/* Topic des codeurs [8] */

Rolinh · Le 28/11/2013, à 18:42

Mmh. Pourrais-tu me donner le contenu de /proc/mounts et également l'output de dfc -To ? Je vais regarder aussi pour le coup du rootfs en même temps.

The Uploader · Le 28/11/2013, à 21:50

(Je viens de démarrer) :

#( 11/28/13@ 9:50 )( max@max-laptop ):~
   dfc
SYS. FICH.  (=)  UT.      LIB. (-) %UTILISÉ    DISPO.     TOTAL MONTÉ SUR  
rootfs      [=======-------------]   32%     19,8G     29,2G /
dev         [--------------------]    0%      1,9G      1,9G /dev
run         [=-------------------]    0%      1,9G      1,9G /run
/dev/sdb1   [=======-------------]   32%     19,8G     29,2G /
tmpfs       [=-------------------]    0%      1,9G      1,9G /dev/shm
tmpfs       [--------------------]    0%      1,9G      1,9G /sys/fs/cgroup
systemd-1   [===========---------]   55%    114,8G    252,9G /home
tmpfs       [=-------------------]    0%      1,9G      1,9G /tmp
/dev/sda2   [===========---------]   55%    114,8G    252,9G /home
#( 11/28/13@ 9:50 )( max@max-laptop ):~
   dfc -To 
