sizeof(short)

Gabriel Dos Reis

23/07/2009 à 15:26

candide writes:

| Gabriel Dos Reis a Ã©crit :
| > | *) d'une part, je ne suis pas certain qu'il y ait besoin de clarifica tion ; on
| > | N'a certes PAS en thÃ©orie
| > |
| > | sizeof(short) <= sizeof(int)
| >
| > Les rÃ¨gles de promotions promotent 'short' en 'int'.
|
| Cette remarque est un peu elliptique pour moi. Dois-je comprendre que par un
| chemin tortueux on pourrait finalement dÃ©duire de la Norme qu'on a t oujours
| sizeof(short) <= sizeof(int) ?

Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?

| Pour que les choses soient claires, je prÃ©cise que je crois voir dan s la rÃ¨gle
| que tu rappelles ci-dessus l'expression de :

6.3.1.1 Boolean, characters, and integers

[#1] Every integer type has an integer conversion rank
defined as follows:

-- No two signed integer types shall have the same rank,
even if they have the same representation.

-- The rank of a signed integer type shall be greater than
the rank of any signed integer type with less
precision.

-- The rank of long long int shall be greater than the
rank of long int, which shall be greater than the rank
of int, which shall be greater than the rank of short
int, which shall be greater than the rank of signed
char.

-- The rank of any unsigned integer type shall equal the
rank of the corresponding signed integer type, if any.

-- The rank of any standard integer type shall be greater
than the rank of any extended integer type with the
same width.

-- The rank of char shall equal the rank of signed char
and unsigned char.

-- The rank of _Bool shall be less than the rank of all
other standard integer types.

-- The rank of any enumerated type shall equal the rank of
the compatible integer type (see 6.7.2.2).

-- The rank of any extended signed integer type relative
to another extended signed integer type with the same
precision is implementation-defined, but still subject

to the other rules for determining the integer
conversion rank.

-- For all integer types T1, T2, and T3, if T1 has greater
rank than T2 and T2 has greater rank than T3, then T1
has greater rank than T3.

[#2] The following may be used in an expression wherever an
int or unsigned int may be used:

-- An object or expression with an integer type whose
integer conversion rank is less than the rank of int
and unsigned int.

-- A bit-field of type _Bool, int, signed int, or unsigned
int.

If an int can represent all values of the original type, the
value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer
promotions.48) All other types are unchanged by the integer
promotions.

[#3] The integer promotions preserve value including sign.
As discussed earlier, whether a ``plain'' char is treated as
signed is implementation-defined.

[...]

6.3.1.8 Usual arithmetic conversions

[#1] Many operators that expect operands of arithmetic type
cause conversions and yield result types in a similar way.
[...]
Otherwise, the integer promotions are performed on both
operands. Then the following rules are applied to the
promoted operands:

If both operands have the same type, then no
further conversion is needed.

Otherwise, if both operands have signed integer
types or both have unsigned integer types, the
operand with the type of lesser integer conversion
rank is converted to the type of the operand with
greater rank.

Otherwise, if the operand that has unsigned
integer type has rank greater or equal to the rank
of the type of the other operand, then the operand
with signed integer type is converted to the type
of the operand with unsigned integer type.

Otherwise, if the type of the operand with signed
integer type can represent all of the values of
the type of the operand with unsigned integer
type, then the operand with unsigned integer type
is converted to the type of the operand with
signed integer type.

Otherwise, both operands are converted to the
unsigned integer type corresponding to the type of
the operand with signed integer type.

-- Gaby

candide <candide@free.invalid> writes:

| Gabriel Dos Reis a Ã©crit :
| > | *) d'une part, je ne suis pas certain qu'il y ait besoin de clarifica tion ; on
| > | N'a certes PAS en thÃ©orie
| > |
| > | sizeof(short) <= sizeof(int)
| >
| > Les rÃ¨gles de promotions promotent 'short' en 'int'.
|
| Cette remarque est un peu elliptique pour moi. Dois-je comprendre que par un
| chemin tortueux on pourrait finalement dÃ©duire de la Norme qu'on a t oujours
| sizeof(short) <= sizeof(int) ?

Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?

| Pour que les choses soient claires, je prÃ©cise que je crois voir dan s la rÃ¨gle
| que tu rappelles ci-dessus l'expression de :

6.3.1.1 Boolean, characters, and integers

[#1] Every integer type has an integer conversion rank
defined as follows:

-- No two signed integer types shall have the same rank,
even if they have the same representation.

-- The rank of a signed integer type shall be greater than
the rank of any signed integer type with less
precision.

-- The rank of long long int shall be greater than the
rank of long int, which shall be greater than the rank
of int, which shall be greater than the rank of short
int, which shall be greater than the rank of signed
char.

-- The rank of any unsigned integer type shall equal the
rank of the corresponding signed integer type, if any.

-- The rank of any standard integer type shall be greater
than the rank of any extended integer type with the
same width.

-- The rank of char shall equal the rank of signed char
and unsigned char.

-- The rank of _Bool shall be less than the rank of all
other standard integer types.

-- The rank of any enumerated type shall equal the rank of
the compatible integer type (see 6.7.2.2).

-- The rank of any extended signed integer type relative
to another extended signed integer type with the same
precision is implementation-defined, but still subject

to the other rules for determining the integer
conversion rank.

-- For all integer types T1, T2, and T3, if T1 has greater
rank than T2 and T2 has greater rank than T3, then T1
has greater rank than T3.

[#2] The following may be used in an expression wherever an
int or unsigned int may be used:

-- An object or expression with an integer type whose
integer conversion rank is less than the rank of int
and unsigned int.

-- A bit-field of type _Bool, int, signed int, or unsigned
int.

If an int can represent all values of the original type, the
value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer
promotions.48) All other types are unchanged by the integer
promotions.

[#3] The integer promotions preserve value including sign.
As discussed earlier, whether a ``plain'' char is treated as
signed is implementation-defined.

[...]

6.3.1.8 Usual arithmetic conversions

[#1] Many operators that expect operands of arithmetic type
cause conversions and yield result types in a similar way.
[...]
Otherwise, the integer promotions are performed on both
operands. Then the following rules are applied to the
promoted operands:

If both operands have the same type, then no
further conversion is needed.

Otherwise, if both operands have signed integer
types or both have unsigned integer types, the
operand with the type of lesser integer conversion
rank is converted to the type of the operand with
greater rank.

Otherwise, if the operand that has unsigned
integer type has rank greater or equal to the rank
of the type of the other operand, then the operand
with signed integer type is converted to the type
of the operand with unsigned integer type.

Otherwise, if the type of the operand with signed
integer type can represent all of the values of
the type of the operand with unsigned integer
type, then the operand with unsigned integer type
is converted to the type of the operand with
signed integer type.

Otherwise, both operands are converted to the
unsigned integer type corresponding to the type of
the operand with signed integer type.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

candide writes:

| Gabriel Dos Reis a Ã©crit :
| > | *) d'une part, je ne suis pas certain qu'il y ait besoin de clarifica tion ; on
| > | N'a certes PAS en thÃ©orie
| > |
| > | sizeof(short) <= sizeof(int)
| >
| > Les rÃ¨gles de promotions promotent 'short' en 'int'.
|
| Cette remarque est un peu elliptique pour moi. Dois-je comprendre que par un
| chemin tortueux on pourrait finalement dÃ©duire de la Norme qu'on a t oujours
| sizeof(short) <= sizeof(int) ?

Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?

| Pour que les choses soient claires, je prÃ©cise que je crois voir dan s la rÃ¨gle
| que tu rappelles ci-dessus l'expression de :

6.3.1.1 Boolean, characters, and integers

[#1] Every integer type has an integer conversion rank
defined as follows:

-- No two signed integer types shall have the same rank,
even if they have the same representation.

-- The rank of a signed integer type shall be greater than
the rank of any signed integer type with less
precision.

-- The rank of long long int shall be greater than the
rank of long int, which shall be greater than the rank
of int, which shall be greater than the rank of short
int, which shall be greater than the rank of signed
char.

-- The rank of any unsigned integer type shall equal the
rank of the corresponding signed integer type, if any.

-- The rank of any standard integer type shall be greater
than the rank of any extended integer type with the
same width.

-- The rank of char shall equal the rank of signed char
and unsigned char.

-- The rank of _Bool shall be less than the rank of all
other standard integer types.

-- The rank of any enumerated type shall equal the rank of
the compatible integer type (see 6.7.2.2).

-- The rank of any extended signed integer type relative
to another extended signed integer type with the same
precision is implementation-defined, but still subject

to the other rules for determining the integer
conversion rank.

-- For all integer types T1, T2, and T3, if T1 has greater
rank than T2 and T2 has greater rank than T3, then T1
has greater rank than T3.

[#2] The following may be used in an expression wherever an
int or unsigned int may be used:

-- An object or expression with an integer type whose
integer conversion rank is less than the rank of int
and unsigned int.

-- A bit-field of type _Bool, int, signed int, or unsigned
int.

If an int can represent all values of the original type, the
value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer
promotions.48) All other types are unchanged by the integer
promotions.

[#3] The integer promotions preserve value including sign.
As discussed earlier, whether a ``plain'' char is treated as
signed is implementation-defined.

[...]

6.3.1.8 Usual arithmetic conversions

[#1] Many operators that expect operands of arithmetic type
cause conversions and yield result types in a similar way.
[...]
Otherwise, the integer promotions are performed on both
operands. Then the following rules are applied to the
promoted operands:

If both operands have the same type, then no
further conversion is needed.

Otherwise, if both operands have signed integer
types or both have unsigned integer types, the
operand with the type of lesser integer conversion
rank is converted to the type of the operand with
greater rank.

Otherwise, if the operand that has unsigned
integer type has rank greater or equal to the rank
of the type of the other operand, then the operand
with signed integer type is converted to the type
of the operand with unsigned integer type.

Otherwise, if the type of the operand with signed
integer type can represent all of the values of
the type of the operand with unsigned integer
type, then the operand with unsigned integer type
is converted to the type of the operand with
signed integer type.

Otherwise, both operands are converted to the
unsigned integer type corresponding to the type of
the operand with signed integer type.

-- Gaby

Gabriel Dos Reis

23/07/2009 à 15:27

candide writes:

| Lucas Levrel a Ã©crit :
|
| > Quel est le problÃ¨me ? S'ils ont une trÃ¨s grande expÃ©rie nce, et qu'ils ont
| > toujours vu qu'en pratique c'est vrai, pourquoi ne l'affirmeraient-ils
| > pas ?
| >
|
| Mais il n'affirment pas qu'"en pratique c'est vrai", mais que "c'est vrai " et
| dans un contexte tel qu'on a toutes raisons de penser que le langage est ainsi
| spÃ©cifiÃ© (c'est d'ailleurs formulÃ© ainsi parfois).

Pourquoi penses-tu que les rÃ¨gles de promotion ne l'impliquent pas ?

-- Gaby

Manuel Pégourié-Gonnard

23/07/2009 à 17:39

Gabriel Dos Reis scripsit:

Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?

Je crois que candide pense que ce qui est tortueux, c'est l'éventuel
chemin logique menant des règles de promotion à des conclusions sur
sizeof.

-- The rank [...]

On est bien d'accord que le rang (rank) de int est supérieur ou égal à
celui de short. La question est de savoir pourquoi ça impliquerait que
sizeof int soit supérieur ou égal à sizeof short.

Si un passage de la norme dit en gros que les compilos doivent être
cohérents dans leur choix de padding, alors c'est bon. Sinon, un compilo
pervers pourrait choisir d'utiliser un padding gigantesque sur les
short et pas de padding sur les int, ce qui donnerait sizeof short >
sizeof int.

--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/

candide

23/07/2009 à 23:25

Manuel Pégourié-Gonnard a écrit :

Gabriel Dos Reis scripsit:

Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?

Je crois que candide pense que ce qui est tortueux, c'est l'éventuel
chemin logique menant des règles de promotion à des conclusions sur
sizeof.

Oui, c'est _exactement_ cela.

-- The rank [...]

On est bien d'accord que le rang (rank) de int est supérieur ou égal à
celui de short.

plutôt

/strictement/ supérieur

me semble-t-il.

La question est de savoir pourquoi ça impliquerait que
sizeof int soit supérieur ou égal à sizeof short.

C'est aussi la question que je me pose.

Si un passage de la norme dit en gros que les compilos doivent être
cohérents dans leur choix de padding, alors c'est bon. Sinon, un compilo
pervers pourrait choisir d'utiliser un padding gigantesque sur les
short et pas de padding sur les int, ce qui donnerait sizeof short >
sizeof int.

C'est aussi cet argument qui m'a été donné sur comp.std.c il y a deux jours
lorsque j'ai reposé la question.

Gaby, nous sommes donc nombreux, ici et ailleurs, à attendre ta démonstration ;)
même si je ne me fais pas beaucoup d'illusion :(

Gabriel Dos Reis

24/07/2009 à 17:05

Manuel PÃ©gouriÃ©-Gonnard <mpg+ writes:

| Gabriel Dos Reis scripsit:
|
| > Pourquoi penses-tu la promotion de short -> int est un chemin tortueux ?
| >
| Je crois que candide pense que ce qui est tortueux, c'est l'Ã©ventuel
| chemin logique menant des rÃ¨gles de promotion Ã des conclusions sur
| sizeof.
|
| > -- The rank [...]
|
| On est bien d'accord que le rang (rank) de int est supÃ©rieur ou Ã ©gal Ã
| celui de short. La question est de savoir pourquoi Ã§a impliquerait q ue
| sizeof int soit supÃ©rieur ou Ã©gal Ã sizeof short.
|
| Si un passage de la norme dit en gros que les compilos doivent Ãªtre
| cohÃ©rents dans leur choix de padding, alors c'est bon.

Je crois que le passage qui impose un choix cohÃ©rent sur les paddings
est absent de la norme C -- il est prÃ©sent dans la norme C++. Oops.

-- Gaby

-ed-

26/07/2009 à 17:02

On 21 juil, 02:41, candide wrote:

Bonjour,

J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).

J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.

Quelqu'un peut-il préciser ? Merci

On a déjà expliqué 3zillions de fois que les types étaient défini s par
leur plages et non par leur tailles... La relation dont tu parles
n'est pas dans la norme. C'est une déduction plus ou moins fumeuse
(probablement issue du Rationale)...

ccandide

26/07/2009 à 20:27

On 26 juil, 17:02, -ed- wrote:

On a déjà expliqué 3zillions de fois que les types étaient défi nis par
leur plages et non par leur tailles...

Ah ouais ?? Quand l'arrogance se transforme en idiotie ... Lorsque je
faisais allusion aux personnes de ce forum qui affirmait que sizeof
(char) <= sizeof(int), à ton avis, je faisais allusion à qui ? Je te
cite le 1er février 2003 :

La définition du langage C établit les relations suivantes :

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

cf. http://groups.google.fr/group/fr.comp.lang.c/msg/48f3a2ee8f2931c1

Et j'ai a ta disposition au moins une autre citation de toi sur cette
question qui aggraverait encore ton cas.

La relation dont tu parles
n'est pas dans la norme. C'est une déduction plus ou moins fumeuse

:)))))

