Je cherche un outil (ou les paramètres appropriés à passer à un outil
standard) qui puisse me donner la position de toutes les occurrences
d'une chaîne dans un fichier (le fichier fait 50 Go en fait un "dump"
d'un disque crashé obtenu avec dd).
J'ai essayé "grep -b" mais il n'aime pas trop les parties binaires. Mon
autre option est de passer par "hexdump -C" d'abord, mais comme là ma
chaîne risque d'être à cheval sur deux lignes...
Une idée ?
Merci,
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
90% les trous de sécus sont basés sur des dépassements..
Oui, je sais. Mais amha c'est plus souvent des problèmes de hacking que de virus.
les virus qui se propagent sur internet (appelés ver) sont la plupart du temps basés sur un problème de sécurité, qui est souvent un dépassement de tampon.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
90% les trous de sécus sont basés sur des dépassements..
Oui, je sais. Mais amha c'est plus souvent des problèmes de hacking que
de virus.
les virus qui se propagent sur internet (appelés ver) sont la plupart du
temps basés sur un problème de sécurité, qui est souvent un dépassement
de tampon.
90% les trous de sécus sont basés sur des dépassements..
Oui, je sais. Mais amha c'est plus souvent des problèmes de hacking que de virus.
les virus qui se propagent sur internet (appelés ver) sont la plupart du temps basés sur un problème de sécurité, qui est souvent un dépassement de tampon.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
DINH Viêt Hoà
FiLH wrote:
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric. Et puis va donc redire tous ce que tu as dit à propos des sizeof(char) sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
On peut dire que je pratique beaucoup le C et les propos de FiLH ne me choquent pas particulièrement. Quand on n'a rien à apporter au débat, on se l'écrase comme dirait comme diraient les parachutes.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
FiLH <filh@filh.orgie> wrote:
C'est une des choses les plus difficile à comprendre pour les
programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric.
Et puis va donc redire tous ce que tu as dit à propos des sizeof(char)
sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
On peut dire que je pratique beaucoup le C et les propos de FiLH ne me
choquent pas particulièrement. Quand on n'a rien à apporter au
débat, on se l'écrase comme dirait comme diraient les parachutes.
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric. Et puis va donc redire tous ce que tu as dit à propos des sizeof(char) sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
On peut dire que je pratique beaucoup le C et les propos de FiLH ne me choquent pas particulièrement. Quand on n'a rien à apporter au débat, on se l'écrase comme dirait comme diraient les parachutes.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
DINH Viêt Hoà
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354 char.
Non, tu fais la même chose, comme "malloc(354 / sizeof(char))", tu alloues 354 mots.
Si on fait une analogie par rapport à la physique et qu'on place sizeof(char) ayant pour unité de mesure l'octet.
354 * sizeof(char) serait mesuré en octets.
354 / sizeof(char) serait mesuré en 1/octets.
Je suis plutôt du camps des mesures en octets.
Quand à 354, il peut être effectivement implicitement mesuré en octets mais ce genre de pratique est plutôt du code destiné à être repris/relu par des gens qui ont un peu connaissance de la norme C (et il y en a très peu sur le marché).
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354
char.
Non, tu fais la même chose, comme "malloc(354 / sizeof(char))", tu alloues
354 mots.
Si on fait une analogie par rapport à la physique et qu'on place
sizeof(char) ayant pour unité de mesure l'octet.
354 * sizeof(char) serait mesuré en octets.
354 / sizeof(char) serait mesuré en 1/octets.
Je suis plutôt du camps des mesures en octets.
Quand à 354, il peut être effectivement implicitement mesuré en octets
mais ce genre de pratique est plutôt du code destiné à être repris/relu
par des gens qui ont un peu connaissance de la norme C (et il y en a
très peu sur le marché).
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354 char.
Non, tu fais la même chose, comme "malloc(354 / sizeof(char))", tu alloues 354 mots.
Si on fait une analogie par rapport à la physique et qu'on place sizeof(char) ayant pour unité de mesure l'octet.
354 * sizeof(char) serait mesuré en octets.
354 / sizeof(char) serait mesuré en 1/octets.
Je suis plutôt du camps des mesures en octets.
Quand à 354, il peut être effectivement implicitement mesuré en octets mais ce genre de pratique est plutôt du code destiné à être repris/relu par des gens qui ont un peu connaissance de la norme C (et il y en a très peu sur le marché).
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
blanc
FiLH wrote:
Pourquoi 256 ? Pourquoi pas 357 ?
Parceque tout simplement c'est le nombre de valeurs possibles pour un caractère (de 8 bits bien sûr). Si tu ne l'as pas vu, c'est que tu n'a pas compris le programme.
Le malloc c'est trop compliqué ?
256 est une constante connue à la compilation. Il est donc absolument inutile de faire (avec un malloc) une allocation dynamique, qui sert dans le cas ou on veut un tableau dont la taille n'est connu qu'à l'exécution.
Mettre un malloc ici ça serait : "pourquoi faire simple quand on peut faire compliqué.
Pourquoi mettre en dur des limites dans le code ?
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder tes char sur plusieurs octets.
J'ai failli suggérer de mettre un #define pour définir cette constante, ça aurait été plus propre. Mais j'y ai renoncé car :
1) il y a peu de chance qu'on ait besoin de changer cette constante. En fait, même si les char sont sur plusieurs octets, on peut ne travailler que sur l'octet poids faible ;
2) je ne voulais pas faire de correction superflue, ainsi les corrections vraiment nécessaires ont plus de poids.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH <filh@filh.orgie> wrote:
Pourquoi 256 ? Pourquoi pas 357 ?
Parceque tout simplement c'est le nombre de valeurs possibles pour un
caractère (de 8 bits bien sûr). Si tu ne l'as pas vu, c'est que tu n'a
pas compris le programme.
Le malloc c'est trop compliqué ?
256 est une constante connue à la compilation. Il est donc absolument
inutile de faire (avec un malloc) une allocation dynamique, qui sert
dans le cas ou on veut un tableau dont la taille n'est connu qu'à
l'exécution.
Mettre un malloc ici ça serait : "pourquoi faire simple quand on peut
faire compliqué.
Pourquoi mettre en dur des limites dans le code ?
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder
tes char sur plusieurs octets.
J'ai failli suggérer de mettre un #define pour définir cette constante,
ça aurait été plus propre. Mais j'y ai renoncé car :
1) il y a peu de chance qu'on ait besoin de changer cette constante. En
fait, même si les char sont sur plusieurs octets, on peut ne travailler
que sur l'octet poids faible ;
2) je ne voulais pas faire de correction superflue, ainsi les
corrections vraiment nécessaires ont plus de poids.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Parceque tout simplement c'est le nombre de valeurs possibles pour un caractère (de 8 bits bien sûr). Si tu ne l'as pas vu, c'est que tu n'a pas compris le programme.
Le malloc c'est trop compliqué ?
256 est une constante connue à la compilation. Il est donc absolument inutile de faire (avec un malloc) une allocation dynamique, qui sert dans le cas ou on veut un tableau dont la taille n'est connu qu'à l'exécution.
Mettre un malloc ici ça serait : "pourquoi faire simple quand on peut faire compliqué.
Pourquoi mettre en dur des limites dans le code ?
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder tes char sur plusieurs octets.
J'ai failli suggérer de mettre un #define pour définir cette constante, ça aurait été plus propre. Mais j'y ai renoncé car :
1) il y a peu de chance qu'on ait besoin de changer cette constante. En fait, même si les char sont sur plusieurs octets, on peut ne travailler que sur l'octet poids faible ;
2) je ne voulais pas faire de correction superflue, ainsi les corrections vraiment nécessaires ont plus de poids.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
filh
JPaul wrote:
FiLH wrote:
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric.
Bah tu sais les arguments d'autorité... on sait ce que ça vaut, surtout venant après un argument orthographique.
Et puis va donc redire tous ce que tu as dit à propos des sizeof(char) sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
Quand je vois la gueule du C que je débugge ça ne m'étonnerait pas vraiment... les cochons ont horreur qu'on pointe leurs saletés...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
JPaul <blanc@empty.org> wrote:
FiLH <filh@filh.orgie> wrote:
C'est une des choses les plus difficile à comprendre pour les
programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric.
Bah tu sais les arguments d'autorité... on sait ce que ça vaut, surtout
venant après un argument orthographique.
Et puis va donc redire tous ce que tu as dit à propos des sizeof(char)
sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
Quand je vois la gueule du C que je débugge ça ne m'étonnerait pas
vraiment... les cochons ont horreur qu'on pointe leurs saletés...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
S'il y a quelqu'un qui ne piges pas ici, ce n'est certainement pas Eric.
Bah tu sais les arguments d'autorité... on sait ce que ça vaut, surtout venant après un argument orthographique.
Et puis va donc redire tous ce que tu as dit à propos des sizeof(char) sur un forum de C, et tu vas voir comment tu vas te faire ramasser ;-)
Quand je vois la gueule du C que je débugge ça ne m'étonnerait pas vraiment... les cochons ont horreur qu'on pointe leurs saletés...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
DINH Viêt Hoà
travaille sur le tableu en fonction de la longueur de la chaîne à chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de caractères supérieur à 128, ça existe je crois.
Sachant de plus que les char peuvent être soit de 0 à 255 ou bien de -128 à 127, ce n'est pas gagné.
Comme quoi, on aura retenu la leçon que d'essayer d'écrire du nouveau code, à priori, simple.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
travaille sur le tableu en fonction de la longueur de la chaîne à
chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de
caractères supérieur à 128, ça existe je crois.
Sachant de plus que les char peuvent être soit de 0 à 255 ou bien
de -128 à 127, ce n'est pas gagné.
Comme quoi, on aura retenu la leçon que d'essayer d'écrire du nouveau
code, à priori, simple.
travaille sur le tableu en fonction de la longueur de la chaîne à chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de caractères supérieur à 128, ça existe je crois.
Sachant de plus que les char peuvent être soit de 0 à 255 ou bien de -128 à 127, ce n'est pas gagné.
Comme quoi, on aura retenu la leçon que d'essayer d'écrire du nouveau code, à priori, simple.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
DINH Viêt Hoà
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder tes char sur plusieurs octets.
Ce que je vois, c'est que la constante est utilisée en plusieurs lieux du programme et donc, si jamais on veut en changer la valeur (par exemple la faire passer de 128 à 256), on doit penser à le changer partout. Alors qu'avec une constante, c'est réglé en un coup de cuillère à pinceau.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder
tes char sur plusieurs octets.
Ce que je vois, c'est que la constante est utilisée en plusieurs lieux
du programme et donc, si jamais on veut en changer la valeur (par
exemple la faire passer de 128 à 256), on doit penser à le changer
partout. Alors qu'avec une constante, c'est réglé en un coup de cuillère
à pinceau.
Rien ne t'empêche de changer ce 256 en 512 voire plus si tu veux coder tes char sur plusieurs octets.
Ce que je vois, c'est que la constante est utilisée en plusieurs lieux du programme et donc, si jamais on veut en changer la valeur (par exemple la faire passer de 128 à 256), on doit penser à le changer partout. Alors qu'avec une constante, c'est réglé en un coup de cuillère à pinceau.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
blanc
FiLH wrote:
T'es sûr ? Parce que bon la boucle :
for (i=0; i<patternLength; i++) { vector[pattern[i]] |= 1<<i; }
travaille sur le tableu en fonction de la longueur de la chaîne à chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais non, attention : i est compris entre 0 et patternLength, mais l'indice du tableau est *** pattern[i] *** qui est la valeur (ascii) d'un caractère du motif, et est donc compris entre 0 et 255. Nicolas avait limité à 128, refusant de considérer les caractères accentués, et rejetant tous les car de code >8 :
Mais il avait oublié de les rejeter dans l'initialisation du tableau, ce qui conduisait effectivement (comme tu l'avais deviné ;-) à un risque de débordement de tableau, si un utilisateur tapait un motif avec des car accentués.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de caractères supérieur à 128, ça existe je crois.
C'est bien pourquoi j'ai proposé de mettre 256. Ceci étant j'ai peut-être eu tort de supprimer le test ;-)
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne constante avec un nom significatif est de la mauvaise programmation.
Là, je suis d'accord (voir mon autre réponse).
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH <filh@filh.orgie> wrote:
T'es sûr ? Parce que bon la boucle :
for (i=0; i<patternLength; i++) {
vector[pattern[i]] |= 1<<i;
}
travaille sur le tableu en fonction de la longueur de la chaîne à
chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais non, attention : i est compris entre 0 et patternLength, mais
l'indice du tableau est *** pattern[i] *** qui est la valeur (ascii)
d'un caractère du motif, et est donc compris entre 0 et 255. Nicolas
avait limité à 128, refusant de considérer les caractères accentués, et
rejetant tous les car de code >8 :
Mais il avait oublié de les rejeter dans l'initialisation du tableau, ce
qui conduisait effectivement (comme tu l'avais deviné ;-) à un risque de
débordement de tableau, si un utilisateur tapait un motif avec des car
accentués.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de
caractères supérieur à 128, ça existe je crois.
C'est bien pourquoi j'ai proposé de mettre 256. Ceci étant j'ai
peut-être eu tort de supprimer le test ;-)
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne
constante avec un nom significatif est de la mauvaise programmation.
Là, je suis d'accord (voir mon autre réponse).
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
for (i=0; i<patternLength; i++) { vector[pattern[i]] |= 1<<i; }
travaille sur le tableu en fonction de la longueur de la chaîne à chercher, j'ai du mal à y voir le nombre de caractère ascii.
Mais non, attention : i est compris entre 0 et patternLength, mais l'indice du tableau est *** pattern[i] *** qui est la valeur (ascii) d'un caractère du motif, et est donc compris entre 0 et 255. Nicolas avait limité à 128, refusant de considérer les caractères accentués, et rejetant tous les car de code >8 :
Mais il avait oublié de les rejeter dans l'initialisation du tableau, ce qui conduisait effectivement (comme tu l'avais deviné ;-) à un risque de débordement de tableau, si un utilisateur tapait un motif avec des car accentués.
Mais si ce 128 est ce que tu dis, c'est un peu cata car bon des codes de caractères supérieur à 128, ça existe je crois.
C'est bien pourquoi j'ai proposé de mettre 256. Ceci étant j'ai peut-être eu tort de supprimer le test ;-)
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne constante avec un nom significatif est de la mauvaise programmation.
Là, je suis d'accord (voir mon autre réponse).
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
blanc
DINH Viêt Hoà wrote:
J'avouerai que je n'ai pas bien compris ce que faisait le programme et qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de chaîne dans le programme.
Il construit un tableau qui par chaque code ASCII indique par un ou plusieurs bits 1 la (ou les) positions de ce caractère dans le motifs. Ce qui limite la taille du motif au nombre de bits d'un élément du tableau. Ici int = 4 octets sur ma machine soit 32 bits dont 32 car max dans le motif.
Ensuite c'est un jeu d'enfant de vérifier qu'une suite de n caractères satisfait aux mêmes positions que dans le motif (avec n= patternLength) . En effet s'il y a une concordance avec le premier carac du motif elle se traduit par un 1 dans le bits de poids faible de la variable result, et ensuite chaque nouvelle concordance décale ce 1 vers la gauche. Donc n concordances successives donnent un 1 en (n-1)ème position. L'astuce du programme est d'enregistrer simultanément dans result, pour chaque caractère du fichier les concordances avec tous les carac du motif.
Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au lieu de cette déclaration de tableau.
Il n'y a aucun intérêt à faire un malloc dans ce cas. Voir mon autre réponse.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
J'avouerai que je n'ai pas bien compris ce que faisait le programme et
qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de
chaîne dans le programme.
Il construit un tableau qui par chaque code ASCII indique par un ou
plusieurs bits 1 la (ou les) positions de ce caractère dans le motifs.
Ce qui limite la taille du motif au nombre de bits d'un élément du
tableau. Ici int = 4 octets sur ma machine soit 32 bits dont 32 car max
dans le motif.
Ensuite c'est un jeu d'enfant de vérifier qu'une suite de n caractères
satisfait aux mêmes positions que dans le motif (avec n= patternLength)
. En effet s'il y a une concordance avec le premier carac du motif elle
se traduit par un 1 dans le bits de poids faible de la variable result,
et ensuite chaque nouvelle concordance décale ce 1 vers la gauche. Donc
n concordances successives donnent un 1 en (n-1)ème position. L'astuce
du programme est d'enregistrer simultanément dans result, pour chaque
caractère du fichier les concordances avec tous les carac du motif.
Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au
lieu de cette déclaration de tableau.
Il n'y a aucun intérêt à faire un malloc dans ce cas. Voir mon autre
réponse.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
J'avouerai que je n'ai pas bien compris ce que faisait le programme et qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de chaîne dans le programme.
Il construit un tableau qui par chaque code ASCII indique par un ou plusieurs bits 1 la (ou les) positions de ce caractère dans le motifs. Ce qui limite la taille du motif au nombre de bits d'un élément du tableau. Ici int = 4 octets sur ma machine soit 32 bits dont 32 car max dans le motif.
Ensuite c'est un jeu d'enfant de vérifier qu'une suite de n caractères satisfait aux mêmes positions que dans le motif (avec n= patternLength) . En effet s'il y a une concordance avec le premier carac du motif elle se traduit par un 1 dans le bits de poids faible de la variable result, et ensuite chaque nouvelle concordance décale ce 1 vers la gauche. Donc n concordances successives donnent un 1 en (n-1)ème position. L'astuce du programme est d'enregistrer simultanément dans result, pour chaque caractère du fichier les concordances avec tous les carac du motif.
Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au lieu de cette déclaration de tableau.
Il n'y a aucun intérêt à faire un malloc dans ce cas. Voir mon autre réponse.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Eric Lévénez
Le 14/07/05 20:15, dans <1gzphhe.1k0zxhmn15vr9N%, « FiLH » a écrit :
En regardant par curiosité les standards on tombe sur www.unix.org qui dit que malloc retourne des bytes de 8 bits.
Quand on parle d'un langage, ici le langage C, il faut regarder la norme liée à ce langage et non une implémentation donnée. Ainsi la norme courante est l'ISO/IEC 9899 et la fonction malloc y est définie au chapitre 7.20.3.3, et, bien sûr, il n'est pas du tout question d'octets.
Ils sont posix tes DSP ?
Il y a des dizaines de normes Posix, je pense que tu fais référence à la norme IEEE Std 1003.1 (aka ISO 9945-1). Alors il faut savoir que dans le cadre des normes de télécommunication et sur les langages comme le C, un byte est un multiplet, et un octet (en anglais, oui, oui), est un multiplet de 8 bits (donc un octet aussi en français). Enfin bref, le malloc retourne un objet d'une taille donnée en byte d'après le ISO/IEC 9945-1. Et comme cette fonction est calquée sur la norme C (ISO/IEC 9899), le malloc retourne bien un nombre de cases mémoire dont l'unité est le char et pas du tout l'octet.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/07/05 20:15, dans <1gzphhe.1k0zxhmn15vr9N%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
En regardant par curiosité les standards on tombe sur www.unix.org
qui dit que malloc retourne des bytes de 8 bits.
Quand on parle d'un langage, ici le langage C, il faut regarder la norme
liée à ce langage et non une implémentation donnée. Ainsi la norme courante
est l'ISO/IEC 9899 et la fonction malloc y est définie au chapitre 7.20.3.3,
et, bien sûr, il n'est pas du tout question d'octets.
Ils sont posix tes DSP ?
Il y a des dizaines de normes Posix, je pense que tu fais référence à la
norme IEEE Std 1003.1 (aka ISO 9945-1). Alors il faut savoir que dans le
cadre des normes de télécommunication et sur les langages comme le C, un
byte est un multiplet, et un octet (en anglais, oui, oui), est un multiplet
de 8 bits (donc un octet aussi en français). Enfin bref, le malloc retourne
un objet d'une taille donnée en byte d'après le ISO/IEC 9945-1. Et comme
cette fonction est calquée sur la norme C (ISO/IEC 9899), le malloc retourne
bien un nombre de cases mémoire dont l'unité est le char et pas du tout
l'octet.
Le 14/07/05 20:15, dans <1gzphhe.1k0zxhmn15vr9N%, « FiLH » a écrit :
En regardant par curiosité les standards on tombe sur www.unix.org qui dit que malloc retourne des bytes de 8 bits.
Quand on parle d'un langage, ici le langage C, il faut regarder la norme liée à ce langage et non une implémentation donnée. Ainsi la norme courante est l'ISO/IEC 9899 et la fonction malloc y est définie au chapitre 7.20.3.3, et, bien sûr, il n'est pas du tout question d'octets.
Ils sont posix tes DSP ?
Il y a des dizaines de normes Posix, je pense que tu fais référence à la norme IEEE Std 1003.1 (aka ISO 9945-1). Alors il faut savoir que dans le cadre des normes de télécommunication et sur les langages comme le C, un byte est un multiplet, et un octet (en anglais, oui, oui), est un multiplet de 8 bits (donc un octet aussi en français). Enfin bref, le malloc retourne un objet d'une taille donnée en byte d'après le ISO/IEC 9945-1. Et comme cette fonction est calquée sur la norme C (ISO/IEC 9899), le malloc retourne bien un nombre de cases mémoire dont l'unité est le char et pas du tout l'octet.
