groumly a écrit 3282 commentaires

Unicode dit que l’existence de 2 formes pour é est un artefact d’encodage, inévitable vu le domaine, mais que les 2 encodages représentent exactement la même chose. Un peu comme un int casté en bool va traiter 1 et 2 comme étant la même chose (true).

Le but d’unicode, c’est précisément de découpler la représentation binaire du texte de sa semantique, pour que le code puisse opérer au niveau semantique. D’ailleurs, je dit texte, mais c’est même pas vrai, c’est juste un raccourci, Unicode gère plus que du texte, c’est le but.
Tout comme le but de if (myInt) est de découpler la représentation binaire de la semantique, et dans ce context 1 et 2 sont égaux.

Donc je te renvoie au commentaire au dessus.
Si tu traites un flux d’octets, oui, la normalisation est incorrecte et n’a pas de sens.
Si tu traites une chaîne Unicode, le standard dit que les 2 formes de é sont équivalentes et représentent la même chose, et ton code est cassé s’il ne fait pas ça. Je te rassure, il y’a énormément de code cassé sur ce sujet, Unicode est très loin d’être simple à gérer. Ce qui est justement ce qui me fait hurler quand je lit les commentaires d’uso.

Juste parce que tu peux traiter la String comme un flux d’octets et t’en sortir dans 98% des cas ne veut pas dire que c’est correct. Le problème du C, c’est précisément de dire « un octet et un char sont la même chose, d’ailleurs on a même pas de type pour représenter un octet, utilisé juste un char ». Ça marchait bien en 77 vu les contraintes, mais le monde a un peu évolué depuis.

passer en ascii standard (voir 7 bits) est une normalisation

comment tu normalises 😒 en ascii?

Euh ouais, mais non la. La normalisation gère des situations sémantiquement identiques, pas de glyphes qui se ressemble suffisamment dans certaines polices.
L’exemple de base, c’est un e compose avec un accent vs un é.

Passer du cyrillique à un alphabet latin ne fait partie d’aucune normalisation, c’est comparer des choux et des carottes. Unicode fournit une liste de caractères sujet à confusion, si t’as besoin de vérifier ce genre de choses: http://www.unicode.org/Public/security/revision-05/intentional.txt

c'est que cela soit utilisé comme argument détracteur de Debian

Va falloir penser a prendre tes pilules, parce que t'es en plein délire la.

J'ai dit qu'avoir son soft intégré upstream dans une distro impliquait que la distro va applique des patches qui ne vont pas forcement plaire a l'auteur, ce qui peut être un problème pour l'auteur.
Si tu lit ca comme un argument detracteur de Debian, faut consulter, parce que ton syndrome de persecution est un peu trop prononcé.

alors que le principe même de Debian c'est de ne pas accepter un quelconque truc propriétaire (que cela soit un nom, une image, ou un bout de code).

Ca les a pas dérangé d'inclure thunderbird et firefox au debut pourtant. On va peut être arrêter de prendre ses vessies pour des lanternes.

C’est pas si compliqué que ça.
Soit tu travaille des byte streams sans te poser la question des encodages et de la semantique des bytes, et Swift te donne cette possibilité, C aussi d’ailleurs.

Soit tu travailles sur des chaînes de caractères et t’es un peu obligé de prendre en compte la normalisation Unicode si tu veux émettre du code correct. Swift te donne cette possibilité. C aussi d’ailleurs, mais tu vas avoir beaucoup plus de boulot à faire.

C’est surtout ça qui m’ennuie dans ton commentaire, considérer qu’une String est juste un tableau d’octets. C’était vaguement vrai en 1977, mais ça fait plus de 20 ans que ça n’est plus le cas.

La question est surtout est ce que ton code est correct? Parce qu’aller très vite pour donner la mauvaise réponse, c’est facile, je peux le faire moi aussi: 42, temps constant, je suis le plus rapide de la planète.
Ok, j’exagère un peu. Plus sérieusement, un lookup qui foire dans une hash map pour des raisons d’encodage de la clé, c’est quand même super ballot. Idem pour une recherche dans un index full text, ou un sed qui rate une substitution.

T’imputes aussi une perte de performance à cette normalisation sans avoir la moindre idée du coût réel de cette normalisation.