(probablement issue du Rationale)...

Ta forfanterie est inégalable. J'ai évidemment consulté le Rationale
et nulle trace de cela. Par contre, de toute évidence tu ne l'as pas
ouvert.

-ed-

27/07/2009 à 15:23

On 26 juil, 20:27, ccandide wrote:

(char) <= sizeof(int), à ton avis, je faisais allusion à qui ? Je t e
cite le 1er février 2003 :

> La définition du langage C établit les relations suivantes :

> sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

2003 ? Oui, c'est possible. Je dois aussi citer tes erreurs passées ?
Ce qui compte, ce n'est pas l'historique, mais l'état des lieux tel
qu'il est affirmé à ce jour, c'est à dire, par exemple, sur mon
site ...

Gabriel Dos Reis

27/07/2009 à 17:56

-ed- writes:

| On 26 juil, 20:27, ccandide wrote:
| > (char) <= sizeof(int), Ã ton avis, je faisais allusion Ã qu i ? Je te
| > cite le 1er fÃ©vrier 2003 :
| >
| > > La dÃ©finition du langage C Ã©tablit les relations suivantes :
| >
| > > sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)
|
| 2003 ? Oui, c'est possible. Je dois aussi citer tes erreurs passÃ©es ?
| Ce qui compte, ce n'est pas l'historique, mais l'Ã©tat des lieux tel
| qu'il est affirmÃ© Ã ce jour, c'est Ã dire, par exemple, su r mon
| site ...

