Je cherche un moyen de connaitre la position d'une occurence dans une chaine
J'ai essayé :
temp = strstr(bufferspace, "truc");
taille = temp-bufferspace;
Ne fonctionne pas car temp peut prendre la valeur NULL et donc le
compilateur refuse.
Etant dans l'espace noyau, je n'ai accès qu'a des fonctions sortant un
pointeur, et non la position.
Il faudrait les deux: byte pour manipuler de la mémoire brute, sans bits de padding, et (unsigned) short short int pour stocker de petits entiers (mais serait-ce vraiment utile?) avec la possibilité d'avoir des bits de padding pour cohérence avec short, int, long et long long.
-- 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 <85u18ojqd6.fsf@bretagne.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
Ou plutôt s'appeler byte ou short short int...
Il faudrait les deux: byte pour manipuler de la mémoire brute, sans
bits de padding, et (unsigned) short short int pour stocker de petits
entiers (mais serait-ce vraiment utile?) avec la possibilité d'avoir
des bits de padding pour cohérence avec short, int, long et long long.
--
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
Il faudrait les deux: byte pour manipuler de la mémoire brute, sans bits de padding, et (unsigned) short short int pour stocker de petits entiers (mais serait-ce vraiment utile?) avec la possibilité d'avoir des bits de padding pour cohérence avec short, int, long et long long.
-- 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
Gabriel Dos Reis
"Antoine Leca" writes:
[...]
| Heureusement que dans la nature, ils sont plus posés (au moins | du côté C, mais cela m'étonnerait que ce soit différent de l'autre côté). | Mais pour une fusion, je le sens pas évident, vu depuis le comité C.
de l'autræ côté, il y avait aussi des excités mais heureusement, ceux là ne sont pas « aux commandes » :-/
| Un autre aspect est que BS a le don, par son seul passé, de | déclencher des réactions exhacerbées dans le comité C, qui a des
j'ai remaqué cela. Je n'ai jamais su pourquoi. Il m'a seulement dit que certains du comité C sont encore plus durs avec DMR.
| vues passablement voire diamétralement opposées sur la « taille » | cible du ou des langages, pour s'arrêter là. | | Mais bon, le comité C n'a quand même pas ressorti de sous la | table sa proposition de rajouter les classes ? (à la mode castrée, | héritage simple, pas de surcharges, etc.)
Non, non. Il proposait un peu plus de coordination des deux côtes. Du genre, c'est pas la peine de definir une fonction nommée clog en prétendant qu'on savait pas que cela allait faire mal, ou introduire inline avec une sémantique différente. Tu vois ces genres de choses quoi. En contrepartie, il était prêt à inciter WG21 à amender le système de type de C++ pour accomoder C99. Mieux, il proposait que les deux parties nomment des gens de confiance pour former un sous-comité pour rédiger une charte et une feuille de route (et il s'excluait d'emblée de ce sous-comité).
C'est dommage que cela ait été la source d'uen flame fest tout à fait mémorable. La magie de <tgmath.h> devrait être accessible au programmeur. C'est dommage.
-- Gaby
"Antoine Leca" <root@localhost.gov> writes:
[...]
| Heureusement que dans la nature, ils sont plus posés (au moins
| du côté C, mais cela m'étonnerait que ce soit différent de l'autre côté).
| Mais pour une fusion, je le sens pas évident, vu depuis le comité C.
de l'autræ côté, il y avait aussi des excités mais heureusement, ceux
là ne sont pas « aux commandes » :-/
| Un autre aspect est que BS a le don, par son seul passé, de
| déclencher des réactions exhacerbées dans le comité C, qui a des
j'ai remaqué cela. Je n'ai jamais su pourquoi. Il m'a seulement dit
que certains du comité C sont encore plus durs avec DMR.
| vues passablement voire diamétralement opposées sur la « taille »
| cible du ou des langages, pour s'arrêter là.
|
| Mais bon, le comité C n'a quand même pas ressorti de sous la
| table sa proposition de rajouter les classes ? (à la mode castrée,
| héritage simple, pas de surcharges, etc.)
Non, non. Il proposait un peu plus de coordination des deux côtes.
Du genre, c'est pas la peine de definir une fonction nommée clog en
prétendant qu'on savait pas que cela allait faire mal, ou introduire
inline avec une sémantique différente. Tu vois ces genres de
choses quoi. En contrepartie, il était prêt à inciter WG21 à amender
le système de type de C++ pour accomoder C99. Mieux, il proposait que
les deux parties nomment des gens de confiance pour former un
sous-comité pour rédiger une charte et une feuille de route (et il
s'excluait d'emblée de ce sous-comité).
C'est dommage que cela ait été la source d'uen flame fest tout à fait
mémorable. La magie de <tgmath.h> devrait être accessible au
programmeur. C'est dommage.
| Heureusement que dans la nature, ils sont plus posés (au moins | du côté C, mais cela m'étonnerait que ce soit différent de l'autre côté). | Mais pour une fusion, je le sens pas évident, vu depuis le comité C.
de l'autræ côté, il y avait aussi des excités mais heureusement, ceux là ne sont pas « aux commandes » :-/
| Un autre aspect est que BS a le don, par son seul passé, de | déclencher des réactions exhacerbées dans le comité C, qui a des
j'ai remaqué cela. Je n'ai jamais su pourquoi. Il m'a seulement dit que certains du comité C sont encore plus durs avec DMR.
| vues passablement voire diamétralement opposées sur la « taille » | cible du ou des langages, pour s'arrêter là. | | Mais bon, le comité C n'a quand même pas ressorti de sous la | table sa proposition de rajouter les classes ? (à la mode castrée, | héritage simple, pas de surcharges, etc.)
Non, non. Il proposait un peu plus de coordination des deux côtes. Du genre, c'est pas la peine de definir une fonction nommée clog en prétendant qu'on savait pas que cela allait faire mal, ou introduire inline avec une sémantique différente. Tu vois ces genres de choses quoi. En contrepartie, il était prêt à inciter WG21 à amender le système de type de C++ pour accomoder C99. Mieux, il proposait que les deux parties nomment des gens de confiance pour former un sous-comité pour rédiger une charte et une feuille de route (et il s'excluait d'emblée de ce sous-comité).
C'est dommage que cela ait été la source d'uen flame fest tout à fait mémorable. La magie de <tgmath.h> devrait être accessible au programmeur. C'est dommage.
-- Gaby
Vincent Lefevre
Dans l'article <bh84rm$82d$, Antoine Leca écrit:
Vincent Lefevre écrivit:
Oui, mais une violation de contrainte, c'est un cas particulier de comportement indéfini (avec des choses en plus), non?
Pour moi, ce sont deux notions orthogonales. Relis 2. avec mon point de vue, tu me diras ce que tu en penses.
OK. Alors ici, je vois cela comme un diagnostic pour violation de contrainte (on est d'accord) *et* un comportement indéfini, car la norme ne définit pas ce qui se passe pour une telle soustraction.
-- 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 <bh84rm$82d$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Vincent Lefevre écrivit:
Oui, mais une violation de contrainte, c'est un cas particulier
de comportement indéfini (avec des choses en plus), non?
Pour moi, ce sont deux notions orthogonales.
Relis 2. avec mon point de vue, tu me diras ce que tu en penses.
OK. Alors ici, je vois cela comme un diagnostic pour violation de
contrainte (on est d'accord) *et* un comportement indéfini, car la
norme ne définit pas ce qui se passe pour une telle soustraction.
--
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
Oui, mais une violation de contrainte, c'est un cas particulier de comportement indéfini (avec des choses en plus), non?
Pour moi, ce sont deux notions orthogonales. Relis 2. avec mon point de vue, tu me diras ce que tu en penses.
OK. Alors ici, je vois cela comme un diagnostic pour violation de contrainte (on est d'accord) *et* un comportement indéfini, car la norme ne définit pas ce qui se passe pour une telle soustraction.
-- 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
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article <bh84rm$82d$, | Antoine Leca écrit: | | > Vincent Lefevre écrivit: | > > Oui, mais une violation de contrainte, c'est un cas particulier | > > de comportement indéfini (avec des choses en plus), non? | | > Pour moi, ce sont deux notions orthogonales. | > Relis 2. avec mon point de vue, tu me diras ce que tu en penses. | | OK. Alors ici, je vois cela comme un diagnostic pour violation de | contrainte (on est d'accord) *et* un comportement indéfini, car la | norme ne définit pas ce qui se passe pour une telle soustraction.
ce n'est pas exactement comme cela que la norme voit les choses.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <bh84rm$82d$1@shakotay.alphanet.ch>,
| Antoine Leca <root@localhost.gov> écrit:
|
| > Vincent Lefevre écrivit:
| > > Oui, mais une violation de contrainte, c'est un cas particulier
| > > de comportement indéfini (avec des choses en plus), non?
|
| > Pour moi, ce sont deux notions orthogonales.
| > Relis 2. avec mon point de vue, tu me diras ce que tu en penses.
|
| OK. Alors ici, je vois cela comme un diagnostic pour violation de
| contrainte (on est d'accord) *et* un comportement indéfini, car la
| norme ne définit pas ce qui se passe pour une telle soustraction.
ce n'est pas exactement comme cela que la norme voit les choses.
| Dans l'article <bh84rm$82d$, | Antoine Leca écrit: | | > Vincent Lefevre écrivit: | > > Oui, mais une violation de contrainte, c'est un cas particulier | > > de comportement indéfini (avec des choses en plus), non? | | > Pour moi, ce sont deux notions orthogonales. | > Relis 2. avec mon point de vue, tu me diras ce que tu en penses. | | OK. Alors ici, je vois cela comme un diagnostic pour violation de | contrainte (on est d'accord) *et* un comportement indéfini, car la | norme ne définit pas ce qui se passe pour une telle soustraction.
ce n'est pas exactement comme cela que la norme voit les choses.
-- Gaby
Antoine Leca
Gabriel Dos Reis écrivit:
"Antoine Leca" writes:
Gabriel Dos Reis écrivit:
"Antoine Leca" writes:
T'es pas obligé de citer mon "adresse" ! ;-)
cela fait bientôt un mois qu'elle m'intrigue :-)
Bah ? c'est un anti-spam pas tout-à-fait standard, mais au moins les spammeurs vont aller se brûler les doigts sur des serveurs « intéressants » (encore que nsa.gov soit sûrement encore plus intéressant, mais je n'ai pas vraiment envie d'appeler l'attention de Carnivore sur fclc !)
Le comité a introduit void* à la place,
Nan. je parlais des types entiers sur un byte, pas des pointeurs.
je comprends bien cela. Cependant, le point est que si char est une
unsigned char
unité officielle de mesure de la mémoire brute, alors char* peut être interpèté comme un pointeur sur de la mémoire brute, or une telle entité est communément représenté par void*. Voilà le lien que je faisais dans mon message.
Oui oui, nous sommes bien d'accord, je t'avais bien capté. En fait, tu défends une position qui si j'ai bien compris est déjà défendu depuis des années par quelques téoriciens. Je ne suis pas personnel- lement capable de dire où est le bien là-dedans, mais je remarque que c'est comme cela, on a « gagné » void*...
en realité, à part la déréférençabilité (ça existe ça ?),
Le terme sûrement pas. Le concept, je penses que c'est clair, non ?
void* a les mêmes caractéristiqques que char*, et aucun autre T* (T différent de charactère) ne jouit de la même propriété. En fait void* n'est pas vriament anonyme.
Moui. Sauf que je trouve que quand tu passes des char*, tu peux plus savoir si ce sont des tableaux de caractères, ou des objets anonymes; je reconnais qu'avec unsigned char* c'est plus "clair" (c'est « normalement » toujours des blocs de mémoire à adresser en vrac, donc des trucs très proches du void*, et pas des tableaux de unsigned char), mais bon, c'est comme cela.
Antoine
Gabriel Dos Reis écrivit:
"Antoine Leca" <root@localhost.gov> writes:
Gabriel Dos Reis écrivit:
"Antoine Leca" <root@localhost.gov> writes:
T'es pas obligé de citer mon "adresse" ! ;-)
cela fait bientôt un mois qu'elle m'intrigue :-)
Bah ? c'est un anti-spam pas tout-à-fait standard, mais au moins
les spammeurs vont aller se brûler les doigts sur des serveurs
« intéressants » (encore que nsa.gov soit sûrement encore plus
intéressant, mais je n'ai pas vraiment envie d'appeler l'attention
de Carnivore sur fclc !)
Le comité a introduit void* à la place,
Nan. je parlais des types entiers sur un byte, pas des pointeurs.
je comprends bien cela. Cependant, le point est que si char est une
unsigned char
unité officielle de mesure de la mémoire brute, alors char* peut être
interpèté comme un pointeur sur de la mémoire brute, or une telle
entité est communément représenté par void*. Voilà le lien que je
faisais dans mon message.
Oui oui, nous sommes bien d'accord, je t'avais bien capté.
En fait, tu défends une position qui si j'ai bien compris est déjà défendu
depuis des années par quelques téoriciens. Je ne suis pas personnel-
lement capable de dire où est le bien là-dedans, mais je remarque
que c'est comme cela, on a « gagné » void*...
en realité, à part la déréférençabilité (ça existe ça ?),
Le terme sûrement pas. Le concept, je penses que c'est clair, non ?
void* a les
mêmes caractéristiqques que char*, et aucun autre T* (T différent de
charactère) ne jouit de la même propriété. En fait void* n'est pas
vriament anonyme.
Moui. Sauf que je trouve que quand tu passes des char*, tu peux
plus savoir si ce sont des tableaux de caractères, ou des objets
anonymes; je reconnais qu'avec unsigned char* c'est plus "clair"
(c'est « normalement » toujours des blocs de mémoire à adresser
en vrac, donc des trucs très proches du void*, et pas des tableaux
de unsigned char), mais bon, c'est comme cela.
Bah ? c'est un anti-spam pas tout-à-fait standard, mais au moins les spammeurs vont aller se brûler les doigts sur des serveurs « intéressants » (encore que nsa.gov soit sûrement encore plus intéressant, mais je n'ai pas vraiment envie d'appeler l'attention de Carnivore sur fclc !)
Le comité a introduit void* à la place,
Nan. je parlais des types entiers sur un byte, pas des pointeurs.
je comprends bien cela. Cependant, le point est que si char est une
unsigned char
unité officielle de mesure de la mémoire brute, alors char* peut être interpèté comme un pointeur sur de la mémoire brute, or une telle entité est communément représenté par void*. Voilà le lien que je faisais dans mon message.
Oui oui, nous sommes bien d'accord, je t'avais bien capté. En fait, tu défends une position qui si j'ai bien compris est déjà défendu depuis des années par quelques téoriciens. Je ne suis pas personnel- lement capable de dire où est le bien là-dedans, mais je remarque que c'est comme cela, on a « gagné » void*...
en realité, à part la déréférençabilité (ça existe ça ?),
Le terme sûrement pas. Le concept, je penses que c'est clair, non ?
void* a les mêmes caractéristiqques que char*, et aucun autre T* (T différent de charactère) ne jouit de la même propriété. En fait void* n'est pas vriament anonyme.
Moui. Sauf que je trouve que quand tu passes des char*, tu peux plus savoir si ce sont des tableaux de caractères, ou des objets anonymes; je reconnais qu'avec unsigned char* c'est plus "clair" (c'est « normalement » toujours des blocs de mémoire à adresser en vrac, donc des trucs très proches du void*, et pas des tableaux de unsigned char), mais bon, c'est comme cela.
Antoine
Antoine Leca
Gabriel Dos Reis écrivit:
Antoine Leca writes:
Cela étant, violation de contrainte ne signifie pas erreur (en C),
la règle est la même en C++. On émet un diagnostique et on fait ce
que tu veux après.
En C++ tu as le droit de générer le code objet pour du code ill-behaved ?
En tous cas, le texte de la norme (« programme mal formé ») incite à beaucoup plus de prudence que celui de C qui ne fait rien d'autre que mentionner l'obligation d'émettre un « diagnostic ».
le compilateur peut accepter de générer le code. Il lui est juste requis de signaler que ce n'est pas bien^H^H^H^Hportable.
mais rien n'oblige que le code généré fasse quelque chose de sensé.
Sais pas.
Clairement, on est en dehors du domaine de la norme. Donc tout est permis, c'est le même raisonnement que pour le comportement indéfini et les dragons nasaux (avec mes excuses à Vincent pour l'avoir envoyé en section 2, c'est évidement la 3.; une fois-là, même si les deux notions sont différents au sein de la norme, le résultat est, après seconde réflexion, effectivement le même.)
Antoine
Gabriel Dos Reis écrivit:
Antoine Leca writes:
Cela étant, violation de contrainte ne signifie pas erreur (en C),
la règle est la même en C++. On émet un diagnostique et on fait ce
que tu veux après.
En C++ tu as le droit de générer le code objet pour du code
ill-behaved ?
En tous cas, le texte de la norme (« programme mal formé ») incite à
beaucoup plus de prudence que celui de C qui ne fait rien d'autre
que mentionner l'obligation d'émettre un « diagnostic ».
le compilateur peut accepter de générer le code. Il lui est juste
requis de signaler que ce n'est pas bien^H^H^H^Hportable.
mais rien n'oblige que le code généré fasse quelque chose de
sensé.
Sais pas.
Clairement, on est en dehors du domaine de la norme.
Donc tout est permis, c'est le même raisonnement que pour
le comportement indéfini et les dragons nasaux (avec mes
excuses à Vincent pour l'avoir envoyé en section 2, c'est
évidement la 3.; une fois-là, même si les deux notions sont
différents au sein de la norme, le résultat est, après seconde
réflexion, effectivement le même.)
Cela étant, violation de contrainte ne signifie pas erreur (en C),
la règle est la même en C++. On émet un diagnostique et on fait ce
que tu veux après.
En C++ tu as le droit de générer le code objet pour du code ill-behaved ?
En tous cas, le texte de la norme (« programme mal formé ») incite à beaucoup plus de prudence que celui de C qui ne fait rien d'autre que mentionner l'obligation d'émettre un « diagnostic ».
le compilateur peut accepter de générer le code. Il lui est juste requis de signaler que ce n'est pas bien^H^H^H^Hportable.
mais rien n'oblige que le code généré fasse quelque chose de sensé.
Sais pas.
Clairement, on est en dehors du domaine de la norme. Donc tout est permis, c'est le même raisonnement que pour le comportement indéfini et les dragons nasaux (avec mes excuses à Vincent pour l'avoir envoyé en section 2, c'est évidement la 3.; une fois-là, même si les deux notions sont différents au sein de la norme, le résultat est, après seconde réflexion, effectivement le même.)
Antoine
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Vincent Lefevre <vincent+ writes:
| Mais on n'a aucune garantie qu'on puisse stocker un caractère (au | sens courant) dans un char. Aujourd'hui, si c'était à refaire, char | ne devrait plus exister.
Moi, je garderais char et virerais les deux autres avatards.
Mais un char qui aurait quelles fonctionnalités? Taille? Bits de padding possibles? Signe?
-- 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 <m3bruw1gbo.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Mais on n'a aucune garantie qu'on puisse stocker un caractère (au
| sens courant) dans un char. Aujourd'hui, si c'était à refaire, char
| ne devrait plus exister.
Moi, je garderais char et virerais les deux autres avatards.
Mais un char qui aurait quelles fonctionnalités? Taille? Bits de padding
possibles? Signe?
--
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
| Mais on n'a aucune garantie qu'on puisse stocker un caractère (au | sens courant) dans un char. Aujourd'hui, si c'était à refaire, char | ne devrait plus exister.
Moi, je garderais char et virerais les deux autres avatards.
Mais un char qui aurait quelles fonctionnalités? Taille? Bits de padding possibles? Signe?
-- 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
Antoine Leca
Gabriel Dos Reis écrivit:
Ce qui m'intéresse en premier lieu c'est de pouvoir implémenter quelque chose comme my_memcpy(void*, const void*, int).
void *my_memcpy(void* a, const void* b, int c).{ return memcpy(a,b,c); }
comment imnplémenter my_qsort() en faisant de l'arithmétique sur void* ?
En appelant qsort :-D
Qui a dit que l'implémentation de la bibliothèque standard devait être strictement conforme, ou « jolie », ou même écrite en C ?
C'est pas Java/C# ici, que diable !
Antoine
Gabriel Dos Reis écrivit:
Ce qui m'intéresse en premier lieu c'est de pouvoir implémenter
quelque chose comme my_memcpy(void*, const void*, int).
void *my_memcpy(void* a, const void* b, int c).{ return memcpy(a,b,c); }
comment imnplémenter my_qsort() en faisant de l'arithmétique sur
void* ?
En appelant qsort :-D
Qui a dit que l'implémentation de la bibliothèque standard devait être
strictement conforme, ou « jolie », ou même écrite en C ?
Ce qui m'intéresse en premier lieu c'est de pouvoir implémenter quelque chose comme my_memcpy(void*, const void*, int).
void *my_memcpy(void* a, const void* b, int c).{ return memcpy(a,b,c); }
comment imnplémenter my_qsort() en faisant de l'arithmétique sur void* ?
En appelant qsort :-D
Qui a dit que l'implémentation de la bibliothèque standard devait être strictement conforme, ou « jolie », ou même écrite en C ?
C'est pas Java/C# ici, que diable !
Antoine
Antoine Leca
Vincent Lefevre écrivit:
Dans l'article <bh7r8s$ka3$, Antoine Leca écrit:
Le diagnostic serait le même (en fait, serait encore plus justifié) si on avait (unsigned char*)p - (signed char*)q.
En l'occurence, du fait des contraintes spécifiques sur les tableaux de caractères (en C99, 6.2.6, 6.2.5p15), on sait que cela "doit" fonctionner. Mais ce n'est pas "légal".
Comment ça, "fonctionner"?
Si tu fais abstraction de la clause spécifique de 6.5.6 qui énonce la contrainte. On peut concevoir, pour le cas particulier des pointeurs vers type caractère, une relaxe de cette contrainte. Et alors, le reste « fonctionne ».
L'implémentation peut très bien émettre un diagnostic et renvoyer 0 pour toute opération du style (unsigned char*)p - (signed char*)q.
Oui oui. Je ne me place plus dans le cadre de la norme, l'essayais d'imaginer ce qui se passe si on enlève la contrainte. Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la valeur logique et naturelle, sur laquelle il n'y a pas ce me semble d'ambiguité, même dans le cas des architectures tordues (il faut bien voir que vu du comité, les cas explicites de comportement indéfini sont en fait les cas où « cela ne passe pas » pour certaines architectures).
Antoine
Vincent Lefevre écrivit:
Dans l'article <bh7r8s$ka3$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Le diagnostic serait le même (en fait, serait encore plus
justifié) si on avait (unsigned char*)p - (signed char*)q.
En l'occurence, du fait des contraintes spécifiques sur
les tableaux de caractères (en C99, 6.2.6, 6.2.5p15),
on sait que cela "doit" fonctionner. Mais ce n'est pas "légal".
Comment ça, "fonctionner"?
Si tu fais abstraction de la clause spécifique de 6.5.6
qui énonce la contrainte. On peut concevoir, pour le cas
particulier des pointeurs vers type caractère, une relaxe de
cette contrainte. Et alors, le reste « fonctionne ».
L'implémentation peut très bien émettre
un diagnostic et renvoyer 0 pour toute opération du style
(unsigned char*)p - (signed char*)q.
Oui oui. Je ne me place plus dans le cadre de la norme,
l'essayais d'imaginer ce qui se passe si on enlève la
contrainte. Dans ce cas, tu ne "peux plus" renvoyer 0,
il "faut" renvoyer la valeur logique et naturelle, sur laquelle
il n'y a pas ce me semble d'ambiguité, même dans le cas
des architectures tordues (il faut bien voir que vu du comité,
les cas explicites de comportement indéfini sont en fait les
cas où « cela ne passe pas » pour certaines architectures).
Le diagnostic serait le même (en fait, serait encore plus justifié) si on avait (unsigned char*)p - (signed char*)q.
En l'occurence, du fait des contraintes spécifiques sur les tableaux de caractères (en C99, 6.2.6, 6.2.5p15), on sait que cela "doit" fonctionner. Mais ce n'est pas "légal".
Comment ça, "fonctionner"?
Si tu fais abstraction de la clause spécifique de 6.5.6 qui énonce la contrainte. On peut concevoir, pour le cas particulier des pointeurs vers type caractère, une relaxe de cette contrainte. Et alors, le reste « fonctionne ».
L'implémentation peut très bien émettre un diagnostic et renvoyer 0 pour toute opération du style (unsigned char*)p - (signed char*)q.
Oui oui. Je ne me place plus dans le cadre de la norme, l'essayais d'imaginer ce qui se passe si on enlève la contrainte. Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la valeur logique et naturelle, sur laquelle il n'y a pas ce me semble d'ambiguité, même dans le cas des architectures tordues (il faut bien voir que vu du comité, les cas explicites de comportement indéfini sont en fait les cas où « cela ne passe pas » pour certaines architectures).
Antoine
Antoine Leca
Erwan David écrivit:
Vincent Lefevre <vincent+ écrivait :
Dans l'article <bh7tch$obm$, Antoine Leca écrit:
Il y a trois types, parce qu'il y a trois besoins (stocker un caractère, stocker un entier signé de petite magnitude, stocker un entier non signé de petite magnitude et assurer ainsi des calculs vérifiables).
Mais on n'a aucune garantie qu'on puisse stocker un caractère (au sens courant) dans un char.
Juste: c'est tout le sens du bor... des wchar_t, utf16_t et autres extravagances, qui cherchent à résoudre le « simple » problème que tu sous-entends ci-dessus...
Aujourd'hui, si c'était à refaire, char ne devrait plus exister.
Mmmm. D'abord, pour les langages conçus aujourd'hui (et qui ne cherchent pas la compatibilité avec C), char existe, mais il est (potentiellement) plus grand qu'un byte; ce qui résoud le problème.
Ce qui n'existe plus « si c'était à refaire », c'est l'affirmation comme quoi l'unité de stockage élémentaire (le byte ou multiplet, et en pratique l'octet) permette de stocker un caractère.
Les besoins, pour moi, ils existent toujours, voire de plus en plus...
Ou plutôt s'appeler byte
Oui.
ou short short int...
<sigh> malheureusement, oui (en particulier, à cause du précédent de %hhd de scanf()).
Antoine
Erwan David écrivit:
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Dans l'article <bh7tch$obm$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Il y a trois types, parce qu'il y a trois besoins (stocker un
caractère, stocker un entier signé de petite magnitude, stocker un
entier non signé de petite magnitude et assurer ainsi des calculs
vérifiables).
Mais on n'a aucune garantie qu'on puisse stocker un caractère (au
sens courant) dans un char.
Juste: c'est tout le sens du bor... des wchar_t, utf16_t et autres
extravagances, qui cherchent à résoudre le « simple » problème
que tu sous-entends ci-dessus...
Aujourd'hui, si c'était à refaire, char ne devrait plus exister.
Mmmm. D'abord, pour les langages conçus aujourd'hui (et qui
ne cherchent pas la compatibilité avec C), char existe, mais il
est (potentiellement) plus grand qu'un byte; ce qui résoud le
problème.
Ce qui n'existe plus « si c'était à refaire », c'est l'affirmation
comme quoi l'unité de stockage élémentaire (le byte ou multiplet,
et en pratique l'octet) permette de stocker un caractère.
Les besoins, pour moi, ils existent toujours, voire de plus en plus...
Ou plutôt s'appeler byte
Oui.
ou short short int...
<sigh> malheureusement, oui (en particulier, à cause du précédent
de %hhd de scanf()).
Il y a trois types, parce qu'il y a trois besoins (stocker un caractère, stocker un entier signé de petite magnitude, stocker un entier non signé de petite magnitude et assurer ainsi des calculs vérifiables).
Mais on n'a aucune garantie qu'on puisse stocker un caractère (au sens courant) dans un char.
Juste: c'est tout le sens du bor... des wchar_t, utf16_t et autres extravagances, qui cherchent à résoudre le « simple » problème que tu sous-entends ci-dessus...
Aujourd'hui, si c'était à refaire, char ne devrait plus exister.
Mmmm. D'abord, pour les langages conçus aujourd'hui (et qui ne cherchent pas la compatibilité avec C), char existe, mais il est (potentiellement) plus grand qu'un byte; ce qui résoud le problème.
Ce qui n'existe plus « si c'était à refaire », c'est l'affirmation comme quoi l'unité de stockage élémentaire (le byte ou multiplet, et en pratique l'octet) permette de stocker un caractère.
Les besoins, pour moi, ils existent toujours, voire de plus en plus...
Ou plutôt s'appeler byte
Oui.
ou short short int...
<sigh> malheureusement, oui (en particulier, à cause du précédent de %hhd de scanf()).