Est ce que Swift est « plus lent » que du C? Oui, très probablement.
Dans quelle proportion est il plus lent? Ça depend du contexte.
Est ce que cette lenteur est causée par la normalisation? Probablement pas, en tout cas certainement pas au niveau que tu penses.

Je comprends très bien que c’est censé être une feature.
Mais c’est juste absolument délirant comme feature.

Les dates sont déjà assez difficiles à gérer tel quel, rajouter des trucs genre « une date invalide est considérée comme valide via des pirouettes intellectuelles » ne va vraiment pas aider.
C’est du même niveau que de dire « bah, les divisions par 0, c’est pas pratique de gérer les erreurs, alors on va dire qu’une division par 0, ça fait 0 ».

C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance.

Potentiellement est utilisé de façon assez créative dans cette phrase. Et ya pas que le process de code review que ce patch a bypassé, après, je dit ça, je dit rien.

Je comprends bien que t’as juste envie me prouver que j’ai tort, mais que ça te plaise ou non, ça illustre parfaitement mon point. Debian à patché un soft (critique ou pas, c’est pas la question) à la truelle en ayant visiblement aucune idée de comment valider que le soft qu’ils livraient faisaient toujours ce qu’il était censé faire.

Ça donne pas forcément envie d’avoir son soft intégré upstream à leur distro, parce que si ça arrive sur un truc aussi gros et central qu’openssl, va savoir ce qu’il se passe sur des paquets moins populaires.

Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla.

Ben écoutes, c’est pas trop mal documenté.
Mozilla autorise l’utilisation de la marque firefox sous réserve que le source n’est pas modifié de façon non triviale, ou s’ils ont approuvé les patches eux même.

Thunderbird était déjà patché par Debian, et Debian savait très bien qu’ils allaient devoir patcher Firefox pour backporter au moins les patches de sécu. Et visiblement, ils avaient pas prévu de demander à Mozilla leur avis sur les backports.

Ce qui, oh, comme par hasard, me parait plutôt bien correspondre au concept de « patches non voulus ».

https://lwn.net/Articles/118268/, https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian ou encore https://glandium.org/blog/?p=97

Après, comme j’ai dit plus haut, t’es clairement la juste pour me contredire, je suppose que t’as pas supporté que je dise que C est largement cantonné à l’embarqué et bas niveau, donc je vais passer sous silence tes autre remarques qui n’ont pas grand chose à voir avec la choucroute, et je vais me retirer de ce fil, pas grand chose de productif n’en sortira.

Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.

Ok, mais ca aide pas avec les versions majeures. Tout le monde n'a pas forcement envie de se taper des gros changements comme ca. GTK3 n'est pas source compatible avec les version précédentes. GTK4 non plus.
Qt a l'air de se débrouiller un peu mieux sur la compat source. Quelqu'un qui distribue une appli

Je comprends bien la philosophie sous jacente qui pousse a faire des changements qui petent tout.
Devnewton demande pourquoi est ce qu'on pourrait vouloir embarquer un framework en statique, je lui dit pourquoi certains sont intéressés par du tout statique.

J'ai pas d'exemple de patch non voulu sur GTK/Qt que je ne suis pas plus que ca, mais il me semble qu'OpenSSL a trouvé a redire sur un certain patch de Debian.
Iceweasel est né d'une dispute entre Mozilla et Debian au sujet des patches de Debian dans firefox.

Apres, tu me crois, tu me crois pas. C'est toi qui voit. Linus Torvarlds a l'air d'être du meme avis que moi, et tu serais mal venu de lui expliquer qu'il est ignorant a propos des problemes de link statique vs dynamique, les chaines de compilation ou comment les distributions fonctionnent.

https://youtu.be/Pzl1B7nB9Kc

Ça dépend du contexte.
Sous Windows/macOS, la plupart utilisent les framework systèmes, qui sont compatible binaire dans toutes les directions, et ça just marche.
Ceux qui font du cross plateform avec qt ou quoi ou qu’est-ce vont de toutes façons devoir embarquer leur dépendance et les déposer quelque part a eux sur le système (sous macOS, typiquement dans l’app bundle, donc privé à l’appli, je sais pas trop où en sont les choses sous Windows de nos jours).