AVERTISSEMENT: le TTY est trop étroit. Certaines options ont été désactivées afin d'ajuster l'affichage (utilisez -f afin d'outrepasser).
SYS. FICH. %UTILISÉ    DISPO.     TOTAL MONTÉ SUR  
rootfs       32%     19,8G     29,2G /
dev           0%      1,9G      1,9G /dev
run           0%      1,9G      1,9G /run
/dev/sdb1    32%     19,8G     29,2G /
tmpfs         0%      1,9G      1,9G /dev/shm
tmpfs         0%      1,9G      1,9G /sys/fs/cgroup
systemd-1    55%    114,8G    252,9G /home
tmpfs         0%      1,9G      1,9G /tmp
/dev/sda2    55%    114,8G    252,9G /home
#( 11/28/13@ 9:51 )( max@max-laptop ):~
   cat /proc/mounts 
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
dev /dev devtmpfs rw,nosuid,relatime,size=2010364k,nr_inodes=502591,mode=755 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
/dev/sdb1 / ext4 rw,noatime,discard,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/bfqio cgroup rw,nosuid,nodev,noexec,relatime,bfqio 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /home autofs rw,relatime,fd=39,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
tmpfs /tmp tmpfs rw 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/sda2 /home ext4 rw,relatime,data=ordered 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

Rolinh · Le 29/11/2013, à 08:21

dfc a écrit :

AVERTISSEMENT: le TTY est trop étroit. Certaines options ont été désactivées afin d'ajuster l'affichage (utilisez -f afin d'outrepasser).

En l'occurence, -T et -o ont été désactivés. ^^

Enfin bon, peu importe, j'ai ce que je voulais voir là pour home:

systemd-1 /home autofs rw,relatime,fd=39,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
/dev/sda2 /home ext4 rw,relatime,data=ordered 0 0

df des coreutils avait introduit un filtre explicite pour rootfs récemment mais cela a été retiré (heureusement, c'était un peu crade comme façon de faire).
Je pense qu'il faudrait que je revois mon filtre qui se base sur une idée trop simpliste: une taille de 0. Cela fonctionne pour les cgroup et autres filesystem tels que proc, sysfs, debugfs, etc. mais ce n'est pas très robuste.

Dernière modification par Rolinh (Le 29/11/2013, à 08:30)

grim7reaper · Le 29/11/2013, à 08:59

Une idée possible serait de filtrer sur le champs 3, en virant les systèmes de fichiers considérés comme nodev dans /proc/filesystems.
Faudra faire une exception pour tmpfs et peut-être pour les systèmes de fichiers via le réseau (à vérifier, j’en ai pas sous la main) mais ça paraît être une approche pas trop crade.
Bon, par contre il faudrait voir si les BSD (MacOS inclus) ont bien ce fichier, ce dont je ne suis vraiment pas certains.

Si non, va falloir trouver une autre approche.

Elzen · Le 29/11/2013, à 10:48

Hum. Je cherche depuis un moment et je n'ai rien trouvé, donc je suppose que non, mais je préfère demander au cas où : en (Py)GTK, dans un TextView, est-il possible de n'afficher (et donc de ne laisser modifier) qu'une partie du TextBuffer associé ?

Du genre, on a un TextView avec un TextBuffer pour afficher le contenu complet d'un truc ; et on veut pouvoir faire un zoom sur un endroit donné, dans un autre TextView, sans impacter le reste du texte.

Sinon, j'peux me débrouiller autrement (du genre en créant un TextBuffer indépendant du premier et en reportant les modifs à chaque signal), mais ça me semblerait moins propre (et ça risque d'être délicat au niveau des undo/redo).

Rolinh · Le 29/11/2013, à 12:32

@grim7reaper: En fait, pour les *BSD (OSX aussi je suppose), c'est super simple et propre: il y a le flag MNT_IGNORE qui est justement prévu pour ça. Pour Linux ben pour le moment je n'ai pas de solution propre.
Regarder l'option de montage nodev comme tu le suggères ne suffit pas:

% dfc -boaT | grep -v nodev
FILESYSTEM  TYPE       %USED AVAILABLE     TOTAL MOUNTED ON               MOUNT OPTIONS
rootfs      rootfs       64%     17.9G     49.1G /                        rw
dev         devtmpfs      0%      7.8G      7.8G /dev                     rw,nosuid,relatime,size=8137524k,nr_inodes=2034381,mode=755
/dev/sda1   ext4         64%     17.9G     49.1G /                        rw,noatime,discard,data=ordered
devpts      devpts      100%        0B        0B /dev/pts                 rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
systemd-1   autofs      100%        0B        0B /proc/sys/fs/binfmt_misc rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
debugfs     debugfs     100%        0B        0B /sys/kernel/debug        rw,relatime
mqueue      mqueue      100%        0B        0B /dev/mqueue              rw,relatime
hugetlbfs   hugetlbfs   100%        0B        0B /dev/hugepages           rw,relatime
tmpfs       tmpfs         5%      7.4G      7.8G /tmp                     rw
/dev/sda2   ext4         11%    151.4G    169.6G /home                    rw,noatime,discard,data=ordered
configfs    configfs    100%        0B        0B /sys/kernel/config       rw,relatime
/dev/md0    ext4         11%      4.8T      5.4T /mnt/data                rw,noatime,stripe=64,data=ordered
binfmt_misc binfmt_misc 100%        0B        0B /proc/sys/fs/binfmt_misc rw,relatime

Donc je pense qu'il faut que je cherche une approche différente.

The Uploader · Le 29/11/2013, à 13:07

Tu peux pas filtrer au niveau de l'UUID des partitions ?

Rolinh · Le 29/11/2013, à 17:27

Ça peut paraître une bonne idée à priori mais ça ne fonctionne pas pour les remote fs (sshfs, nfs, toussa). Et puis la documentation de libblkid, merci quoi...
Enfin bon, faudra bien que je trouve un moyen de récupérer les UUID de toute façon vu qu'une option pour afficher les UUID est prévue.

grim7reaper · Le 30/11/2013, à 01:43

Rolinh a écrit :

Regarder l'option de montage nodev comme tu le suggères ne suffit pas:

Tu m’as mal compris.
Je ne parlais pas de nodev dans les options de montages, mais de nodev dans /proc/filesystems.
À partir de ça, tu aurais une liste de type de système de fichier à filtrer :

Exemple sur ma machine :

% grep nodev /proc/filesystems | cut -f 2
sysfs
rootfs
ramfs
bdev
proc
cgroup
cpuset
tmpfs
devtmpfs
binfmt_misc
debugfs
securityfs
sockfs
pipefs
anon_inodefs
configfs
devpts
hugetlbfs
autofs
pstore
mqueue
fuse
fusectl

Rolinh · Le 30/11/2013, à 10:27

Ah ouais, j'avais mal compris. Chez moi il ne marque pas fuseblk comme étant nodev mais fuse et fusectl oui. Du coup, un fuse.sshfs par exemple, tu trierais ça comment?

grim7reaper · Le 01/12/2013, à 01:16

C’est quoi le type d’un sshfs ?
Je pense qu’il y aura peut-être des exceptions à faire. Si elles sont pas trop nombreuses c’est jouable, sinon faudra trouver autre chose.

Rolinh · Le 01/12/2013, à 13:19

Bah c'est monté via fuse en userspace normalement donc c'est pas un filesystem per se. sshfs apparaît comme fuse.sshfs. En fait, il y a potentiellement un tri à faire pour tous les fs monté via fuse.
En fait, fuseblk c'est pour les mount NTFS ou FAT je pense du coup ça explique pourquoi c'est pas un nodev.

Il y a peut-être une idée à piquer dans filter_mount_list de df des coreutils:

Coreutils df(1) a écrit :

Filter mount list by skipping duplicate entries.
In the case of duplicities - based on to the device number - the mount entry
with a '/' in its me_devname (i.e. not pseudo name like tmpfs) wins.
If both have a real devname (e.g. bind mounts), then that with the shorter
me_mountdir wins.

The Uploader · Le 01/12/2013, à 23:57

*bouffe du WPF (.NET)*
Oui bon le MVVM, c'est du MVC en un peu plus découplé...

Dernière modification par The Uploader (Le 01/12/2013, à 23:57)

grim7reaper · Le 02/12/2013, à 06:41

@Rolinh : en effet, l’approche de df est peut-être pas mauvaise.

@The Uploader : maso ou c’est pour le boulot (ou un éventuel boulot) ?

grim7reaper · Le 02/12/2013, à 08:13

Hop, mise à jour de mes flags de compilations C et C++.
Suppression d’options obsolètes ou redondantes et quelques ajouts.

C_FLAGS='-std=c89 -Wall -Wextra -pedantic -Wdouble-promotion -Wformat=2 -Winit-self -Wmissing-include-dirs -Wswitch-default -Wfloat-equal -Wundef -Wshadow -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wjump-misses-init -Wlogical-op -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wredundant-decls -Wnested-externs -pipe'
C_FLAGS_DEBUG='-g3 -ggdb3 -Wpadded -Wpacked'
C_FLAGS_RELEASE='-O3 -flto -march=native -DNDEBUG'
alias gcc_debug="gcc $C_FLAGS $C_FLAGS_DEBUG"
alias gcc_release="gcc $C_FLAGS $C_FLAGS_RELEASE"

CXX_FLAGS='-std=c++11 -Wall -Wextra -pedantic -Wdouble-promotion -Wformat=2 -Winit-self -Wmissing-include-dirs -Wswitch-default -Wsuggest-attribute=const -Wsuggest-attribute=noreturn -Wfloat-equal -Wundef -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-conversion -Wuseless-cast -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wnon-virtual-dtor -Wstrict-null-sentinel -Wold-style-cast -Woverloaded-virtual -pipe'
CXX_FLAGS_DEBUG='-g3 -ggdb3 -Wpadded -Wpacked'
CXX_FLAGS_RELEASE='-O3 -flto -march=native -DNDEBUG -Winline'
alias g++_debug="g++ $CXX_FLAGS $CXX_FLAGS_DEBUG"
alias g++_release="g++ $CXX_FLAGS $CXX_FLAGS_RELEASE"

Bon je n’ai pas encore testé de manière approfondie, donc ce n’est pas une version définitive. Si certains font trop de faux-positifs, je ferai un tri.

The Uploader · Le 02/12/2013, à 09:17

grim7reaper a écrit :

@Rolinh : en effet, l’approche de df est peut-être pas mauvaise.
@The Uploader : maso ou c’est pour le boulot (ou un éventuel boulot) ?

éventuel boulot.

Rolinh · Le 02/12/2013, à 11:06

@grim7reaper: oh, cool, je vais tester ça (sur dfc et VQMT dans un premier temps). Ils sont tous spécifiques à gcc ou bien clang les supporte aussi?

EDIT: Un truc auquel je viens de penser: -march=native pour RELEASE c'est peut-être pas une si bonne idée tout compte fait. C'est bien quand tu compiles et installes sur ta machine mais imagine un packager pour une distribution quelconque: il veut compiler des paquets génériques et c'est naturel de vouloir utiliser RELEASE.

Dernière modification par Rolinh (Le 02/12/2013, à 11:13)

grim7reaper · Le 02/12/2013, à 12:32

Rolinh a écrit :

Ils sont tous spécifiques à gcc ou bien clang les supporte aussi?

Y’en a pas mal qui doivent passer sur clang, vu que clang vise une certaine compatibilité avec GCC à ce niveau. Mais je ne garantirai pas que tout sois dispo’.

Pour clang j’utilise un jeu d’options différent. Par exemple, clang offre des options très sympa’ pour détecter les comportements non définis (ce n’est pas parfait, ça ne détecte pas tout bien sûr mais ça reste très utile).
Je peux poster celles que j’utilise actuellement :

# clang
alias clang_debug='clang -g -fno-limit-debug-info -std=c89 -Weverything -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv -pipe'
alias clang_release='clang -std=c89 -O4 -pedantic -Wall -Wextra -pipe -march=native -DNDEBUG'

# clang++
alias clang++_debug='clang++ -g -fno-limit-debug-info -std=c++11 -Weverything -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv -pipe'
alias clang++_release='clang++ -std=c++11 -O4 -pedantic -Wall -Wextra -pipe -march=native -DNDEBUG'

Il faudrait que je regarde sil y a des choses à mettre à jour pour clang aussi.
Le problème c’est que clang ne documente pas des masses ses options (où alors je n’ai pas trouvé où ).

Rolinh a écrit :

EDIT: Un truc auquel je viens de penser: -march=native pour RELEASE c'est peut-être pas une si bonne idée tout compte fait. C'est bien quand tu compiles et installes sur ta machine mais imagine un packager pour une distribution quelconque: il veut compiler des paquets génériques et c'est naturel de vouloir utiliser RELEASE.

Oui, c’est bien si tu distribues sous forme de sources et que les gens compilent sur leur machine.
Si tu distribues du binaire, il vaut mieux ne pas utiliser -march ou en utiliser un plus générique (genre i686 par exemple).

Dernière modification par grim7reaper (Le 02/12/2013, à 12:34)

Rolinh · Le 02/12/2013, à 13:24

grim7reaper a écrit :

Y’en a pas mal qui doivent passer sur clang, vu que clang vise une certaine compatibilité avec GCC à ce niveau. Mais je ne garantirai pas que tout sois dispo’.

-Wjump-misses-init ne passe pas (clang 3.4). Pour les autres ça semble bon.

grim7reaper a écrit :

Pour clang j’utilise un jeu d’options différent. Par exemple, clang offre des options très sympa’ (...)

Cool, je testerais ça aussi.

grim7reaper a écrit :

Il faudrait que je regarde sil y a des choses à mettre à jour pour clang aussi.

Ouep, fais-le

grim7reaper a écrit :

Le problème c’est que clang ne documente pas des masses ses options (où alors je n’ai pas trouvé où ).

Ah, ça c'est pas cool

The Uploader · Le 02/12/2013, à 13:34

D'aileurs j'utilise march=native dans /etc/makepkg.conf sur ma Arch, mais c'est plus parce que l'option est là qu'autre chose.
Y'a un vrai intérêt ? (en x86_64, je parle).

Dernière modification par The Uploader (Le 02/12/2013, à 13:34)

grim7reaper · Le 02/12/2013, à 13:44

The Uploader a écrit :

Y'a un vrai intérêt ? (en x86_64, je parle).

Ça dépends de ton CPU.
Dans mon cas, oui j’y gagne :

man 1 gcc a écrit :

[…]
i686
When used with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. When used with -mtune, it has the same meaning as generic.
[…]
corei7
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 instruction set support.
[…]

Je gagne le support des jeux d’instructions vectorielles (+ peut-être d’autres trucs non précisés dans le man).
C’est pas tout les programmes qui vont réellement en profiter, c’est sûr mais ça serait dommage de s’en priver.

Rolinh · Le 02/12/2013, à 13:53

Bon, du coup j'ai supprimé l'option grim de dfc. Tu ne m'en veux pas? Et j'utilise tes flags par défaut.

Faudra que je teste ça sous FreeBSD aussi pour savoir quels options ne passent pas avec GCC 4.2 afin de les désactiver au besoin. Faudrait peut-être aussi que je teste avec des versions plus ancienne de clang (3.2 et 3.3).

grim7reaper · Le 03/12/2013, à 02:04

Rolinh a écrit :

Bon, du coup j'ai supprimé l'option grim de dfc. Tu ne m'en veux pas? Et j'utilise tes flags par défaut.

Nope, pas de problème bien sûr

Tiens, dans ton CMakeLists.txt tu mets :

CMakeLists.txt a écrit :

using c99 only for long long, all the rest should be c89 compliant

En fait, il n’y a pas que le long long qui n’est pas C89-compliant, il y a aussi ce genre de truc :

	char *const color_opts[] = {
		[CALWAYS] = "always",
		[CNEVER] = "never",
		[CAUTO] = "auto",
		NULL
	};

Qui donne :

warning: designated initializers are a C99 feature [-Wc99-extensions]

Du coup, si tu veux vraiment du C89 il faudrait appliquer ce patch :

diff --git a/src/dfc.c b/src/dfc.c
index 1ecb9e1..933fead 100644
--- a/src/dfc.c
+++ b/src/dfc.c
@@ -121,38 +121,38 @@ main(int argc, char *argv[])
        };
 
        char *const color_opts[] = {
-               [CALWAYS] = "always",
-               [CNEVER] = "never",
-               [CAUTO] = "auto",
+               "always",
+               "never",
+               "auto",
                NULL
        };
 
        char *const export_opts[] = {
-               [ETEXT] = "text",
-               [ECSV] = "csv",
-               [EHTML] = "html",
-               [ETEX] = "tex",
+               "text",
+               "csv",
+               "html",
+               "tex",
                NULL
        };
 
        char *const sort_opts[] = {
-               [SFSNAME] = "name",
-               [SFSTYPE] = "type",
-               [SFSDIR] = "mount",
+               "name",
+               "type",
+               "mount",
                NULL
        };
 
        char *const unit_opts[] = {
-               [UH] = "h",
-               [UB] = "b",
-               [UK] = "k",
-               [UM] = "m",
-               [UG] = "g",
-               [UT] = "t",
-               [UP] = "p",
-               [UE] = "e",
-               [UZ] = "z",
-               [UY] = "y",
+               "h",
+               "b",
+               "k",
+               "m",
+               "g",
+               "t",
+               "p",
+               "e",
+               "z",
+               "y",
                NULL
        };

(Je met le diff’ ici car je pense pas avoir le droit de commit sur dfc).
Ou alors, vu que c’est un problème d’associations constantes symboliques/chaînes de caractères, tu pourrais peut-être envisager l’utilisation d’item-lists.

Sinon, je me demande un truc : si tu n’utilises vraiment que le long long en hors C89, tu ne pourrais pas compiler en C89 + option -Wno-long-long au lieu de compiler en C99 ?

Édit : Y’aurait aussi moyen de faire sauter ces warnings là :

dfc/src/list.c: In function ‘delete_struct_and_get_next’:
dfc/src/list.c:144:8: attention : cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
   free((char *)p->fsname);
        ^
dfc/src/list.c:146:8: attention : cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
   free((char *)p->dir);
        ^
dfc/src/list.c:148:8: attention : cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
   free((char *)p->type);
        ^
dfc/src/list.c:150:8: attention : cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
   free((char *)p->opts);

Moyennant le patch suivant :

diff --git a/src/dfc.c b/src/dfc.c
index 1ecb9e1..839c194 100644
--- a/src/dfc.c
+++ b/src/dfc.c
@@ -74,8 +74,8 @@
 #endif /* NLS_ENABLED */
 
 /* global variables definition, see declaration in extern.h */
-const char *g_unknown_str = "unknown";
-const char *g_none_str    = "none";
+char g_unknown_str[] = "unknown";
+char g_none_str[]    = "none";
 struct conf cnf;
 int aflag, bflag, cflag, dflag, eflag, fflag, hflag, iflag, lflag, mflag,
     nflag, oflag, pflag, qflag, sflag, tflag, uflag, vflag, wflag;
diff --git a/src/extern.h b/src/extern.h
index c405d6a..e05a2c6 100644
--- a/src/extern.h
+++ b/src/extern.h
@@ -95,8 +95,8 @@ struct conf {
  * fsmntinfo struct. So we can know that and don't free the pointers
  */
 
-extern const char *g_unknown_str;
-extern const char *g_none_str;
+extern char g_unknown_str[];
+extern char g_none_str[];
 
 /* struct to store specific configuration from config file */
 extern struct conf cnf;
diff --git a/src/list.c b/src/list.c
index 50efcf6..0032d36 100644
--- a/src/list.c
+++ b/src/list.c
@@ -141,13 +141,13 @@ struct fsmntinfo
        next = p->next;
 
        if(p->fsname != g_unknown_str) /* we malloc'd a string */
-               free((char *)p->fsname);
+               free(p->fsname);
        if(p->dir != g_unknown_str)
-               free((char *)p->dir);
+               free(p->dir);
        if(p->type != g_unknown_str)
-               free((char *)p->type);
+               free(p->type);
        if(p->opts != g_none_str)
-               free((char *)p->opts);
+               free(p->opts);
 
        free(p);
 
diff --git a/src/list.h b/src/list.h
index 2fbc409..4d788ea 100644
--- a/src/list.h
+++ b/src/list.h
@@ -55,10 +55,10 @@
  */
 struct fsmntinfo {
        /* infos to get from getmntent(3) */
-       const char *fsname;     /* name of mounted file system */
-       const char *dir;        /* file system path prefix */
-       const char *type;       /* mount type */
-       const char *opts;       /* mount options (see mntent.h) */
+       char *fsname;   /* name of mounted file system */
+       char *dir;      /* file system path prefix */
+       char *type;     /* mount type */
+       char *opts;     /* mount options (see mntent.h) */
 
        /* infos to get from statvfs(3) */
 #if defined(__linux__) || defined(__NetBSD__)

Dernière modification par grim7reaper (Le 03/12/2013, à 02:34)

Rolinh · Le 03/12/2013, à 08:44

grim7reaper a écrit :

En fait, il n’y a pas que le long long qui n’est pas C89-compliant(...)

Effectivement. Le pire c'est que je venais de commiter un changement là-dessus...

grim7reaper a écrit :

(Je met le diff’ ici car je pense pas avoir le droit de commit sur dfc).)

C'est exact. Enfin, c'était. Je suffisamment confiance en tes compétences et ta volonté de bien faire les choses pour t'avoir octroyé un commit bit désormais.
Ça évitera des git-format-patch à tout va. Et dans le doute, je suis en général joignable sur #gwcomputingnet sur freenode.
Du coup, je te laisse commiter tes changements.

grim7reaper a écrit :

Ou alors, vu que c’est un problème d’associations constantes symboliques/chaînes de caractères, tu pourrais peut-être envisager l’utilisation d’item-lists.

Je vais y jeter un œil mais il faut bien sûr que dans mon cas ça respecte char * const *tokens de getsubopt(3).

grim7reaper a écrit :

Sinon, je me demande un truc : si tu n’utilises vraiment que le long long en hors C89, tu ne pourrais pas compiler en C89 + option -Wno-long-long au lieu de compiler en C99 ?

Effectivement, ça me semble très pertinent.

grim7reaper a écrit :

Édit : Y’aurait aussi moyen de faire sauter ces warnings là ...)

Effectivement, je n'y avais pas pensé.

grim7reaper · Le 03/12/2013, à 11:12

Merci
Je commite ça dès que j’ai le temps.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2026 Le 28/11/2013, à 18:42

Re : /* Topic des codeurs [8] */

#2027 Le 28/11/2013, à 21:50

Re : /* Topic des codeurs [8] */

#2028 Le 29/11/2013, à 08:21

Re : /* Topic des codeurs [8] */

#2029 Le 29/11/2013, à 08:59

Re : /* Topic des codeurs [8] */

#2030 Le 29/11/2013, à 10:48

Re : /* Topic des codeurs [8] */

#2031 Le 29/11/2013, à 12:32

Re : /* Topic des codeurs [8] */

#2032 Le 29/11/2013, à 13:07

Re : /* Topic des codeurs [8] */

#2033 Le 29/11/2013, à 17:27

Re : /* Topic des codeurs [8] */

#2034 Le 30/11/2013, à 01:43

Re : /* Topic des codeurs [8] */

#2035 Le 30/11/2013, à 10:27

Re : /* Topic des codeurs [8] */

#2036 Le 01/12/2013, à 01:16

Re : /* Topic des codeurs [8] */

#2037 Le 01/12/2013, à 13:19

Re : /* Topic des codeurs [8] */

#2038 Le 01/12/2013, à 23:57

Re : /* Topic des codeurs [8] */

#2039 Le 02/12/2013, à 06:41

Re : /* Topic des codeurs [8] */

#2040 Le 02/12/2013, à 08:13

Re : /* Topic des codeurs [8] */

#2041 Le 02/12/2013, à 09:17

Re : /* Topic des codeurs [8] */

#2042 Le 02/12/2013, à 11:06

Re : /* Topic des codeurs [8] */

#2043 Le 02/12/2013, à 12:32

Re : /* Topic des codeurs [8] */

#2044 Le 02/12/2013, à 13:24

Re : /* Topic des codeurs [8] */

#2045 Le 02/12/2013, à 13:34

Re : /* Topic des codeurs [8] */

#2046 Le 02/12/2013, à 13:44

Re : /* Topic des codeurs [8] */

#2047 Le 02/12/2013, à 13:53

Re : /* Topic des codeurs [8] */

#2048 Le 03/12/2013, à 02:04

Re : /* Topic des codeurs [8] */

#2049 Le 03/12/2013, à 08:44

Re : /* Topic des codeurs [8] */

#2050 Le 03/12/2013, à 11:12

Re : /* Topic des codeurs [8] */

Pied de page des forums