:-)

-- Gaby

ccandide

28/07/2009 à 00:36

On 27 juil, 15:23, -ed- wrote:

2003 ? Oui, c'est possible.

Possible ? C'est même certain. Mais à propos, en 2003, tu avais déj à
combien d'années de C en tant que professionnel ? 15 ans ? Et tu
étalais ta morgue sur les forums C de Usenet depuis combien d'années ?
4 ans ? Donc l'année 2003 ne fait rien à l'affaire.

Et sans compter que je ne suis pas certain que tu savais, aujourd'hui,
en 2009, que sizeof (int) > sizeof(long) était possible. Quand j'ai lu
ta réponse j'ai immédiatement pensé à cette phrase de Jean Cocteau :

"Puisque ces choses nous dépassent, feignons den être les
instigateurs."

Ce que je constate c'est :

1°) que sur ce fil tu es arrivé après la bataille, pour donner des
leçons comme à ton habitude et essayer de tirer les marrons du feu ;

2°) qu'en 2008, au cours d'une discussion sur le site du zéro,
quelqu'un a affirmé dans un message, entre autres que la Norme
assurait que (sizeof(short) <= sizeof(int)) && (sizeof(int) <= sizeof
(long)), et tu as répondu à son message sur un tout autre point, sans
démentir ce point particulier. Connaissant tes habitudes sur le site
du zéro, je crois que tu aurais démenti si tu avais su que c'était
faux.

