Je n'ai jamais prétendu qu'il était incorrect! C'est juste que je le trouve crade. Rien ne t'empêche de définir une variable de retour au début, et de la retourner une seule fois à la fin.
Ça pinaille là. Ce sont des droits Unix. On peut utiliser les constantes symboliques, mais ça n'apporte pas grand chose, voir c'est contre-productif.
J'aurais dû expliquer, mais ce qui me gène, c'est la duplication de code. Ici tu as 0700, et dans une autre fonction tu as 0700, et dans un autre fichier tu as 0700, etc. Je ne voulais surtout pas dire qu'il fallait remplacer 0700 par une constante user_access_only, mais plutôt par une variable globale int permission_parent_dir = 0700; . En gros, dintinguer le signifiant du signifié, et faciliter la maintenance du code.
C'est un peu moche, mais c'est de la tambouille interne. Comme de toute façon, ils ont décidé que /run devait exister
Ouais, c'est super sympa pour les mainteneurs des distributions qui décideront d'organiser le système autrement. C'est juste de l'égoïsme, "Moi je ne vois pas pourquoi je changerais ça, donc je le met en dur". 1) tu n'es jamais sûr que tu n'auras pas besoin de le changer, et 2) tu n'es jamais sûr que quelqu'un d'autre n'aura pas besoin de le changer.
C'est du C. On a l'habitude d'abuser la sémantique. Si c'est "proprement" documenté :). Pas choqué
Abuser la sémantique est une chose, mais là, ça renvoie 4 trucs différents :
* l'opposé du retour de get_ctty_devnr si ce retour est positif
* -ENOMEM si l'asprint a foiré
* -errno si l'open a foiré
* le file descriptor si open a réussi
Il me semble que la sémantique, c'est que si le retour est positif, alors c'est le file descriptor, s'il est négatif, c'est n'importe quoi. Le traitement de l'erreur va être vachement facile.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par arnaudus . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Je n'ai jamais prétendu qu'il était incorrect! C'est juste que je le trouve crade. Rien ne t'empêche de définir une variable de retour au début, et de la retourner une seule fois à la fin.
J'aurais dû expliquer, mais ce qui me gène, c'est la duplication de code. Ici tu as 0700, et dans une autre fonction tu as 0700, et dans un autre fichier tu as 0700, etc. Je ne voulais surtout pas dire qu'il fallait remplacer 0700 par une constante user_access_only, mais plutôt par une variable globale int permission_parent_dir = 0700; . En gros, dintinguer le signifiant du signifié, et faciliter la maintenance du code.
Ouais, c'est super sympa pour les mainteneurs des distributions qui décideront d'organiser le système autrement. C'est juste de l'égoïsme, "Moi je ne vois pas pourquoi je changerais ça, donc je le met en dur". 1) tu n'es jamais sûr que tu n'auras pas besoin de le changer, et 2) tu n'es jamais sûr que quelqu'un d'autre n'aura pas besoin de le changer.
Abuser la sémantique est une chose, mais là, ça renvoie 4 trucs différents :
* l'opposé du retour de get_ctty_devnr si ce retour est positif
* -ENOMEM si l'asprint a foiré
* -errno si l'open a foiré
* le file descriptor si open a réussi
Il me semble que la sémantique, c'est que si le retour est positif, alors c'est le file descriptor, s'il est négatif, c'est n'importe quoi. Le traitement de l'erreur va être vachement facile.