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>
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer. Le traitement de l'erreur de malloc() peut vite générer en l'écriture de code à longueur indéterminée.
Non. De deux choses l'unes : - soit tu es sur un programme qui a besoin d'un traitement d'erreur correct, et dans ce cas là il est déjà écrit, et le cas malloc n'ajouter rien.
- soit tu es dans un programme qui peut s'arrêter en cas de pénurie de mémoire et le traitement d'erreur se fait en deux lignes.
Dans tous les cas écrire un code de traitement d'erreur spécifique pour un malloc n'a pas lieu d'être.
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 permet de ne pas limiter la taille de la chaîne recherchée.
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à <dinh.viet.hoa@free.fr> wrote:
Oui mais
- 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer.
Le traitement de l'erreur de malloc() peut vite générer en l'écriture de
code à longueur indéterminée.
Non. De deux choses l'unes :
- soit tu es sur un programme qui a besoin d'un traitement d'erreur
correct, et dans ce cas là il est déjà écrit, et le cas malloc n'ajouter
rien.
- soit tu es dans un programme qui peut s'arrêter en cas de pénurie de
mémoire et le traitement d'erreur se fait en deux lignes.
Dans tous les cas écrire un code de traitement d'erreur spécifique pour
un malloc n'a pas lieu d'être.
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 permet de ne pas limiter la taille de la chaîne recherchée.
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
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer. Le traitement de l'erreur de malloc() peut vite générer en l'écriture de code à longueur indéterminée.
Non. De deux choses l'unes : - soit tu es sur un programme qui a besoin d'un traitement d'erreur correct, et dans ce cas là il est déjà écrit, et le cas malloc n'ajouter rien.
- soit tu es dans un programme qui peut s'arrêter en cas de pénurie de mémoire et le traitement d'erreur se fait en deux lignes.
Dans tous les cas écrire un code de traitement d'erreur spécifique pour un malloc n'a pas lieu d'être.
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 permet de ne pas limiter la taille de la chaîne recherchée.
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
Saïd
DINH Viêt Hoà :
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. 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.
Un tableau de la taille du jeu de caracteres ASCII est alloue (128 cases). Ce qui est limitant c'est que c'est un tableau de int (32 bits, sur ma machines) et que de ce fait les chaines traitees ne peuvent depasser 32 caracteres (sur ma machine et mon compilateur avec sa configuration par defaut, sans prejuger des autres ordinateurs/compilateurs qui ont leurs coutumes propres et qui doivent etre respectees en tant que telles et sans vouloir faire de l'imperialisme du 32 bits).
-- Saïd. C programmers never die - they're just cast into void.
DINH Viêt Hoà :
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.
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.
Un tableau de la taille du jeu de caracteres ASCII est alloue (128 cases).
Ce qui est limitant c'est que c'est un tableau de int (32 bits, sur ma
machines) et que de ce fait les chaines traitees ne peuvent depasser 32
caracteres (sur ma machine et mon compilateur avec sa configuration par
defaut, sans prejuger des autres ordinateurs/compilateurs qui ont leurs
coutumes propres et qui doivent etre respectees en tant que telles et sans
vouloir faire de l'imperialisme du 32 bits).
--
Saïd.
C programmers never die - they're just cast into void.
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. 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.
Un tableau de la taille du jeu de caracteres ASCII est alloue (128 cases). Ce qui est limitant c'est que c'est un tableau de int (32 bits, sur ma machines) et que de ce fait les chaines traitees ne peuvent depasser 32 caracteres (sur ma machine et mon compilateur avec sa configuration par defaut, sans prejuger des autres ordinateurs/compilateurs qui ont leurs coutumes propres et qui doivent etre respectees en tant que telles et sans vouloir faire de l'imperialisme du 32 bits).
-- Saïd. C programmers never die - they're just cast into void.
Saïd
FiLH :
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court, d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte alphanumerique anglosaxon).
-- Saïd. C programmers never die - they're just cast into void.
FiLH :
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres
traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court,
d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte
alphanumerique anglosaxon).
--
Saïd.
C programmers never die - they're just cast into void.
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court, d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte alphanumerique anglosaxon).
-- Saïd. C programmers never die - they're just cast into void.
Eric Lévénez
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH » a écrit :
Eric Lévénez wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
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.
C'est tout. Ça évite un commentaire ça précise un usage.
Non. Tu vois bien que tu te trompes dans ton premier malloc en pensant allouer des octets. Ce que montre ton premier malloc, c'est qu'avant de donner de mauvaises indications au lecteur du code (par un "* sizeof(char)"), il est plus judicieux de placer un commentaire adapté.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
Eric Lévénez <eric@levenez.com> wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on
compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc
préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il
s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun
rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1)
n'alloue pas un octet, mais un mot, donc 32 bits.
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.
C'est tout. Ça évite un commentaire ça précise un usage.
Non. Tu vois bien que tu te trompes dans ton premier malloc en pensant
allouer des octets. Ce que montre ton premier malloc, c'est qu'avant de
donner de mauvaises indications au lecteur du code (par un "*
sizeof(char)"), il est plus judicieux de placer un commentaire adapté.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH » a écrit :
Eric Lévénez wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
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.
C'est tout. Ça évite un commentaire ça précise un usage.
Non. Tu vois bien que tu te trompes dans ton premier malloc en pensant allouer des octets. Ce que montre ton premier malloc, c'est qu'avant de donner de mauvaises indications au lecteur du code (par un "* sizeof(char)"), il est plus judicieux de placer un commentaire adapté.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
filh
Saïd wrote:
FiLH :
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court, d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte alphanumerique anglosaxon).
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 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.
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne constante avec un nom significatif est de la mauvaise programmation.
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
Saïd <said@brian.lan> wrote:
FiLH :
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres
traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court,
d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte
alphanumerique anglosaxon).
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 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.
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne
constante avec un nom significatif est de la mauvaise programmation.
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
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 permet de ne pas limiter la taille de la chaîne recherchée.
Faux! le 128 dans le cas du programme donne est du au jeu de caracteres traite (ASCII en dessous de 128 (ca doit s'appeler ASCII tout court, d'ailleurs)). Il est donc constant (tant qu'il s'agit de chercher du texte alphanumerique anglosaxon).
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 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.
Cela prouve une fois de plus que mettre 128 au llieu d'une bonne constante avec un nom significatif est de la mauvaise programmation.
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
filh
Eric Lévénez wrote:
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH »
Eric Lévénez wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
Ce n'était pas la quesiton ici. Tu dérives sur une erreur qui n'a aucun rapport avec le question dont je parles.
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.
On fait la même chose pratiquement, mais pas sémantiquement.
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
Indiquer ce pour quoi on fait une chose est un avantage certain dans le code.
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
Eric Lévénez <eric@levenez.com> wrote:
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%filh@filh.orgie>, « FiLH »
Eric Lévénez <eric@levenez.com> wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on
compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc
préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il
s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun
rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1)
n'alloue pas un octet, mais un mot, donc 32 bits.
Ce n'était pas la quesiton ici.
Tu dérives sur une erreur qui n'a aucun rapport avec le question dont je
parles.
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.
On fait la même chose pratiquement, mais pas sémantiquement.
C'est une des choses les plus difficile à comprendre pour les
programmeurs, et tu ne fais pas exception, tu ne le piges pas.
Indiquer ce pour quoi on fait une chose est un avantage certain dans le
code.
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
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH »
Eric Lévénez wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
Ce n'était pas la quesiton ici. Tu dérives sur une erreur qui n'a aucun rapport avec le question dont je parles.
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.
On fait la même chose pratiquement, mais pas sémantiquement.
C'est une des choses les plus difficile à comprendre pour les programmeurs, et tu ne fais pas exception, tu ne le piges pas.
Indiquer ce pour quoi on fait une chose est un avantage certain dans le code.
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
langmc
FiLH wrote:
Non. De deux choses l'unes :
L'autre c'est le soleil.
-- Le sage montre la lune, l'imbécile regarde le doigt.
FiLH <filh@filh.orgie> wrote:
Non. De deux choses l'unes :
L'autre c'est le soleil.
--
Le sage montre la lune, l'imbécile regarde le doigt.
-- Le sage montre la lune, l'imbécile regarde le doigt.
filh
Eric Lévénez wrote:
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH »
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
En regardant par curiosité les standards on tombe sur www.unix.org qui dit que malloc retourne des bytes de 8 bits.
Ils sont posix tes DSP ?
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
Eric Lévénez <eric@levenez.com> wrote:
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%filh@filh.orgie>, « FiLH »
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il
s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun
rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1)
n'alloue pas un octet, mais un mot, donc 32 bits.
En regardant par curiosité les standards on tombe sur www.unix.org
qui dit que malloc retourne des bytes de 8 bits.
Ils sont posix tes DSP ?
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
Le 14/07/05 18:37, dans <1gzpcv6.1htz1pzaczcncN%, « FiLH »
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Non, pas du tout. Tu alloues 345 mots permettant de stocker des char. Aucun rapport avec des octets. Je travaille sur des DSP 32 bits, et un malloc(1) n'alloue pas un octet, mais un mot, donc 32 bits.
En regardant par curiosité les standards on tombe sur www.unix.org qui dit que malloc retourne des bytes de 8 bits.
Ils sont posix tes DSP ?
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
blanc
FiLH wrote:
Quand on n'a rien à dire on attaque sur l'orthographe...
Désolé, mais je n'ai fait que transcrire ce que j'ai effectivement ressenti... J'ai mis un certain temps à comprendre ce que tu voulais dire, et ce sont dans l'ordre les mots qui me sont venus à l'esprit, car j'ai considéré d'abord que c'était une fgaute de frappe, avant une faute d'orthographe...
Et je l'ai retranscrit pour dire que l'orthographe c'est aussi important, car ça peut parfois mener à des erreurs de compréhension, voire des malentendus.
Voilà ce que j'avais à dire. :-)
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.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH <filh@filh.orgie> wrote:
Quand on n'a rien à dire on attaque sur l'orthographe...
Désolé, mais je n'ai fait que transcrire ce que j'ai effectivement
ressenti... J'ai mis un certain temps à comprendre ce que tu voulais
dire, et ce sont dans l'ordre les mots qui me sont venus à l'esprit, car
j'ai considéré d'abord que c'était une fgaute de frappe, avant une faute
d'orthographe...
Et je l'ai retranscrit pour dire que l'orthographe c'est aussi
important, car ça peut parfois mener à des erreurs de compréhension,
voire des malentendus.
Voilà ce que j'avais à dire. :-)
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.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Quand on n'a rien à dire on attaque sur l'orthographe...
Désolé, mais je n'ai fait que transcrire ce que j'ai effectivement ressenti... J'ai mis un certain temps à comprendre ce que tu voulais dire, et ce sont dans l'ordre les mots qui me sont venus à l'esprit, car j'ai considéré d'abord que c'était une fgaute de frappe, avant une faute d'orthographe...
Et je l'ai retranscrit pour dire que l'orthographe c'est aussi important, car ça peut parfois mener à des erreurs de compréhension, voire des malentendus.
Voilà ce que j'avais à dire. :-)
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.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
blanc
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 ;-)
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
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 ;-)
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
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 ;-)
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