Sur ces plateformes, ça va, ça se gère sans trop de migraines. Mais après t’as Linux.
Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Si t’arrives a être intégré upstream, ça aide, mais après tu te tapes des patches qui te plaisent pas forcemment, tu contrôles pas quelle version est distribué, ce genre de choses qui peuvent être un gros problème en fonction du projet.

Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent ».
Et du coup, l’intérêt du link statique de go devient beaucoup plus apparent.

Ca montre surtout que les mecs de php sont des bras cassés, ce qui est pas franchement nouveau. Ils l’ont pas abandonné parce que personne en voulait, ils l’ont arrêté parce qu’ils n’ont pas réussi à l’implémenter, en grande partie parce qu’ils n’ont pas assez de gens sur les projets qui comprennent le problème.

Ça te surprend vraiment venant d’un langage qui considère que la date 0000-00-00 est équivalente à 1999-11-30, et ferme ça comme « not a bug, working as designed »?

Pour le « personne ne voulait vraiment la feature », je te renvoie à https://wiki.php.net/ideas/php6/unicode

Unicode still remains one of the top requested features in PHP.

C’est moi, ou tu viens de sortir php dans une discussion sur les bons langages de programmation?

Après, je sais pas à quoi tu fais référence exactement que les mecs de php aient prit une décision à la con et n’ait pas réussi à fournir une implémentation correcte, ça serait pas la première fois (les mecs ont prit l’habitude de releaser avec des tests unitaires qui passent pas, alors on est plus à ça près), et que les mecs qui utilisent php ne comprennent rien à ce qu’il se passe non plus, ca serait pas la première fois non plus.

Je suis d’accord, la normalisation a rien à faire dans un langage de programmation, c’est pour ça qu’elle est définie au niveau d’unicode lui même.
Swift se contente d’implémenter la spec.

https://unicode.org/reports/tr15/

ce qui oblige à connaître l’encodage du texte comparé, ce que le == n’indique pas du tout — nécessairement il admet implicitement un encodage, mais lequel ?

Comment diable veut tu espérer comparer des chaînes si tu ne connais pas leur encodage? En l’occurrence, l’encodage est capturé à la source, quand tu construit la chaîne.

Les opérations d’égalité et autres manipulations se font ensuite de normalisée, vu que tout le monde est sur le même pied, via String. Tu peux recevoir une chaîne en UTF8, une autre en utf32 et une troisième en iso 8859-15, et les concatener ensemble, String sait comment faire vu que string connaît et comprend chacun des encodages. Ta chaîne sera correcte sémantiquement et techniquement, au niveau du buffer qui back la struct.

L’égalité par défaut va marcher au niveau sémantique, si tu veux comparer les char *, tu peux aussi, cf le code au dessus.

Plusieurs choses. Déjà c’est du Swift, pas du go. Les mecs de go ont pas de voyelles sur leur clavier non plus.

Ensuite, oui, == est souvent plus cher en Swift qu’un ==, mais pas pour les raisons que tu cites. C’est une égalité de valeur, pas de référence. Swift utilise === pour l’égalité de références.

Pour finir, la normalisation n’est pas appliquée à chaque égalité, mais a la constructiom, quand tu vas devoir itérer ta chaîne pour les raisons au dessus. J’ai pas les détails de l’implémentation, mais l’essentiel de ce que tu vois ici est appliqué de façon paresseuse. Tu le payes (presque) pas tant que tu l’utilises pas. Encore que, je suppute que utf8CString est simplement le buffer qui back la chaîne, ce qui me fait penser que même la normalisation est appliquée de façon paresseuse en fait.

Et oui, les mecs du runtime ont passé beaucoup de temps à peaufiner leur api string pour éviter que ça soit « bloated », c’est pour ça qu’on s’est tapé un changement d’api à mi chemin. Ça tourne sur des montres, donc bon, ils s’en sortent pas trop mal quand même.

Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo,

C’est assez particulier comme vision quand même.

Une bonne voiture ne se définit que par la capacité des conducteurs de refaire l’injection.
Un bon avion ne se définit que par la capacité des pilotes de refaire l’avionique.
Un bon cpu ne se définit que par la capacité de refaire les transistors.
Un bon immeuble ne se définit que par la capacité des architectes de couler le béton.
Un bon ballon de foot ne se définit que par la capacité du footballeur de refaire le ballon.

Est ce que t’as vraiment envie que tu compilateur ne puisse pas interpréter du texte correctement, et te balance une erreur de compilation qui n’existe pas a cause d’un manque de normalisation Unicode?

