bibliotheque et fichiers d'en-tete pour l'utilisateur
50 réponses
Vincent Lefevre
Bonjour et bonne année,
J'aimerais avoir votre avis sur le point suivant (je n'ai pas vu
d'indications dans les FAQ). Dans la bibliothèque qu'on développe
(MPFR), il y a des fonctions qui ne sont liées aucunement à la
bibliothèque standard et d'autres qui sont liées à certaines choses
de <stdio.h> (par exemple utilisent FILE en argument, parce que ce
sont des fonctions d'entrées/sorties). Y a-t-il une ou des solutions
recommandées concernant les fichiers d'en-tête fournis par la
bibliothèque (pour l'utilisateur de la bibliothèque), avec une
volonté de portabilité?
1) La solution actuelle est celle de GMP, qui est d'essayer de
détecter automatiquement si <stdio.h> a été #inclus avant gmp.h,
auquel cas gmp.h déclare les fonctions d'entrées/sorties. Mais cela
pose notamment deux gros problèmes: comme il n'y a pas de standard
pour cette détection, cela risque d'échouer sur les plateformes non
testées (et cela arrive en pratique) ou à cause de changements futurs
sur les plateformes existantes (cf tous les problèmes qu'a posés le
changement lié au errno dans la glibc); d'autre part, cette méthode
empiète sur le domaine de l'utilisateur. Par exemple, le programme
suivant ne compile pas:
#define H_STDIO 1
#include <gmp.h>
int main(void)
{
return 0;
}
(à noter que H_STDIO ne fait pas partie des macros réservées par GMP,
qui commencent par "GMP_", par convention).
2) Il y a la solution d'inclure systématiquement <stdio.h> dans le
fichier d'en-tête qu'on fournit (mpfr.h), éventuellement sauf si telle
macro, e.g. MPFR_NO_STDIO, est définie auparavant par l'utilisateur
(évidemment, tout cela devant être parfaitement documenté...).
3) Il y a la solution de fournir plusieurs fichiers d'en-tête, e.g.
mpfr.h et mpfrIO.h, où <stdio.h> n'est inclus que dans "mpfrIO.h".
C'est une sorte de (2) modulaire.
Dans les quelques bibliothèques que j'ai regardées (à part GMP), c'est
soit (2) sans la possibilité d'empêcher l'inclusion, soit (3).
Pour info, ma préférence personnelle va pour (3), pour son aspect
modulaire en particulier.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin qui vont forcer a reordonner les choses, voire a enlever des entetes ou a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est infiniment plus simple de faire les corrections localement, dans le fichier C qui pose probleme, que de devoir mettre en place des solutions plus bancales dans un fichier d'entete qui inclut la terre et l'univers. (et invariablement, sur un gros projet, on va tot ou tard se retrouver avec des autres d'inclusion foireux, avec un fichier qui veut #include <a.h> #include <b.h> et l'autre #include <b.h> #include <a.h>)
Non. Un fichier .h doit être parszable sans autre inclusion. L'utilisateur de tas bibliothèque ne doit pas avoir à inclure d'en-tête pour autre chose que pour les fonctions que *lui* utilise.
espie@tetto.gentiane.org (Marc Espie) écrivait :
Je prefere de tres, tres, tres loin la solution qui consiste a laisser
les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma
bibliotheque qu'il doit utiliser
#include <stdio.h>
#include <foo.h>
dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin
qui vont forcer a reordonner les choses, voire a enlever des entetes ou
a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est
infiniment plus simple de faire les corrections localement, dans le
fichier C qui pose probleme, que de devoir mettre en place des solutions
plus bancales dans un fichier d'entete qui inclut la terre et l'univers.
(et invariablement, sur un gros projet, on va tot ou tard se retrouver
avec des autres d'inclusion foireux, avec un fichier qui veut
#include <a.h>
#include <b.h>
et l'autre
#include <b.h>
#include <a.h>)
Non. Un fichier .h doit être parszable sans autre
inclusion. L'utilisateur de tas bibliothèque ne doit pas avoir à
inclure d'en-tête pour autre chose que pour les fonctions que *lui*
utilise.
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin qui vont forcer a reordonner les choses, voire a enlever des entetes ou a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est infiniment plus simple de faire les corrections localement, dans le fichier C qui pose probleme, que de devoir mettre en place des solutions plus bancales dans un fichier d'entete qui inclut la terre et l'univers. (et invariablement, sur un gros projet, on va tot ou tard se retrouver avec des autres d'inclusion foireux, avec un fichier qui veut #include <a.h> #include <b.h> et l'autre #include <b.h> #include <a.h>)
Non. Un fichier .h doit être parszable sans autre inclusion. L'utilisateur de tas bibliothèque ne doit pas avoir à inclure d'en-tête pour autre chose que pour les fonctions que *lui* utilise.
Erwan David
(Marc Espie) écrivait :
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin qui vont forcer a reordonner les choses, voire a enlever des entetes ou a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est infiniment plus simple de faire les corrections localement, dans le fichier C qui pose probleme, que de devoir mettre en place des solutions plus bancales dans un fichier d'entete qui inclut la terre et l'univers. (et invariablement, sur un gros projet, on va tot ou tard se retrouver avec des autres d'inclusion foireux, avec un fichier qui veut #include <a.h> #include <b.h> et l'autre #include <b.h> #include <a.h>)
Euh, je ne vois pas ce qui pourrais provoquer ça. Les problèmes d'ordre d'inclusion apparaissent quand a.h n'inclus pas b.h mais n'est pas parsable sans l'avoir inclus (par exemple parceque a.h déclare une fonction utilisant un type déclaré dans b.h)
C'est pour éviter ce genre de problème que je préfère nettement la garde systématique contre les inclusions multiples et l'inclusion systématique dans tous les en-têtes de ce qu'il faut pour pouvoir les parser.
espie@tetto.gentiane.org (Marc Espie) écrivait :
Je prefere de tres, tres, tres loin la solution qui consiste a laisser
les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma
bibliotheque qu'il doit utiliser
#include <stdio.h>
#include <foo.h>
dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin
qui vont forcer a reordonner les choses, voire a enlever des entetes ou
a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est
infiniment plus simple de faire les corrections localement, dans le
fichier C qui pose probleme, que de devoir mettre en place des solutions
plus bancales dans un fichier d'entete qui inclut la terre et l'univers.
(et invariablement, sur un gros projet, on va tot ou tard se retrouver
avec des autres d'inclusion foireux, avec un fichier qui veut
#include <a.h>
#include <b.h>
et l'autre
#include <b.h>
#include <a.h>)
Euh, je ne vois pas ce qui pourrais provoquer ça. Les problèmes
d'ordre d'inclusion apparaissent quand a.h n'inclus pas b.h mais n'est
pas parsable sans l'avoir inclus (par exemple parceque a.h déclare une
fonction utilisant un type déclaré dans b.h)
C'est pour éviter ce genre de problème que je préfère nettement la
garde systématique contre les inclusions multiples et l'inclusion
systématique dans tous les en-têtes de ce qu'il faut pour pouvoir les
parser.
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
D'experience, il y a toujours, toujours des bouts foireux dans un coin qui vont forcer a reordonner les choses, voire a enlever des entetes ou a reordonner des trucs sur certains systemes. Dans ce cas-la, c'est infiniment plus simple de faire les corrections localement, dans le fichier C qui pose probleme, que de devoir mettre en place des solutions plus bancales dans un fichier d'entete qui inclut la terre et l'univers. (et invariablement, sur un gros projet, on va tot ou tard se retrouver avec des autres d'inclusion foireux, avec un fichier qui veut #include <a.h> #include <b.h> et l'autre #include <b.h> #include <a.h>)
Euh, je ne vois pas ce qui pourrais provoquer ça. Les problèmes d'ordre d'inclusion apparaissent quand a.h n'inclus pas b.h mais n'est pas parsable sans l'avoir inclus (par exemple parceque a.h déclare une fonction utilisant un type déclaré dans b.h)
C'est pour éviter ce genre de problème que je préfère nettement la garde systématique contre les inclusions multiples et l'inclusion systématique dans tous les en-têtes de ce qu'il faut pour pouvoir les parser.
Jean-Marc Bourguet
(Marc Espie) writes:
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
J'ai horreur de devoir documenter ce qui n'est que des details d'implementation. Et j'ai horreur de devoir changer 5000 fichiers parce que ces details changent. Au mieux c'est maintenant j'ai besoin de foo.h, j'ai a le rajouter ou? Mince, j'ai pas les droits sur ce fichier... Si c'est je n'ai plus besoin de foo.h, d'ou est-ce que je dois le supprimer ca a de bonne chance de ne jamais etre fait.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@tetto.gentiane.org (Marc Espie) writes:
Je prefere de tres, tres, tres loin la solution qui consiste a laisser
les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma
bibliotheque qu'il doit utiliser
#include <stdio.h>
#include <foo.h>
dans le synopsis que de faire les choses a sa place.
J'ai horreur de devoir documenter ce qui n'est que des details
d'implementation. Et j'ai horreur de devoir changer 5000 fichiers
parce que ces details changent. Au mieux c'est maintenant j'ai besoin
de foo.h, j'ai a le rajouter ou? Mince, j'ai pas les droits sur ce
fichier... Si c'est je n'ai plus besoin de foo.h, d'ou est-ce que je
dois le supprimer ca a de bonne chance de ne jamais etre fait.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je prefere de tres, tres, tres loin la solution qui consiste a laisser les entetes a plat.
Il est pour moi infiniment preferable d'expliquer a l'utilisateur de ma bibliotheque qu'il doit utiliser #include <stdio.h> #include <foo.h> dans le synopsis que de faire les choses a sa place.
J'ai horreur de devoir documenter ce qui n'est que des details d'implementation. Et j'ai horreur de devoir changer 5000 fichiers parce que ces details changent. Au mieux c'est maintenant j'ai besoin de foo.h, j'ai a le rajouter ou? Mince, j'ai pas les droits sur ce fichier... Si c'est je n'ai plus besoin de foo.h, d'ou est-ce que je dois le supprimer ca a de bonne chance de ne jamais etre fait.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Vincent Lefevre <vincent+ writes:
| _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas | <stdio.h> et ne déclare pas les prototypes en dépendant (comme si | les fonctions d'entrées/sorties n'existaient pas).
As-tu un cas concret -- pas une hypothèse ?
Cas concret de quoi? Tu veux dire que toutes les implémentations freestanding ont un <stdio.h> (comme je ne connais pas, dans le doute...)?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <m3brpfnx8q.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas
| <stdio.h> et ne déclare pas les prototypes en dépendant (comme si
| les fonctions d'entrées/sorties n'existaient pas).
As-tu un cas concret -- pas une hypothèse ?
Cas concret de quoi? Tu veux dire que toutes les implémentations
freestanding ont un <stdio.h> (comme je ne connais pas, dans le
doute...)?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
| _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas | <stdio.h> et ne déclare pas les prototypes en dépendant (comme si | les fonctions d'entrées/sorties n'existaient pas).
As-tu un cas concret -- pas une hypothèse ?
Cas concret de quoi? Tu veux dire que toutes les implémentations freestanding ont un <stdio.h> (comme je ne connais pas, dans le doute...)?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre
Dans l'article , Emmanuel Delahaye écrit:
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car la norme dit:
[#6] The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A [...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les implémentations freestanding fournissent un <stdio.h> similaire à de l'hébergé, alors OK.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <Xns9469D10A3DAA7hsnoservernet@212.198.2.12>,
Emmanuel Delahaye <emdelYOURBRA@noos.fr> écrit:
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek,
Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs
pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car
la norme dit:
[#6] The two forms of conforming implementation are hosted
and freestanding. A conforming hosted implementation shall
accept any strictly conforming program. A conforming
freestanding implementation shall accept any strictly
conforming program that does not use complex types and in
which the use of the features specified in the library
clause (clause 7) is confined to the contents of the
standard headers <float.h>, <iso646.h>, <limits.h>,
<stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
[...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les
implémentations freestanding fournissent un <stdio.h> similaire
à de l'hébergé, alors OK.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car la norme dit:
[#6] The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A [...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les implémentations freestanding fournissent un <stdio.h> similaire à de l'hébergé, alors OK.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Erwan David
Vincent Lefevre <vincent+ écrivait :
Dans l'article , Emmanuel Delahaye écrit:
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car la norme dit:
[#6] The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A [...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les implémentations freestanding fournissent un <stdio.h> similaire à de l'hébergé, alors OK.
Non. Si tu es en freestanding tu n'utilise *pas* stdio.h Jamais.
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Dans l'article <Xns9469D10A3DAA7hsnoservernet@212.198.2.12>,
Emmanuel Delahaye <emdelYOURBRA@noos.fr> écrit:
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek,
Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs
pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car
la norme dit:
[#6] The two forms of conforming implementation are hosted
and freestanding. A conforming hosted implementation shall
accept any strictly conforming program. A conforming
freestanding implementation shall accept any strictly
conforming program that does not use complex types and in
which the use of the features specified in the library
clause (clause 7) is confined to the contents of the
standard headers <float.h>, <iso646.h>, <limits.h>,
<stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
[...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les
implémentations freestanding fournissent un <stdio.h> similaire
à de l'hébergé, alors OK.
Non. Si tu es en freestanding tu n'utilise *pas* stdio.h
Jamais.
Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
Je pensais qu'il pouvait éventuellement y avoir des problèmes, car la norme dit:
[#6] The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A [...]
<stdio.h> n'est pas dans la liste. Maintenant, si toutes les implémentations freestanding fournissent un <stdio.h> similaire à de l'hébergé, alors OK.
Non. Si tu es en freestanding tu n'utilise *pas* stdio.h Jamais.
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas | > | <stdio.h> et ne déclare pas les prototypes en dépendant (comme si | > | les fonctions d'entrées/sorties n'existaient pas). | | > As-tu un cas concret -- pas une hypothèse ? | | Cas concret de quoi? Tu veux dire que toutes les implémentations | freestanding ont un <stdio.h> (comme je ne connais pas, dans le | doute...)?
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien compris utilise GMP) ET où l'environment est freestanding.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux imaginer de telles situations, mais elles ne se réalisent que dans l'abstrait, i.e. pas concretement.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3brpfnx8q.fsf@uniton.integrable-solutions.net>,
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
|
| > Vincent Lefevre <vincent+news@vinc17.org> writes:
|
| > | _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas
| > | <stdio.h> et ne déclare pas les prototypes en dépendant (comme si
| > | les fonctions d'entrées/sorties n'existaient pas).
|
| > As-tu un cas concret -- pas une hypothèse ?
|
| Cas concret de quoi? Tu veux dire que toutes les implémentations
| freestanding ont un <stdio.h> (comme je ne connais pas, dans le
| doute...)?
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien
compris utilise GMP) ET où l'environment est freestanding.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux
imaginer de telles situations, mais elles ne se réalisent que dans
l'abstrait, i.e. pas concretement.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | _ Si MPFR_NO_STDIO est définie (cas rare), alors mpfr.h n'inclut pas | > | <stdio.h> et ne déclare pas les prototypes en dépendant (comme si | > | les fonctions d'entrées/sorties n'existaient pas). | | > As-tu un cas concret -- pas une hypothèse ? | | Cas concret de quoi? Tu veux dire que toutes les implémentations | freestanding ont un <stdio.h> (comme je ne connais pas, dans le | doute...)?
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien compris utilise GMP) ET où l'environment est freestanding.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux imaginer de telles situations, mais elles ne se réalisent que dans l'abstrait, i.e. pas concretement.
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Emmanuel Delahaye écrit: | | > Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, | > Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs | > pas pourquoi il y aurait plus de problèmes qu'avec du hosted... | | Je pensais qu'il pouvait éventuellement y avoir des problèmes, car | la norme dit: | | [#6] The two forms of conforming implementation are hosted | and freestanding. A conforming hosted implementation shall | accept any strictly conforming program. A conforming | freestanding implementation shall accept any strictly | conforming program that does not use complex types and in | which the use of the features specified in the library | clause (clause 7) is confined to the contents of the | standard headers <float.h>, <iso646.h>, <limits.h>, | <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A | [...] | | <stdio.h> n'est pas dans la liste. Maintenant, si toutes les | implémentations freestanding fournissent un <stdio.h> similaire | à de l'hébergé, alors OK.
Je suis étonné de voir que tu te préoccupes plus de <stdio.h> que de <stdlib.h> -- qui contient malloc().
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <Xns9469D10A3DAA7hsnoservernet@212.198.2.12>,
| Emmanuel Delahaye <emdelYOURBRA@noos.fr> écrit:
|
| > Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek,
| > Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs
| > pas pourquoi il y aurait plus de problèmes qu'avec du hosted...
|
| Je pensais qu'il pouvait éventuellement y avoir des problèmes, car
| la norme dit:
|
| [#6] The two forms of conforming implementation are hosted
| and freestanding. A conforming hosted implementation shall
| accept any strictly conforming program. A conforming
| freestanding implementation shall accept any strictly
| conforming program that does not use complex types and in
| which the use of the features specified in the library
| clause (clause 7) is confined to the contents of the
| standard headers <float.h>, <iso646.h>, <limits.h>,
| <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
| [...]
|
| <stdio.h> n'est pas dans la liste. Maintenant, si toutes les
| implémentations freestanding fournissent un <stdio.h> similaire
| à de l'hébergé, alors OK.
Je suis étonné de voir que tu te préoccupes plus de <stdio.h> que de
<stdlib.h> -- qui contient malloc().
| Dans l'article , | Emmanuel Delahaye écrit: | | > Bah, j'en utilise depuis plus de 10 ans (Intermetrics, Microtek, | > Texas, Diab). Jamais eu de problème avec ça. Je ne vois d'ailleurs | > pas pourquoi il y aurait plus de problèmes qu'avec du hosted... | | Je pensais qu'il pouvait éventuellement y avoir des problèmes, car | la norme dit: | | [#6] The two forms of conforming implementation are hosted | and freestanding. A conforming hosted implementation shall | accept any strictly conforming program. A conforming | freestanding implementation shall accept any strictly | conforming program that does not use complex types and in | which the use of the features specified in the library | clause (clause 7) is confined to the contents of the | standard headers <float.h>, <iso646.h>, <limits.h>, | <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A | [...] | | <stdio.h> n'est pas dans la liste. Maintenant, si toutes les | implémentations freestanding fournissent un <stdio.h> similaire | à de l'hébergé, alors OK.
Je suis étonné de voir que tu te préoccupes plus de <stdio.h> que de <stdlib.h> -- qui contient malloc().
-- Gaby
Gabriel Dos Reis
Erwan David writes:
| Non. Si tu es en freestanding tu n'utilise *pas* stdio.h | Jamais.
Oui, mais alors par le même argument tu n'utilises pas GMP non plus.
-- Gaby
Erwan David <erwan@rail.eu.org> writes:
| Non. Si tu es en freestanding tu n'utilise *pas* stdio.h
| Jamais.
Oui, mais alors par le même argument tu n'utilises pas GMP non plus.
| Non. Si tu es en freestanding tu n'utilise *pas* stdio.h | Jamais.
Oui, mais alors par le même argument tu n'utilises pas GMP non plus.
-- Gaby
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien compris utilise GMP) ET où l'environment est freestanding.
Ah... Le but est de prévoir le maximum de situations possibles dès maintenant d'une part pour éviter d'avoir à faire des modifications sur certaines parties du code dans le futur (risquant par la même occasion d'y introduire des incompatibilités ou des bugs) et d'autre part pour que des utilisateurs d'environnements freestanding puissent récupérer le code et le faire fonctionner avec le moins de modifications et avec le moins de rapports de bugs.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux imaginer de telles situations, mais elles ne se réalisent que dans l'abstrait, i.e. pas concretement.
Mais comment savoir si elles vont se réaliser contrètement ou non?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <m3fzeq4a87.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien
compris utilise GMP) ET où l'environment est freestanding.
Ah... Le but est de prévoir le maximum de situations possibles dès
maintenant d'une part pour éviter d'avoir à faire des modifications
sur certaines parties du code dans le futur (risquant par la même
occasion d'y introduire des incompatibilités ou des bugs) et d'autre
part pour que des utilisateurs d'environnements freestanding
puissent récupérer le code et le faire fonctionner avec le moins de
modifications et avec le moins de rapports de bugs.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux
imaginer de telles situations, mais elles ne se réalisent que dans
l'abstrait, i.e. pas concretement.
Mais comment savoir si elles vont se réaliser contrètement ou non?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Cas concret où tu vas porter ta bibliothèque (qui, si j'ai bien compris utilise GMP) ET où l'environment est freestanding.
Ah... Le but est de prévoir le maximum de situations possibles dès maintenant d'une part pour éviter d'avoir à faire des modifications sur certaines parties du code dans le futur (risquant par la même occasion d'y introduire des incompatibilités ou des bugs) et d'autre part pour que des utilisateurs d'environnements freestanding puissent récupérer le code et le faire fonctionner avec le moins de modifications et avec le moins de rapports de bugs.
Mon hypothèse (tout à fait arrogante mais réaliste) est tu peux imaginer de telles situations, mais elles ne se réalisent que dans l'abstrait, i.e. pas concretement.
Mais comment savoir si elles vont se réaliser contrètement ou non?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
