Le poulet tandorii - Page 28

C'est moi qui irai au championnat !

moi aussi

C'est à ce genre de détails qu'on la reconnait

pas moi

No contestas ???

si

moins de deux semaines.

pour quoi ?

Moi je le crois.

pourquoi ?

Faut bosser !!!

pourquoi ?

Pollux (./806) :
Le C, mais de toute façon je vois pas le pb... Chaîne de caractère != bloc de données binaires.

Pourquoi? Pour compliquer?
Bon, certes, il est normal que chaînes de caractères et données binaires soient des types différents, mais ces types devraient être compatibles.

Bouarf ! Des chaînes avec un demi-caractère au bout ?

Ben ouais, c'est rigolo !
(Quel rabat-joie, ce Pollux)

(c'est super, l'ensemble des caractères d'une chaîne n'est pas stable par SREV )

Bah, si.

c'est de l'obfuscation mais pas du cryptage

Nan mais je dis pas le contraire, mais c'est marrant pour les collégiens ^^

Ben non, une chaîne c'est fait pour contenir des caractères, ça n'a rien à voir avec des données binaires ^^ (une chaîne de caractère, c'est conçu principalement pour la lecture séquentielle

La fonction créé l'organe, toussa : c'est ce avec quoi on t'a bourré le mou depuis tout petit.

Pourtant, les éditeurs de texte brut (donc éditeurs de chaîne de caractères, moralement), se sentent obligés de pouvoir ouvrir un fichier avec des \00.

En FORTH, une chaîne de caractère, c'est un pointeur de début et une longueur, et c'est tout !

un XOR entre des chaînes ? quelle idée saugrenue, ça n'a aucun sens de calculer ώ XOR Љ

Ben là ça n'a pas de sens parce que les données binaires n'ont pas la même longueur, banane ! (ou alors elles ont la même longueur? Ben alors ça a un sens !)


Sacré Pollux, il n'a jamais rien fait de sa vie ! Des XOR entre chaînes de caractères, j'en fait à chaque petit déjeuner.

Hippopotame (./823) :

Pollux (./806) :
Le C, mais de toute façon je vois pas le pb... Chaîne de caractère != bloc de données binaires.

Pourquoi? Pour compliquer?Bon, certes, il est normal que chaînes de caractères et données binaires soient des types différents, mais ces types devraient être compatibles.

Oui, transformer une chaîne de caractère en bloc binaire est une opération légitime (encore faut-il préciser l'encodage...), mais transformer un bloc binaire en chaîne de caractère n'a aucun sens, sauf bien sûr si le bloc en question correspond effectivement à une chaîne encodée comme il faut... D'ailleurs tous les encodages non-triviaux (dont UTF-8) ne sont pas surjectifs ^^

Bouarf ! Des chaînes avec un demi-caractère au bout ?

Ben ouais, c'est rigolo ! (Quel rabat-joie, ce Pollux)

J'ai pas dit que c'était pas rigolo, juste que ct pas propre

(c'est super, l'ensemble des caractères d'une chaîne n'est pas stable par SREV )

Bah, si.

Bah, non. "ABC<demi caractère>" SREV "<demi caractère>CBA" != ASSERT

c'est de l'obfuscation mais pas du cryptage

Nan mais je dis pas le contraire, mais c'est marrant pour les collégiens ^^

Nan mais je dis pas le contraire, je disais ça juste pour te faire chier

Ben non, une chaîne c'est fait pour contenir des caractères, ça n'a rien à voir avec des données binaires ^^ (une chaîne de caractère, c'est conçu principalement pour la lecture séquentielle

La fonction créé l'organe, toussa : c'est ce avec quoi on t'a bourré le mou depuis tout petit.
Pourtant, les éditeurs de texte brut (donc éditeurs de chaîne de caractères, moralement), se sentent obligés de pouvoir ouvrir un fichier avec des \00.

Parce qu'ils ne sont pas fait que pour ouvrir des textes ; c'est parfois utile de pouvoir ouvrir un fichier binaire avec un éditeur de texte. Et ils ne travaillent malheureusement pas sur des jolies chaînes de caractères, ils doivent détecter plein de saloperies comme les encodages, les conventions de retour à la ligne, etc...

En FORTH, une chaîne de caractère, c'est un pointeur de début et une longueur, et c'est tout !

FORTH supporte unicode ?

un XOR entre des chaînes ? quelle idée saugrenue, ça n'a aucun sens de calculer ώ XOR Љ

Ben là ça n'a pas de sens parce que les données binaires n'ont pas la même longueur, banane ! (ou alors elles ont la même longueur? Ben alors ça a un sens !)

Justement, quelle est la longueur d'un caractère ?

Content pour moi

Header pour moi

Pollux (./824) :
Oui, transformer une chaîne de caractère en bloc binaire est une opération légitime (encore faut-il préciser l'encodage...),

Brèfle : les chaînes de caractères dont tu parles sont de plus haut niveau que celles dont je parle. Les tiennes sont des objets plus riches, avec par exemple une information d'encodage en plus. On ne parle pas de la même chose.

J'ai pas dit que c'était pas rigolo, juste que ct pas propre

Tu peux le dire et le répéter autant que tu veux, ça ne convainc personne.

"ABC<demi caractère>" SREV => "<demi caractère>CBA"

Non.

Parce qu'ils ne sont pas fait que pour ouvrir des textes ; c'est parfois utile de pouvoir ouvrir un fichier binaire avec un éditeur de texte.

Parce que moralement, binaires et texte c'est la même chose : n'essaie pas de noyer le poisson.

FORTH supporte unicode ?

Ben FORTH peut supporter unicode si on écrit les routines pour.

Justement, quelle est la longueur d'un caractère ?

Ben ça dépend, tu l'as dit toi même !
Et ça n'a aucun rapport avec la question.

Hippopotame (./827) :

Pollux (./824) :
Oui, transformer une chaîne de caractère en bloc binaire est une opération légitime (encore faut-il préciser l'encodage...),

Brèfle : les chaînes de caractères dont tu parles sont de plus haut niveau que celles dont je parle. Les tiennes sont des objets plus riches, avec par exemple une information d'encodage en plus. On ne parle pas de la même chose.

Non justement, les miennes font abstraction de l'encodage ^^ (mais oui, c'est une structure de plus haut niveau, c'est bien pour ça qu'on appelle ça une chaîne de caractères et pas un tableau d'octets)

"ABC<demi caractère>" SREV => "<demi caractère>CBA"

Non.

Donc l'ensemble des caractères n'est pas stable par SREV.

Parce qu'ils ne sont pas fait que pour ouvrir des textes ; c'est parfois utile de pouvoir ouvrir un fichier binaire avec un éditeur de texte.

Parce que moralement, binaires et texte c'est la même chose : n'essaie pas de noyer le poisson.

Non, les fichier "plain text" sont un sous-ensemble des fichiers binaires. Par exemple un fichier UTF-8 mal encodé, ou un fichier UTF-32 contenant des caractères invalides (au sens d'unicode) ne sont pas des fichiers "plain text".

FORTH supporte unicode ?

Ben FORTH peut supporter unicode si on écrit les routines pour.

Ca s'appelle "ne pas supporter unicode" (en tout cas pour les chaînes standard). Tu ne peux pas créer le caractère n°4242, et les caractères sont tous entre 0 et 255 (mais c'est "enough for everyone", comme chacun sait )

Justement, quelle est la longueur d'un caractère ?

Ben ça dépend, tu l'as dit toi même !Et ça n'a aucun rapport avec la question.

Ben alors pourquoi est-ce que ça aurait une influence sur la validité ou non du XOR ?

[cite] Pollux (./828) :

Hippopotame (./827) :

Pollux (./824) :
Oui, transformer une chaîne de caractère en bloc binaire est une opération légitime (encore faut-il préciser l'encodage...),

Brèfle : les chaînes de caractères dont tu parles sont de plus haut niveau que celles dont je parle. Les tiennes sont des objets plus riches, avec par exemple une information d'encodage en plus. On ne parle pas de la même chose.

Non justement, les miennes font abstraction de l'encodage ^^ (mais oui, c'est une structure de plus haut niveau, c'est bien pour ça qu'on appelle ça une chaîne de caractères et pas un tableau d'octets)

Donc l'ensemble des caractères n'est pas stable par SREV.

Ah d'accord, je vois ce que tu veux dire. Effectivement SREV renverse les octets, pas les caractères multi-octets. (sur HP il n'y a pas de caractère multi-octet, certes, en revanche il y a des caractères de contrôle pour faire du texte formaté (italique, souligné, etc...). Il se trouve que SREV respecte ce formatage, mais c'est un hasard (ces caractères de contrôles sont placés de façon symétrique, pour écrire du texte en italique ça donne : "\13\02\13 texte... \13\02\13").

Bon, mais de toute façon, il ne faut pas prendre la commande SREV au sérieux : elle ne fait pas partie des commandes principales dont l'usager non averti se sert, elle fait partie de la librairie 256 des commandes de bidouillage de bas niveau, sa présence se justifie pour travailler facilement avec ce saturn qui lit et écrit à l'envers.

Plutôt que SREV, il vaut mieux parler des commandes de base sur les chaînes : SIZE, SUB, REPL, etc... Celles ci considèrent que 1 caractère = 1 octet.

Non, les fichier "plain text" sont un sous-ensemble des fichiers binaires. Par exemple un fichier UTF-8 mal encodé, ou un fichier UTF-32 contenant des caractères invalides (au sens d'unicode) ne sont pas des fichiers "plain text".

Menfou des plain text, je te parle des string en général (c'est à dire des chaînes d'octets, grosso modo).

Ca s'appelle "ne pas supporter unicode" (en tout cas pour les chaînes standard). Tu ne peux pas créer le caractère n°4242, et les caractères sont tous entre 0 et 255

Euh, ben si, tu écris 4242 avec le préfixe qui va bien, chais plus le format. Où est le problème.

Ben alors pourquoi est-ce que ça aurait une influence sur la validité ou non du XOR ?

ben ça n'en a aucune, justement. C'est pas la longueur des caractères qui compte, c'est la taille de la chaîne.

Hippopotame (./829) :

Donc l'ensemble des caractères n'est pas stable par SREV.

Ah d'accord, je vois ce que tu veux dire. Effectivement SREV renverse les octets, pas les caractères multi-octets. (sur HP il n'y a pas de caractère multi-octet, certes, en revanche il y a des caractères de contrôle pour faire du texte formaté (italique, souligné, etc...). Il se trouve que SREV respecte ce formatage, mais c'est un hasard (ces caractères de contrôles sont placés de façon symétrique, pour écrire du texte en italique ça donne : "\13\02\13 texte... \13\02\13").

Euh je parlais pas de ça, je parlais des demi-octets (tu disais que c'était parfaitement propre d'avoir des chaînes de 3.5 caractères, ça prouve que non)

Bon, mais de toute façon, il ne faut pas prendre la commande SREV au sérieux : elle ne fait pas partie des commandes principales dont l'usager non averti se sert, elle fait partie de la librairie 256 des commandes de bidouillage de bas niveau, sa présence se justifie pour travailler facilement avec ce saturn qui lit et écrit à l'envers.

J'ai parlé de SREV, mais c'est pareil pour la concaténation : l'ensemble des caractères n'est pas additif par concaténation pour les chaînes de longueur non-entière ^^

Non, les fichier "plain text" sont un sous-ensemble des fichiers binaires. Par exemple un fichier UTF-8 mal encodé, ou un fichier UTF-32 contenant des caractères invalides (au sens d'unicode) ne sont pas des fichiers "plain text".

Menfou des plain text, je te parle des string en général (c'est à dire des chaînes d'octets, grosso modo).

Lis ce à quoi je répondais, tu ne parlais pas de string mais de fichiers texte ^^

Ca s'appelle "ne pas supporter unicode" (en tout cas pour les chaînes standard). Tu ne peux pas créer le caractère n°4242, et les caractères sont tous entre 0 et 255

Euh, ben si, tu écris 4242 avec le préfixe qui va bien, chais plus le format. Où est le problème.

Ca ne s'appelle pas supporter unicode : la longueur d'une chaîne n'est pas la longueur de sa représentation binaire... (et puis ton encodage n'est pas surjectif)

Ben alors pourquoi est-ce que ça aurait une influence sur la validité ou non du XOR ?

ben ça n'en a aucune, justement. C'est pas la longueur des caractères qui compte, c'est la taille de la chaîne.

gni ? tu veux dire que, si tu encodes l'unicode en HTML, "&12345;" XOR "bonjour" est bien défini et que "&12345;" XOR "a" ne l'est pas ?

Pollux (./830) :
Euh je parlais pas de ça, je parlais des demi-octets (tu disais que c'était parfaitement propre d'avoir des chaînes de 3.5 caractères, ça prouve que non)

D'abord ça "prouve" rien du tout. (Qu'est ce qui prouverait quoi???)
Ensuite tu m'entraînes vers des problématiques inintéressantes : au fond je ne veux pas dire que c'est "parfaitement propre", je m'en fous, je dis juste que c'est une conséquence rigolote du fait qu'on a une puce 4 bits, et que ça ne pose pas de problème sauf pour les psychorigides.

J'ai parlé de SREV, mais c'est pareil pour la concaténation : l'ensemble des caractères n'est pas additif par concaténation pour les chaînes de longueur non-entière ^^

Ben oui, ben on s'en fout.

Lis ce à quoi je répondais, tu ne parlais pas de string mais de fichiers texte ^^

Je te parlais des éditeurs de texte qui, ô joie, acceptent les \00.

Et de toute façon, un fichier texte (ou pas texte) c'est une chaîne d'octets donc une chaîne de caractères.

la longueur d'une chaîne n'est pas la longueur de sa représentation binaire...

Ben oui, t'as deux notions de longueur, quelle surprise !
Je ne comprends pas ton émerveillement...

gni ? tu veux dire que, si tu encodes l'unicode en HTML, "&
12345;" XOR "bonjour" est bien défini et que "&12345;" XOR "a" ne l'est pas ?

Ben c'est assez clair, non, tu sais compter quand même?

Exemple :
"X" "1234567" XOR => "\"0 l&4$"
mais
"X" "1234567" XOR => Error (Bad Argument Value)




Plutôt que de se faire des noeuds dans la tête avec ces chaînes, pour justifier cette connerie de chaines AZT, les programmeurs en C auraient mieux fait de séparer clairement les types entiers et flottants !

Vive yaronet libre !

Hippopotame (./831) :

Pollux (./830) :
Euh je parlais pas de ça, je parlais des demi-octets (tu disais que c'était parfaitement propre d'avoir des chaînes de 3.5 caractères, ça prouve que non)

D'abord ça "prouve" rien du tout. (Qu'est ce qui prouverait quoi???)Ensuite tu m'entraînes vers des problématiques inintéressantes : au fond je ne veux pas dire que c'est "parfaitement propre", je m'en fous, je dis juste que c'est une conséquence rigolote du fait qu'on a une puce 4 bits, et que ça ne pose pas de problème sauf pour les psychorigides.

Moi je dis simplement que, si tu sors du modèle ASCII pur (0<=caractère<255) il n'y a pas d'isomorphisme satisfaisant entre chaînes de caractères et chaînes binaires (i.e. qui ne casse pas des propriétés importantes des chaînes de caractères)

Lis ce à quoi je répondais, tu ne parlais pas de string mais de fichiers texte ^^

Je te parlais des éditeurs de texte qui, ô joie, acceptent les \00.
Et de toute façon, un fichier texte (ou pas texte) c'est une chaîne d'octets donc une chaîne de caractères.

Une chaîne d'octets, oui, une chaîne de caractères, ça dépend de l'encodage...

la longueur d'une chaîne n'est pas la longueur de sa représentation binaire...

Ben oui, t'as deux notions de longueur, quelle surprise !Je ne comprends pas ton émerveillement...

Mais on s'en fout de la longueur binaire de la chaîne ou bien de la position binaire d'un caractère...

gni ? tu veux dire que, si tu encodes l'unicode en HTML, "&
12345;" XOR "bonjour" est bien défini et que "&12345;" XOR "a" ne l'est pas ?

Ben c'est assez clair, non, tu sais compter quand même?

C'est pas clair du tout et surtout ça fait n'importe quoi : tu dois abandonner au moins une de ces propriétés :
- le XOR de 2 chaînes valides est tjs une chaîne valide
- la concaténation de 2 chaînes a et b, où a a une longueur de n caractères (par exemple n=1 pour a="&12345;") est telle que (a+b)[i+n]=b[i]

Plutôt que de se faire des noeuds dans la tête avec ces chaînes, pour justifier cette connerie de chaines AZT, les programmeurs en C auraient mieux fait de séparer clairement les types entiers et flottants !

Les types entiers et flottants sont bien séparés

Pollux (./833) :
Moi je dis simplement que, si tu sors du modèle ASCII pur (0<=caractère<255) il n'y a pas d'isomorphisme satisfaisant entre chaînes de caractères et chaînes binaires (i.e. qui ne casse pas des propriétés importantes des chaînes de caractères)

Nan mais d'accord.

Une chaîne d'octets, oui, une chaîne de caractères, ça dépend de l'encodage...

Il existe un encodage pour le quel c'est une chaîne de c., et puis voilà.

Mais on s'en fout de la longueur binaire de la chaîne ou bien de la position binaire d'un caractère...

Ben non, pas moi !
Comment je ferais un XOR sinon ??

C'est pas clair du tout et surtout ça fait n'importe quoi : tu dois abandonner au moins une de ces propriétés :
- le XOR de 2 chaînes valides est tjs une chaîne valide
- la concaténation de 2 chaînes a et b, où a a une longueur de n caractères (par exemple n=1 pour a="&12345;") est telle que (a+b)[i+n]=b[i]

Ah oui d'accord mais parce que tu veux te placer dans des encodages compliqués. Mais si c'est pas une chaîne tétratomique-compliant on s'en fout.

Les types entiers et flottants sont bien séparés

Et mon cul c'est du poulet.

Hippopotame (./834) :

Pollux (./833) :
Moi je dis simplement que, si tu sors du modèle ASCII pur (0<=caractère<255) il n'y a pas d'isomorphisme satisfaisant entre chaînes de caractères et chaînes binaires (i.e. qui ne casse pas des propriétés importantes des chaînes de caractères)

Nan mais d'accord.

Une chaîne d'octets, oui, une chaîne de caractères, ça dépend de l'encodage...

Il existe un encodage pour le quel c'est une chaîne de c., et puis voilà.

Mais on s'en fout de la longueur binaire de la chaîne ou bien de la position binaire d'un caractère...

Ben non, pas moi !
Comment je ferais un XOR sinon ??

C'est pas clair du tout et surtout ça fait n'importe quoi : tu dois abandonner au moins une de ces propriétés :
- le XOR de 2 chaînes valides est tjs une chaîne valide
- la concaténation de 2 chaînes a et b, où a a une longueur de n caractères (par exemple n=1 pour a="&12345;") est telle que (a+b)[i+n]=b[i]

Ah oui d'accord mais parce que tu veux te placer dans des encodages compliqués. Mais si c'est pas une chaîne tétratomique-compliant on s'en fout.

Les types entiers et flottants sont bien séparés

Et mon cul c'est du poulet.

non, je ne crois pas que ton cul soit du poulet.

Ouais c'est de l'hippo

Hippopotame (./834) :
Il existe un encodage pour le quel c'est une chaîne de c., et puis voilà.

Ah oui, absolument.
([mode=avocat du diable] mais de toute façon ça ne devrait pas te gêner que le 0 binaire soit représenté par autre chose dans la chaîne de caractère [/mode])

Hippopotame (./834) :
Ben non, pas moi ! Comment je ferais un XOR sinon ??

(a.to_binary(UTF8) ^ b.to_binary(UTF8)).to_string(UTF8)
(par exemple)
Et ça a l'avantage de faire apparaître clairement ta contrainte tordue "une chaîne de 1 caractère unicode ne peut être XORée qu'avec une chaîne de 6 caractère ascii", ou bien le fait que le décodage UTF8 peut échouer...

Hippopotame (./834) :
Ah oui d'accord mais parce que tu veux te placer dans des encodages compliqués. Mais si c'est pas une chaîne tétratomique-compliant on s'en fout.

C'est quoi une chaîne tétratomique-compliant ?
(et évidemment que je me place dans des encodages compliqués, c'est la seule raison pour laquelle une chaîne serait autre chose qu'un tableau d'octets)

Hippopotame (./834) :
Et mon cul c'est du poulet.

Ben par défaut C te fait pas chier et est relativement permissif, mais si ton application est critique au point d'exiger d'être plus verbeux il y a plein d'outils pour vérifier ton code :

~ $ > hippo.c
int main() {
    double x = 42;
    float y = x/3;
    return y;
}
~ $ lint hippo.c
Splint 3.1.1 --- 02 May 2003

hippo.c: (in function main)
hippo.c:3:15: Variable y initialized to type double, expects float: x / 3
  To allow all numeric types to match, use +relaxtypes.
hippo.c:4:12: Return value type float does not match declared type int: y

Finished checking --- 2 code warnings

(tu peux aussi exiger que les arguments d'un if soient des bool, plein de choses comme ça)

Brèfle si toi tu veux appeler chaîne de caractères tes machines de haut niveau avec encodage, et dont les unités de base sont des caractères qui moralement ne sont pas des octets, alors fort bien mais j'ai besoin de chaînes d'octets, que j'appellerai chaînes de caractères dans le privé, et je peste contre le fait qu'on a imposé à ces chaînes d'octets d'être à zéro terminal.

(a.to_binary(UTF8) ^ b.to_binary(UTF8)).to_string(UTF8)
(par exemple) Et ça a l'avantage de faire apparaître clairement ta contrainte tordue "une chaîne de 1 caractère unicode ne peut être XORée qu'avec une chaîne de 6 caractère ascii", ou bien le fait que le décodage UTF8 peut échouer...

menfou.

(et évidemment que je me place dans des encodages compliqués, c'est la seule raison pour laquelle une chaîne serait autre chose qu'un tableau d'octets)

Oui, c'est ce que je disais, ya donc pas de raison de pas être d'accord, sauf sur une bête question de vocabulaire.

Ben par défaut C te fait pas chier et est relativement permissif, mais (...)

Ben par défaut C te fait pas chier et est relativement permissif.
(et puis si d'ailleurs, même en étant permissif il fait chier.)

Hippopotame (./838) :
Brèfle si toi tu veux appeler chaîne de caractères tes machines de haut niveau avec encodage, et dont les unités de base sont des caractères qui moralement ne sont pas des octets, alors fort bien mais j'ai besoin de chaînes d'octets, que j'appellerai chaînes de caractères dans le privé, et je peste contre le fait qu'on a imposé à ces chaînes d'octets d'être à zéro terminal.

Ah, mais personne n'impose à *tes* chaînes d'octets d'être à zéro terminal, hein... De toute façon les fonctions de chaîne de la lib std du C sont pourrites, alors...
([google]brèfle[/google] )

Ben par défaut C te fait pas chier et est relativement permissif, mais (...)

Ben par défaut C te fait pas chier et est relativement permissif.
(et puis si d'ailleurs, même en étant permissif il fait chier.)

Pkoi il fait chier au niveau des float vs int ?

parce que zis expression has type int but is used with type float


Et puis le C il fait pas spécialement chier pour les float vs int, il fait chier en général parce qu'il est tout bloaté.