1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restrei nt
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8. Pour
l'instant, je pense faire quelque chose comme
int is_small( size_t a )
{
if( (unsigned long) a >> 16 != 0 )
return 0;
return ((unsigned long) a + 256) >> 16 == 0;
}
pour éviter d'avoir à faire plusieurs cas selon la taille de si ze_t.
Cela vous paraît-il correct et portable ? Voyez-vous une façon plus
élégante/lisible de faire la même chose ?
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restrei nt
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8. Pour
l'instant, je pense faire quelque chose comme
int is_small( size_t a )
{
if( (unsigned long) a >> 16 != 0 )
return 0;
return ((unsigned long) a + 256) >> 16 == 0;
}
pour éviter d'avoir à faire plusieurs cas selon la taille de si ze_t.
Cela vous paraît-il correct et portable ? Voyez-vous une façon plus
élégante/lisible de faire la même chose ?
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restrei nt
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8. Pour
l'instant, je pense faire quelque chose comme
int is_small( size_t a )
{
if( (unsigned long) a >> 16 != 0 )
return 0;
return ((unsigned long) a + 256) >> 16 == 0;
}
pour éviter d'avoir à faire plusieurs cas selon la taille de si ze_t.
Cela vous paraît-il correct et portable ? Voyez-vous une façon plus
élégante/lisible de faire la même chose ?
Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;
Manuel Pégourié-Gonnard <mpg@elzevir.fr> writes:
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;
Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;
In article ,
Jean-Marc Bourguet wrote:Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type enti er d'au
moins 32 bits de large. Ce type est-il vraiment implémenté pa r tous les
compilos, y compris quand la cible est un environnement très restr eint
(genre microcontroleur 8 bits) ?
C89, c'est un peu a la bourre, on est quand meme deux revisions plus loin.
Notons que ces points n'ont pas change sur le fond.Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
Un compilateur conforme doit implementer long int avec un intervalle de v aleurs
correct (et donc un unsigned long int sur au moins 32 bits). Il faut voir si
on se limite aux compilateurs conformes ou pas...!
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être m al cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
stdint.h est C99... si Manuel cherche dans C89, c'est normal qu'il n'ait pas
trouve...Quel etait le probleme avec
return a < 0xFF00;
Ca m'a l'air parfaitement portable pour moi aussi...
In article <pxbd2g0k1tt.fsf@bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Manuel Pégourié-Gonnard <mpg@elzevir.fr> writes:
1. La norme C89 spécifie long int, qui doit être un type enti er d'au
moins 32 bits de large. Ce type est-il vraiment implémenté pa r tous les
compilos, y compris quand la cible est un environnement très restr eint
(genre microcontroleur 8 bits) ?
C89, c'est un peu a la bourre, on est quand meme deux revisions plus loin.
Notons que ces points n'ont pas change sur le fond.
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
Un compilateur conforme doit implementer long int avec un intervalle de v aleurs
correct (et donc un unsigned long int sur au moins 32 bits). Il faut voir si
on se limite aux compilateurs conformes ou pas...!
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être m al cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
stdint.h est C99... si Manuel cherche dans C89, c'est normal qu'il n'ait pas
trouve...
Quel etait le probleme avec
return a < 0xFF00;
Ca m'a l'air parfaitement portable pour moi aussi...
In article ,
Jean-Marc Bourguet wrote:Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type enti er d'au
moins 32 bits de large. Ce type est-il vraiment implémenté pa r tous les
compilos, y compris quand la cible est un environnement très restr eint
(genre microcontroleur 8 bits) ?
C89, c'est un peu a la bourre, on est quand meme deux revisions plus loin.
Notons que ces points n'ont pas change sur le fond.Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
Un compilateur conforme doit implementer long int avec un intervalle de v aleurs
correct (et donc un unsigned long int sur au moins 32 bits). Il faut voir si
on se limite aux compilateurs conformes ou pas...!
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être m al cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
stdint.h est C99... si Manuel cherche dans C89, c'est normal qu'il n'ait pas
trouve...Quel etait le probleme avec
return a < 0xFF00;
Ca m'a l'air parfaitement portable pour moi aussi...
Quelques petites questions sur les types entiers :
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8.
Quelques petites questions sur les types entiers :
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8.
Quelques petites questions sur les types entiers :
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
Ce qui motive ces deux questions, c'est que je dois tester si une valeur
de type size_t est ou non strictement inférieure à 2^16 - 2^8.
Quel etait le probleme avec
return a < 0xFF00;
Quel etait le probleme avec
return a < 0xFF00;
Quel etait le probleme avec
return a < 0xFF00;
Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
In article <ljolug$2d1$,
Antoine Leca wrote:Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
Je suis maintenant encore plus convaincu qu'il *faut* le plus possible,
le plus souvent possible eviter la prise de tete.
Le projet OpenBSD est en train de nettoyer le code d'OpenSSL, apres la
magnifique faille HeartBleed. Eh bien, c'est terrifiant tout le code
hyper-crade "refait a la main" qu'on trouve un peu partout, souvent
parce que tel compilo ante-diluvien ne supportait pas tel ou tel truc.
In article <ljolug$2d1$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
Je suis maintenant encore plus convaincu qu'il *faut* le plus possible,
le plus souvent possible eviter la prise de tete.
Le projet OpenBSD est en train de nettoyer le code d'OpenSSL, apres la
magnifique faille HeartBleed. Eh bien, c'est terrifiant tout le code
hyper-crade "refait a la main" qu'on trouve un peu partout, souvent
parce que tel compilo ante-diluvien ne supportait pas tel ou tel truc.
In article <ljolug$2d1$,
Antoine Leca wrote:Cf. Jean-Marc et Marc pour ce qui ne relève pas de la prise de tête.
Je suis maintenant encore plus convaincu qu'il *faut* le plus possible,
le plus souvent possible eviter la prise de tete.
Le projet OpenBSD est en train de nettoyer le code d'OpenSSL, apres la
magnifique faille HeartBleed. Eh bien, c'est terrifiant tout le code
hyper-crade "refait a la main" qu'on trouve un peu partout, souvent
parce que tel compilo ante-diluvien ne supportait pas tel ou tel truc.
On parle d'autotools? ;-)
On parle d'autotools? ;-)
On parle d'autotools? ;-)
A: bon, on vire le code de pyramid de la release
B: c'est pas cool d'enlever des ports comme ca, et si on gardait
A: j'ai suivi en detail les machines encore en etat de marche. C'est moi
qui possedais la derniere. Elle est morte avant-hier. Alors, on le vire
ce code ?
A: bon, on vire le code de pyramid de la release
B: c'est pas cool d'enlever des ports comme ca, et si on gardait
A: j'ai suivi en detail les machines encore en etat de marche. C'est moi
qui possedais la derniere. Elle est morte avant-hier. Alors, on le vire
ce code ?
A: bon, on vire le code de pyramid de la release
B: c'est pas cool d'enlever des ports comme ca, et si on gardait
A: j'ai suivi en detail les machines encore en etat de marche. C'est moi
qui possedais la derniere. Elle est morte avant-hier. Alors, on le vire
ce code ?
Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;
Manuel Pégourié-Gonnard <mpg@elzevir.fr> writes:
1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;
Manuel Pégourié-Gonnard writes:1. La norme C89 spécifie long int, qui doit être un type entier d'au
moins 32 bits de large. Ce type est-il vraiment implémenté par tous les
compilos, y compris quand la cible est un environnement très restreint
(genre microcontroleur 8 bits) ?
Aucune idee sur ce point precis, mais je sais que les compilateurs pour
microp 8 bits prennent parfois plus de libertes avec la norme que les
autres.
2. A-t-on des garanties sur la taille minimum de size_t ? Je n'ai pas
réussi à en trouver dans la norme, mais j'ai peut-être mal cherché.
SIZE_MAX vaut au moins 65535 (description de stdint.h)
Quel etait le probleme avec
return a < 0xFF00;