prototype de la fonction main : pourquoi argc est il signé ?
22 réponses
hibakusha
Bonjour à tous.
Pour le protoype suivant de main :
int main(int argc, char* argv[])
la norme indique pour argc :
"The value of argc shall be nonnegative."
L'utilisation de "shall" est perturbante, et je me demande ce qu'il
faut comprendre ici : est ce que cela veut bien dire que argc DOIT être
positif ? Et dans ce cas, pourquoi argc est il de type "int", c'est à
dire potentiellement négatif ?
Est ce moi qui comprends mal cette définition, ou bien y a t il la une
bizarerie, héritage quelconque d'un comportement etrange de certaines
version d'unix ou je ne sais quelle autre explication ?
Clairement, je me demande si il existe certaines situations où argc peut
être négatif ?
Et je me pose cette question avant de partir en vacances, c'est un signe...
Merci d'apporter vos lumieres sur le sujet...
(Je suis sûr que la question à déja été posée, mais je n'arrive pas a
mettre la main sur une réponse)
Mmmmh. En fait, et ÀMHA évidemment, [u]int_fastN_t ne sert à rien, entre autre ou surtout parce que personne ne l'utilise !
Moi je les utilise. :)
Sans compter qu'il est très difficile de définir correctement (comment quantifier l'impact de la limitation de taille du cache ou celui des différents microcodes ? sur x86-32, suivant les algorithmes et les versions des processeurs ciblés, pour int_fast16_t tu auras parfois 16 et parfois 32 bits...)
S'il est difficile à l'implémentation de les définir, je ne pense pas que l'utilisateur puisse mieux le faire. Je pense que dans le doute, une implémentation doit prendre la même définition que [u]int_leastN_t.
Je ne crois pas que [u]int_fastN_t fut une bonne idée.
J'aurais préféré une définition différente, notamment pour int_fastN_t, à savoir qu'une valeur hors des N bits provoque un comportement indéfini.
Un des problèmes est que certaines structures liées au système ont des données sur 16 bits, et avant C99, short était plus ou moins de seul moyen pour cela.
En fait, l'interface avec les données de taille fixée par l'extérieur est LA grande raison des [u]intN_t ! Le reste n'est que broderie.
C'est pour ça que je dis qu'une implémentation 36 bits peut très bien définir [u]int32_t.
Sauf que dans la pratique, l'ordre des octets importe aussi ; et bien sûr le fait que cette normalisation est arrivée bien trop tard.
Dans l'article <faepo8$rql$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Mmmmh. En fait, et ÀMHA évidemment, [u]int_fastN_t ne sert à rien, entre
autre ou surtout parce que personne ne l'utilise !
Moi je les utilise. :)
Sans compter qu'il est très difficile de définir correctement
(comment quantifier l'impact de la limitation de taille du cache ou
celui des différents microcodes ? sur x86-32, suivant les
algorithmes et les versions des processeurs ciblés, pour
int_fast16_t tu auras parfois 16 et parfois 32 bits...)
S'il est difficile à l'implémentation de les définir, je ne pense pas
que l'utilisateur puisse mieux le faire. Je pense que dans le doute,
une implémentation doit prendre la même définition que [u]int_leastN_t.
Je ne crois pas que [u]int_fastN_t fut une bonne idée.
J'aurais préféré une définition différente, notamment pour int_fastN_t,
à savoir qu'une valeur hors des N bits provoque un comportement indéfini.
Un des problèmes est que certaines structures liées au système ont
des données sur 16 bits, et avant C99, short était plus ou moins
de seul moyen pour cela.
En fait, l'interface avec les données de taille fixée par
l'extérieur est LA grande raison des [u]intN_t ! Le reste n'est que
broderie.
C'est pour ça que je dis qu'une implémentation 36 bits peut très
bien définir [u]int32_t.
Sauf que dans la pratique, l'ordre des octets importe aussi ; et
bien sûr le fait que cette normalisation est arrivée bien trop tard.
Mmmmh. En fait, et ÀMHA évidemment, [u]int_fastN_t ne sert à rien, entre autre ou surtout parce que personne ne l'utilise !
Moi je les utilise. :)
Sans compter qu'il est très difficile de définir correctement (comment quantifier l'impact de la limitation de taille du cache ou celui des différents microcodes ? sur x86-32, suivant les algorithmes et les versions des processeurs ciblés, pour int_fast16_t tu auras parfois 16 et parfois 32 bits...)
S'il est difficile à l'implémentation de les définir, je ne pense pas que l'utilisateur puisse mieux le faire. Je pense que dans le doute, une implémentation doit prendre la même définition que [u]int_leastN_t.
Je ne crois pas que [u]int_fastN_t fut une bonne idée.
J'aurais préféré une définition différente, notamment pour int_fastN_t, à savoir qu'une valeur hors des N bits provoque un comportement indéfini.
Un des problèmes est que certaines structures liées au système ont des données sur 16 bits, et avant C99, short était plus ou moins de seul moyen pour cela.
En fait, l'interface avec les données de taille fixée par l'extérieur est LA grande raison des [u]intN_t ! Le reste n'est que broderie.
C'est pour ça que je dis qu'une implémentation 36 bits peut très bien définir [u]int32_t.
Sauf que dans la pratique, l'ordre des octets importe aussi ; et bien sûr le fait que cette normalisation est arrivée bien trop tard.
"Antoine Leca" a écrit dans le message de news: faepo8$rql$
[...]
Cf. l'enfilade sur la supposition que le type int doit être réservé à l'intervalle [-32768, 32767].
Notons au passage que les types décriés int_least16_t et int_fast16_t sont en fait limités à [-32767..32767] sur certaines architectures obsoletes, contrairement à int16_t qui est forcément exactement 16 bits en représentation binaire en complément à 2 sans trap values et autres bits de padding.
Personnellement, je pense qu'on devrait supprimer toutes ces acrobaties délirantes pour supporter des architectures moribondes sans intérêt (complement à 1, signe/magnitude, bits de padding, trap values...) voire même les tailles de mots bancales (char de 9 bits, int de 36...)
A vouloir à tout prix rester compatible avec les architectures obsoletes, c'est le langage C lui-meme qui devient obsolete.
Chqrlie.
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de news:
faepo8$rql$1@shakotay.alphanet.ch...
[...]
Cf. l'enfilade sur la supposition que le type int doit être réservé à
l'intervalle [-32768, 32767].
Notons au passage que les types décriés int_least16_t et int_fast16_t sont
en fait limités à [-32767..32767] sur certaines architectures obsoletes,
contrairement à int16_t qui est forcément exactement 16 bits en
représentation binaire en complément à 2 sans trap values et autres bits de
padding.
Personnellement, je pense qu'on devrait supprimer toutes ces acrobaties
délirantes pour supporter des architectures moribondes sans intérêt
(complement à 1, signe/magnitude, bits de padding, trap values...) voire
même les tailles de mots bancales (char de 9 bits, int de 36...)
A vouloir à tout prix rester compatible avec les architectures obsoletes,
c'est le langage C lui-meme qui devient obsolete.
"Antoine Leca" a écrit dans le message de news: faepo8$rql$
[...]
Cf. l'enfilade sur la supposition que le type int doit être réservé à l'intervalle [-32768, 32767].
Notons au passage que les types décriés int_least16_t et int_fast16_t sont en fait limités à [-32767..32767] sur certaines architectures obsoletes, contrairement à int16_t qui est forcément exactement 16 bits en représentation binaire en complément à 2 sans trap values et autres bits de padding.
Personnellement, je pense qu'on devrait supprimer toutes ces acrobaties délirantes pour supporter des architectures moribondes sans intérêt (complement à 1, signe/magnitude, bits de padding, trap values...) voire même les tailles de mots bancales (char de 9 bits, int de 36...)
A vouloir à tout prix rester compatible avec les architectures obsoletes, c'est le langage C lui-meme qui devient obsolete.