Le message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510043

Au passage, dans ce fil, tu n'as pas manqué de montrer ta
méconnaissance totale de la Norme en démentant ce que disait un
participant, à savoir que le type int est le type naturel de
l'architecture, ce qui est pourtant bien connu si on a lu la Norme. Le
message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510253

je ne serais pas étonné de trouver des références de toi, postéri eures
à 2003 et qui affirmeraient que sizeof(short) <= sizeof(int).

Je te trouve d'autant moins d'excuses à venir me/nous donner la leçon
avec ton

On a déjà expliqué 3zillions de fois que les types étaient défi nis par
leur plages et non par leur tailles...

(cf. ci-dessus)

qu'en fait Chris Torek sur clc t'avait donné la réponse à la question
du présent fil dans un fil que TU avais toi même ouvert en 2000. Ce
fil ouvert par toi est ici :

http://groups.google.com/group/comp.lang.c/msg/f8fcf15e577303bf

et la réponse que donne Chis Torek (et qui y propose une
implémentation conforme vérifiant sizeof(int) == 14 et sizeof(long) ==
3) est ici :

http://groups.google.com/group/comp.lang.c/msg/812d58fb3c86f3a2

Je précise tout de suite à ceux qui pourraient penser que j'ai voulu
te piéger : j'ai découvert ces fils bien APRES d'avoir posté ma
question ici sur fclc et j'ai même évité de te citer quand j'avais lu
ici que sizeof(short) <= sizeof(int). C'est ta réponse d'un
_incroyable__toupet_ qui m'oblige à te dire les choses sur le ton
approprié, fort peu courtois, je n'en disconviens pas mais après tout,
le manque de courtoisie, le lynchage de débutant dont tu as fait
couramment preuve et ton arrogance naturelle couplé au manque de
fiabilité de tes réponses t'exposent à ce genre de retour.