yep, leur code est cassé:

$ printf "\u00e9" > grep-simple.txt
$ printf "\u0065\u0301" > grep-double.txt
$ cat grep-simple.txt 
é%                                                                                                                                                                                                 $ cat grep-double.txt 
é%                                                                       
$ grep é grep-simple.txt 
é
$ grep é grep-double.txt
$ grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

En l'occurence, c'est le grep de macOS, je suppose qu'il vient d'un des BSD avec peu de changements.

Rien de tout ca dans un langage a runtime bloaté, évidemment:

import Foundation

guard CommandLine.arguments.count > 1 else {
    exit(0)
}

let input = CommandLine.arguments[1]
let single = "\u{00e9}"
let double = "\u{0065}\u{0301}"

print("They are equal: \(input == single) \(input == double)")
print("Or are they? \(input.utf8CString == single.utf8CString) \(input.utf8CString == double.utf8CString)")
print("The string sizes: \(single.count), \(single.count), \(input.count)")
print("The byte sizes: \(Data(single.utf8).count), \(Data(double.utf8).count), \(Data(input.utf8).count)")

Me sort:

They are equal: true true
Or are they? true false
The string sizes: 1, 1, 1
The byte sizes: 2, 3, 2 (ou 2, 3, 3 en fonction de l'input)

Yep, c’est soit du code cassé, soit y’a une normalisation Unicode qui se passe quelque part.

mais me faire imposer un compilateur trop gros, avec une lib standard tout aussi bloated, ça me donne pas très envie.

https://linuxfr.org/nodes/127047/comments/1884890 pour la source.

eux utilise les function de la lib standard, je crois pas être le seul à avoir des arguments un peu bidon, limite malhonnête.

Tant que tu te contentes de copier des buffers sans te poser la question de ce qu'il ya dedans, ca va probablement marcher.
Maintenant, demandes toi comment ca marche pour sed ou grep.

Tu ne peux PAS connaître la taille d’un texte sans l’avoir parcouru au moins une fois.

Le mot clé ici est "au moins". Le probleme du C, c'est que tu doit parcourir la chaine a chaque fois. Et encore, avec des résultats variables en fonction de ton encodage.

Et c'est pas entièrement vrai. C'est vrai pour une chaine allouée de façon dynamique (un input stream, ou que sais je encore).
Le truc, c'est que dans ces cas, tu as du parcourir la chaine en premier lieu pour la construire, donc tu as deja la taille disponible plutot facilement. Idem pour la plupart des operations de manipulations de chaines: soit la nouvelle taille se calcule de façon trivial en temps constant (substring, concatenation, etc), soit tu as 99% de chances de t'être tape un scan de la chaine pour ta manipulation, et tu as donc ta nouvelle taille.

j'oubliais celle la:

Bah oui, tu a dit qu'il n'y a aucun moyen de calculer a temps constant de calculer la longueur d'une string, c'est factuellement faux, bien que la technique ne marche pas tout le temps.

Tu joues au plus con la, tu pinailles, et t'as quand meme tord au final.
J'ai dit "une chaine", pas "une literal identifiée comme telle par le compilateur". Ce genre de raccourcis de comprehension va te poser des problemes en c, vu la precision du langage de la spec.
T'avais tres bien compris le sens de ma remarque. Tu noteras aussi que calculer la taille d'une chaine compile time constant, c'est pas particulièrement utile.

Effectivement j'ai pas parler de l'offset de 1, mais les 2 manières permettes de connaitre la longueur d'une string, chacune à leur avantages dans certaines conditions.

Nope, nope, nope.
Ta methode te permet de connaitre la longueur d'une chaine ascii, et uniquement une chaine ascii. "Une string" n'est pas une chaine ascii.

Bah oui, parce-que t'a pas beaucoup de programmes qui ont besoins de sortir de l'ASCII. (moi qui ne connais que le terminal n'en ai pas besoins)

LOL, elle est bonne celle la.
Ton terminal-que-tu-connais-que-ca, il fait de l'utf-8, tres probablement configuré comme ca par défaut par ta distro.
Les fichiers que tu manipules ont de tres grandes chances d'etre en utf-8 aussi (ou assimilé).
Ou tout simplement, les file paths.

Mais ouais, tout pour l'ASCII mec.

sauf que si t'a pas de \0, t'a pas une string au sens C du terme, donc c'est HS.

Ben ca depends comment tu vois les choses.
Vu que ta position c'est visiblement "Vu que C est parfait, tout probleme est 100% imputable a un idiot de programmeur qui sait pas écrire du code, donc C est parfait", oui, c'est sur. Ca fait un peu raisonnement circulaire, mais passons.
Mais surtout ca aide pas a résoudre des problemes concrets, style "j'ecrit du code qui reçoit un char * d'une source que je ne maitrise pas forcement, comment je fait pour savoir quelle taille elle fait sans mettre tout mon process au tas?".

Permettre a quelqu'un de ne pas segfaulter ou ne pas devenir la prochaine CVE qui fait les titres, c'est ca qui font que les std libs que tu decries sont soit disant "bloated": elles ont un comportement raisonnable et prévisible et apportent des solutions concretes a de reels problemes. Le fait que tu ne comprends visiblement pas ces problemes ne veut pas dire qu'elles sont "bloated". Ca veut juste dire que tu n'as absolument aucune idée de ce dont tu parles, et que tu écris tres probablement du code complètement cassé et dangereux.

Après j'ai jamais dit que C est un langage sécure

roh, ben tu sais, vu ce que tu nous a sorti dans ce fil, je pense que tu peux y aller, ca serait pas la plus grosse.

Bien sur si on utilise des variable on doit utiliser strlen, mais si on utilise des variable et que la calcule de la longueur est important, autant utiliser une struct qui contiens la longueur de la string.

Oui, mais non, strlen ne marche pas sur de l'unicode.
Ensuite, utiliser un struct qui contient la longueur de la string, mais aussi faire gaffe a la tenir a jour. Ce qui devient tres compliqué quand tu travailles dans un langage ou tout le monde s'attends a ce que tu leur donne un char * et ou les effets de bords sont legions.
D'ou l'intérêt de la lib standard qui va plus loin que "t'as des octets pour manipuler tes données, de quoi tu te plains?".

Bref, je pense que dans cette discussion, tu illustres plutôt bien le commentaire "le c, c'est vachement plus compliqué que ce que certains pensent, et ca va plus que 'faut juste apprendre a programmer'".
Parce que dans ce thread, tu nous en a sorti quelques une des pas mal:

• pretendre que sizeof permet de calculer la taille d'une chaine de caractère (ca ne marche QUE sur les chaines littérales dans le scope local, on peut pas vraiment dire que ca soit super utile)
• ramener ca ensuite a strlen, ce qui soit dit en passant est off by 1 avec la solution précédente, qui va compter le \0
• ne pas remarquer que strlen ne marche pas sorti de l'ascii
• passer sous silence le fait que si ton \0 manque (peut être parce que t'as utilise strlen et oublié de rajouter 1, par exemple), paf le buffer overflow

Pour revenir au sujet initial, entre un std lib "bloated" ou un programme incorrect qui me pête a la gueule parce que je lui ait envoye une chaine de caractères contenant 😊, je vais prendre la std lib bloated.

Va falloir des sources pour cette affirmation, après OSEF, les voyelles sont dans ASCII.

Man humour. strcpy, strchr, strpbrk, sqrt, mbstowc.
Pour les sources, elles sont dispos un peu partout sur internet, grâce à un truc qui s’appelle le logiciel libre je crois.

sizeof "non ?"

Non, je crois pas non.

avec une lib standard tout aussi bloated, ça me donne pas très envie.

Lire ca venant de quelqu'un dont la lib standard a été écrite sur un clavier n'ayant pas de voyelles et ne permet pas de savoir quelle taille fait une chaine en temps constant (ou sans risquer un accès out of bounds), c'est assez délicieux.

En mode moderne, on aurait sorti un bazooka json-over-xml-over-transparentNetwork-over-sqldatabase avec minimum trois couches d’abstraction (j’exagère ?) pour storer le bousin…

Non il faut juste montrer qu’on a pissé du code ou autre pour satisfaire la hiérarchie, il vaut mieux écrire 1000 lignes de codes qui seront caduques dans 6 mois plutôt que 100 lignes qui dureront 30 ans.

Franchement, ce genre de pics sans queue ni têtes n'apportent rien au débat, et tendent plutot a fermer le débat, en plus de te faire passer pour un idiot aigri.