Je dois comparer le produit de plusieurs int à une constante (dans une
macro). Typiquement :
#define LIMITE 512*1024*1024
int a,b,c;
...
if(a*b*c<LIMITE) ...
Comment faire ça proprement si LIMITE et le produit sont supérieurs à
INT_MAX ? Notamment :
- quel type pour LIMITE ;
- comment écririez-vous la comparaison ?
Le but étant la lisibilité et la portabilité, pas la performance.
Pour LIMITE je suppose qu'il faut opter pour long long int, parce qu'avec
unsigned int je vais buter sur 4 gigas. Mais je pourrais aussi utiliser
un flottant s'il est plus portable (une petite erreur d'arrondi n'est pas
grave dans mon contexte).
Si déjà les développeurs pouvaient être conforme à Posix quelque chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT pas la direction suivie.
Sans compter que pour un système qui serait un peu à la traîne, Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment important par rapport à :2001/:2004, du fait du nombre important d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au cas où quelques commandes historiques viendraient de BSD plutôt que de SysV...
Antoine
JKB écrivit :
Si déjà les développeurs pouvaient être conforme à Posix quelque
chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce
serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un
assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT
pas la direction suivie.
Sans compter que pour un système qui serait un peu à la traîne,
Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment
important par rapport à :2001/:2004, du fait du nombre important
d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction
entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de
viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au
cas où quelques commandes historiques viendraient de BSD plutôt que de
SysV...
Si déjà les développeurs pouvaient être conforme à Posix quelque chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT pas la direction suivie.
Sans compter que pour un système qui serait un peu à la traîne, Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment important par rapport à :2001/:2004, du fait du nombre important d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au cas où quelques commandes historiques viendraient de BSD plutôt que de SysV...
Antoine
JKB
Le Wed, 22 Sep 2010 19:52:57 +0200, Antoine Leca écrivait :
JKB écrivit :
Si déjà les développeurs pouvaient être conforme à Posix quelque chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT pas la direction suivie.
Nous sommes bien d'accord. Et je passe sur les conneries avec la mémoire qui ne fonctionnent que sur x86. Des histoires d'alignement mémoire qui plantent partout ailleurs ! Il y en a encore un dans seamonkey. Quant à OpenOffice, je n'en parle même pas...
Sans compter que pour un système qui serait un peu à la traîne, Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment important par rapport à :2001/:2004, du fait du nombre important d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au cas où quelques commandes historiques viendraient de BSD plutôt que de SysV...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 22 Sep 2010 19:52:57 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
JKB écrivit :
Si déjà les développeurs pouvaient être conforme à Posix quelque
chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce
serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un
assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT
pas la direction suivie.
Nous sommes bien d'accord. Et je passe sur les conneries avec la
mémoire qui ne fonctionnent que sur x86. Des histoires d'alignement
mémoire qui plantent partout ailleurs ! Il y en a encore un dans
seamonkey. Quant à OpenOffice, je n'en parle même pas...
Sans compter que pour un système qui serait un peu à la traîne,
Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment
important par rapport à :2001/:2004, du fait du nombre important
d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction
entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de
viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au
cas où quelques commandes historiques viendraient de BSD plutôt que de
SysV...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 22 Sep 2010 19:52:57 +0200, Antoine Leca écrivait :
JKB écrivit :
Si déjà les développeurs pouvaient être conforme à Posix quelque chose ou SysV, plutôt que d'être conforme Linux ou FreeBSD sur x86, ce serait vraiment bien. Certains jours, je rêve de ça...
Mon impression pour regarder cela de plus près ces temps-ci (après un assez long moment plus éloigné du sujet), c'est que ce n'est VRAIMENT pas la direction suivie.
Nous sommes bien d'accord. Et je passe sur les conneries avec la mémoire qui ne fonctionnent que sur x86. Des histoires d'alignement mémoire qui plantent partout ailleurs ! Il y en a encore un dans seamonkey. Quant à OpenOffice, je n'en parle même pas...
Sans compter que pour un système qui serait un peu à la traîne, Posix:2008 (au sens strict, pas X/Open) représente un effort vraiment important par rapport à :2001/:2004, du fait du nombre important d'interface qui sont passées de optionnelles à obligatoires.
En fait, je me demande à quoi cela sert de toujours avoir la distinction entre les deux, il semblerait qu'aujourd'hui un vendeur se doive de viser X/Open (actuellement) 7, quitte à officiellement couvrir Posix au cas où quelques commandes historiques viendraient de BSD plutôt que de SysV...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement a ce que les zones en bordure fassent des segfault...
In article <slrni9kdb3.scv.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs
diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on
a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement
a ce que les zones en bordure fassent des segfault...
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement a ce que les zones en bordure fassent des segfault...
JKB
Le Wed, 22 Sep 2010 22:22:57 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Encore que NetBSD, FreeBSD et Linux sont beaucoup plus conformes que OpenBSD, surtout lorsqu'on parle de conformité Posix 2001. Et il y a des systèmes prétendûment Posix (comme MacOS X ou Solaris) qui ne le sont pas plus qu'un Linux brut de fonderie.
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement a ce que les zones en bordure fassent des segfault...
Peut-être. Maintenant, s'il faut pour avoir ce genre de fonctionnement avoir un OS qui se tire une balle dans le pied dès qu'on mélange la libpthread avec des trucs comme les piles alternatives, je préfère encore coder sur du Linux en me restreignant à POSIX ou SysV et en vérifiant avec des outils comme valgrind.
Je n'ai pas regardé comment fonctionne cette chose, mais s'il fonctionne de la même façon que efence, c'est inutilisable sur la plupart des programmes sérieux.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 22 Sep 2010 22:22:57 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni9kdb3.scv.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Encore que NetBSD, FreeBSD et Linux sont beaucoup plus conformes que
OpenBSD, surtout lorsqu'on parle de conformité Posix 2001. Et il y a
des systèmes prétendûment Posix (comme MacOS X ou Solaris) qui ne le
sont pas plus qu'un Linux brut de fonderie.
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs
diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on
a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement
a ce que les zones en bordure fassent des segfault...
Peut-être. Maintenant, s'il faut pour avoir ce genre de
fonctionnement avoir un OS qui se tire une balle dans le pied dès
qu'on mélange la libpthread avec des trucs comme les piles
alternatives, je préfère encore coder sur du Linux en me
restreignant à POSIX ou SysV et en vérifiant avec des outils comme
valgrind.
Je n'ai pas regardé comment fonctionne cette chose, mais s'il
fonctionne de la même façon que efence, c'est inutilisable sur la
plupart des programmes sérieux.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 22 Sep 2010 22:22:57 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Encore que NetBSD, FreeBSD et Linux sont beaucoup plus conformes que OpenBSD, surtout lorsqu'on parle de conformité Posix 2001. Et il y a des systèmes prétendûment Posix (comme MacOS X ou Solaris) qui ne le sont pas plus qu'un Linux brut de fonderie.
A cote de ca, il y a des points sur lesquels OpenBSD te donnera de meilleurs diagnostics... t'as pas idee du nombre de buffer overflow et underflow qu'on a vu passer un peu partout depuis qu'on a un malloc qui vise systematiquement a ce que les zones en bordure fassent des segfault...
Peut-être. Maintenant, s'il faut pour avoir ce genre de fonctionnement avoir un OS qui se tire une balle dans le pied dès qu'on mélange la libpthread avec des trucs comme les piles alternatives, je préfère encore coder sur du Linux en me restreignant à POSIX ou SysV et en vérifiant avec des outils comme valgrind.
Je n'ai pas regardé comment fonctionne cette chose, mais s'il fonctionne de la même façon que efence, c'est inutilisable sur la plupart des programmes sérieux.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
C'est inutile sur les programmes serieux, qui par definition, sont codes correctement. ;-) par contre, sur les programmes reels codes avec les pieds, ca marche bien. Par exemple, on a du corriger deux/trois bugs qui empechaient de compiler openoffice (eh oui, buffer underflow en pagaille dans dmake).
Tout betement, c'est actif par defaut, et c'est juste malloc qui a tendance a te faire des trous dans l'espace memoire vu par un processus, et a placer pas mal d'allocations memoire en bordure de trou. Si tu en veux un peu plus, il y a des options pour ca (malloc regarde une variable d'environnement a l'initialisation), qui vont bouffer un peu plus de place/un peu de CPU.
Il y a eu un enorme boulot de fait pour que ca bouffe peu de ressources. En particulier, ca serait pas actif par defaut si ca avait un reel impact.
In article <slrni9luad.scv.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
C'est inutile sur les programmes serieux, qui par definition, sont codes
correctement. ;-) par contre, sur les programmes reels codes avec les pieds,
ca marche bien. Par exemple, on a du corriger deux/trois bugs qui empechaient
de compiler openoffice (eh oui, buffer underflow en pagaille dans dmake).
Tout betement, c'est actif par defaut, et c'est juste malloc qui a tendance
a te faire des trous dans l'espace memoire vu par un processus, et a placer
pas mal d'allocations memoire en bordure de trou. Si tu en veux un peu plus,
il y a des options pour ca (malloc regarde une variable d'environnement a
l'initialisation), qui vont bouffer un peu plus de place/un peu de CPU.
Il y a eu un enorme boulot de fait pour que ca bouffe peu de ressources.
En particulier, ca serait pas actif par defaut si ca avait un reel impact.
C'est inutile sur les programmes serieux, qui par definition, sont codes correctement. ;-) par contre, sur les programmes reels codes avec les pieds, ca marche bien. Par exemple, on a du corriger deux/trois bugs qui empechaient de compiler openoffice (eh oui, buffer underflow en pagaille dans dmake).
Tout betement, c'est actif par defaut, et c'est juste malloc qui a tendance a te faire des trous dans l'espace memoire vu par un processus, et a placer pas mal d'allocations memoire en bordure de trou. Si tu en veux un peu plus, il y a des options pour ca (malloc regarde une variable d'environnement a l'initialisation), qui vont bouffer un peu plus de place/un peu de CPU.
Il y a eu un enorme boulot de fait pour que ca bouffe peu de ressources. En particulier, ca serait pas actif par defaut si ca avait un reel impact.