Je dois aussi citer tes erreurs passées ?

Mes erreurs du passés ? Ce n'est pas le terme approprié car je ne me
suis jamais présenté comme un expert mais plutôt comme un candide qui
revendique ses errements au cours de son apprentissage du C !! Je l'
ai appris pratiquement en direct sur fclc, mon premier message date de
la mi-août 2005.

Ce qui compte, ce n'est pas l'historique,

SI. Ce que tu as dit en 2003 alors que tu étais déjà un programmeur
aguerri aurait dû t'inviter à plus d'humilité (et aurait même dû
t'inciter à t'abstenir de répondre plutôt que de venir fanfaronner).

mais l'état des lieux tel
qu'il est affirmé à ce jour, c'est à dire, par exemple, sur mon
site ...

Je crois que parfois tu ne te rends pas compte du grotesque de tes
propos.

Je ne vais pas parler de ton site mais plutôt de la FAQ C de
Developpez (site qui contient un forum C dont tu es modérateur-
rédacteur-grand_manitou_aux_15000_messages) et qui affirme que la
Norme dit que sizeof(short)<=sizeof(int) <=sizeof(long). Commence déj à
par balayer devant ta porte, c'est une mesure de salubrité.

On 27 juil, 15:23, -ed- <emmanuel.delah...@gmail.com> wrote:

2003 ? Oui, c'est possible.

Possible ? C'est même certain. Mais à propos, en 2003, tu avais déj à
combien d'années de C en tant que professionnel ? 15 ans ? Et tu
étalais ta morgue sur les forums C de Usenet depuis combien d'années ?
4 ans ? Donc l'année 2003 ne fait rien à l'affaire.

Et sans compter que je ne suis pas certain que tu savais, aujourd'hui,
en 2009, que sizeof (int) > sizeof(long) était possible. Quand j'ai lu
ta réponse j'ai immédiatement pensé à cette phrase de Jean Cocteau :

"Puisque ces choses nous dépassent, feignons den être les
instigateurs."

Ce que je constate c'est :

1°) que sur ce fil tu es arrivé après la bataille, pour donner des
leçons comme à ton habitude et essayer de tirer les marrons du feu ;

2°) qu'en 2008, au cours d'une discussion sur le site du zéro,
quelqu'un a affirmé dans un message, entre autres que la Norme
assurait que (sizeof(short) <= sizeof(int)) && (sizeof(int) <= sizeof
(long)), et tu as répondu à son message sur un tout autre point, sans
démentir ce point particulier. Connaissant tes habitudes sur le site
du zéro, je crois que tu aurais démenti si tu avais su que c'était
faux.

Le message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510043

Au passage, dans ce fil, tu n'as pas manqué de montrer ta
méconnaissance totale de la Norme en démentant ce que disait un
participant, à savoir que le type int est le type naturel de
l'architecture, ce qui est pourtant bien connu si on a lu la Norme. Le
message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510253

je ne serais pas étonné de trouver des références de toi, postéri eures
à 2003 et qui affirmeraient que sizeof(short) <= sizeof(int).

Je te trouve d'autant moins d'excuses à venir me/nous donner la leçon
avec ton

On a déjà expliqué 3zillions de fois que les types étaient défi nis par
leur plages et non par leur tailles...

(cf. ci-dessus)

qu'en fait Chris Torek sur clc t'avait donné la réponse à la question
du présent fil dans un fil que TU avais toi même ouvert en 2000. Ce
fil ouvert par toi est ici :

http://groups.google.com/group/comp.lang.c/msg/f8fcf15e577303bf

et la réponse que donne Chis Torek (et qui y propose une
implémentation conforme vérifiant sizeof(int) == 14 et sizeof(long) ==
3) est ici :

http://groups.google.com/group/comp.lang.c/msg/812d58fb3c86f3a2

Je précise tout de suite à ceux qui pourraient penser que j'ai voulu
te piéger : j'ai découvert ces fils bien APRES d'avoir posté ma
question ici sur fclc et j'ai même évité de te citer quand j'avais lu
ici que sizeof(short) <= sizeof(int). C'est ta réponse d'un
_incroyable__toupet_ qui m'oblige à te dire les choses sur le ton
approprié, fort peu courtois, je n'en disconviens pas mais après tout,
le manque de courtoisie, le lynchage de débutant dont tu as fait
couramment preuve et ton arrogance naturelle couplé au manque de
fiabilité de tes réponses t'exposent à ce genre de retour.

Je dois aussi citer tes erreurs passées ?

Mes erreurs du passés ? Ce n'est pas le terme approprié car je ne me
suis jamais présenté comme un expert mais plutôt comme un candide qui
revendique ses errements au cours de son apprentissage du C !! Je l'
ai appris pratiquement en direct sur fclc, mon premier message date de
la mi-août 2005.

Ce qui compte, ce n'est pas l'historique,

SI. Ce que tu as dit en 2003 alors que tu étais déjà un programmeur
aguerri aurait dû t'inviter à plus d'humilité (et aurait même dû
t'inciter à t'abstenir de répondre plutôt que de venir fanfaronner).

mais l'état des lieux tel
qu'il est affirmé à ce jour, c'est à dire, par exemple, sur mon
site ...

Je crois que parfois tu ne te rends pas compte du grotesque de tes
propos.

Je ne vais pas parler de ton site mais plutôt de la FAQ C de
Developpez (site qui contient un forum C dont tu es modérateur-
rédacteur-grand_manitou_aux_15000_messages) et qui affirme que la
Norme dit que sizeof(short)<=sizeof(int) <=sizeof(long). Commence déj à
par balayer devant ta porte, c'est une mesure de salubrité.

Vous avez filtré cet utilisateur ! Consultez son message

On 27 juil, 15:23, -ed- wrote:

2003 ? Oui, c'est possible.

Possible ? C'est même certain. Mais à propos, en 2003, tu avais déj à
combien d'années de C en tant que professionnel ? 15 ans ? Et tu
étalais ta morgue sur les forums C de Usenet depuis combien d'années ?
4 ans ? Donc l'année 2003 ne fait rien à l'affaire.

Et sans compter que je ne suis pas certain que tu savais, aujourd'hui,
en 2009, que sizeof (int) > sizeof(long) était possible. Quand j'ai lu
ta réponse j'ai immédiatement pensé à cette phrase de Jean Cocteau :

"Puisque ces choses nous dépassent, feignons den être les
instigateurs."

Ce que je constate c'est :

1°) que sur ce fil tu es arrivé après la bataille, pour donner des
leçons comme à ton habitude et essayer de tirer les marrons du feu ;

2°) qu'en 2008, au cours d'une discussion sur le site du zéro,
quelqu'un a affirmé dans un message, entre autres que la Norme
assurait que (sizeof(short) <= sizeof(int)) && (sizeof(int) <= sizeof
(long)), et tu as répondu à son message sur un tout autre point, sans
démentir ce point particulier. Connaissant tes habitudes sur le site
du zéro, je crois que tu aurais démenti si tu avais su que c'était
faux.

Le message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510043

Au passage, dans ce fil, tu n'as pas manqué de montrer ta
méconnaissance totale de la Norme en démentant ce que disait un
participant, à savoir que le type int est le type naturel de
l'architecture, ce qui est pourtant bien connu si on a lu la Norme. Le
message est ici :
http://www.siteduzero.com/forum-83-276415-p1-le-temps-existe-ou-pas.html#r2 510253

je ne serais pas étonné de trouver des références de toi, postéri eures
à 2003 et qui affirmeraient que sizeof(short) <= sizeof(int).

Je te trouve d'autant moins d'excuses à venir me/nous donner la leçon
avec ton

On a déjà expliqué 3zillions de fois que les types étaient défi nis par
leur plages et non par leur tailles...

(cf. ci-dessus)

qu'en fait Chris Torek sur clc t'avait donné la réponse à la question
du présent fil dans un fil que TU avais toi même ouvert en 2000. Ce
fil ouvert par toi est ici :

http://groups.google.com/group/comp.lang.c/msg/f8fcf15e577303bf

et la réponse que donne Chis Torek (et qui y propose une
implémentation conforme vérifiant sizeof(int) == 14 et sizeof(long) ==
3) est ici :

http://groups.google.com/group/comp.lang.c/msg/812d58fb3c86f3a2

Je précise tout de suite à ceux qui pourraient penser que j'ai voulu
te piéger : j'ai découvert ces fils bien APRES d'avoir posté ma
question ici sur fclc et j'ai même évité de te citer quand j'avais lu
ici que sizeof(short) <= sizeof(int). C'est ta réponse d'un
_incroyable__toupet_ qui m'oblige à te dire les choses sur le ton
approprié, fort peu courtois, je n'en disconviens pas mais après tout,
le manque de courtoisie, le lynchage de débutant dont tu as fait
couramment preuve et ton arrogance naturelle couplé au manque de
fiabilité de tes réponses t'exposent à ce genre de retour.

Je dois aussi citer tes erreurs passées ?

Mes erreurs du passés ? Ce n'est pas le terme approprié car je ne me
suis jamais présenté comme un expert mais plutôt comme un candide qui
revendique ses errements au cours de son apprentissage du C !! Je l'
ai appris pratiquement en direct sur fclc, mon premier message date de
la mi-août 2005.

Ce qui compte, ce n'est pas l'historique,

SI. Ce que tu as dit en 2003 alors que tu étais déjà un programmeur
aguerri aurait dû t'inviter à plus d'humilité (et aurait même dû
t'inciter à t'abstenir de répondre plutôt que de venir fanfaronner).

mais l'état des lieux tel
qu'il est affirmé à ce jour, c'est à dire, par exemple, sur mon
site ...

Je crois que parfois tu ne te rends pas compte du grotesque de tes
propos.

Je ne vais pas parler de ton site mais plutôt de la FAQ C de
Developpez (site qui contient un forum C dont tu es modérateur-
rédacteur-grand_manitou_aux_15000_messages) et qui affirme que la
Norme dit que sizeof(short)<=sizeof(int) <=sizeof(long). Commence déj à
par balayer devant ta porte, c'est une mesure de salubrité.

sizeof(short)

10 réponses

Veuillez sélectionner un problème