Pourquoi ? parce que ce sont des passoires et qu'elles sont responsables d'une bonne partie des dépassements de tampons, mets délicats utilisés pour injecter données et code afin d'altérer le fonctionnement d'un programme dans des buts souvent fort peu avantageux pour l'utilisateur. Responsables des failles de sécurité quoi.
On est vendredi et je vous jure que je n'ai pas fait exprès de tomber dessus aujourd'hui même mais le billet du blog SDL [2] (Security Development Lifecycle, pas l'autre) se termine sur une petite pique qui cache le troll :
I wonder when Larry, Steve and Linus will start banning strcpy() in their products?. Ça a au moins le mérite de ratisser large même si cela reste approximatif. Une pointe d'humour qui se cache dans une question fort intéressante.
Alors pour ou contre HADŒPI les fonctions explicitement bannies ? Combien de fois Ulrich Drepper utilisera fuck, crap ou you don't pay me, do not fill bug reports dans ses réponses du bug tracker ? Autant de questions en suspend qui me font espérer d'avoir encore une connexion internet demain.
[1] : http://msdn.microsoft.com/en-us/library/bb288454.aspx
[2] : http://blogs.msdn.com/sdl/archive/2009/05/14/please-join-me-(...)
# bannir "connect"
Posté par thedidouille . Évalué à 1.
On devrait aussi rétablir la ceinture de chasteté, combien de temps avant que l'on se rende compte de son absolue nécessité dans la jungle où nous vivons?
Franchement HS, je sais mais bon.
[^] # Re: bannir "connect"
Posté par Gui13 (site web personnel) . Évalué à 4.
Je ne comprend pas leur motif: si les bugs viennent de là, il faut les corriger, pas bannir la fonction sous prétexte que son mauvais usage a conduit à ce bug!
On ne bannit pas les voiture sous prétexte que, mal utilisée, on peut se flinguer avec!
[^] # Re: bannir "connect"
Posté par Zenitram (site web personnel) . Évalué à 10.
Il est quand même assez évident :
avant, il fallait faire en gros :
char destination[1000];
if (strlen(source)<1000)
strcpy(destination, source); //C'est safe
else
setrncpy(destination, source, 1000); //safe tout le temp mais lent, car rempli toujours les 1000 chars avec du padding si necessaire
alors qu'avec, ça donne vite fait :
char destination[1000];
strcpy(destination, source, 1000); //C'est safe et rapide
Bon, maintenant, je dis ça, mais je suis programmeur C++, donc vive std::string!
[^] # Re: bannir "connect"
Posté par Thierry . Évalué à 7.
Pas vraiment safe, en fait, parce que si tu as plus de 1000 caractères, la destination n'aura pas son '\0' final...
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 2.
char *plop;
asprintf(&plop, "%s", chaineACopier); // /!\ GNU_C et BSD
...
free(plop)
>Bon, maintenant, je dis ça, mais je suis programmeur C++, donc vive std::string!
Heureusement qu'il y a boost alors, car sinon il manquerait le stricmp, et pleins d'autre fonction utile pour les strings
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par Anthony Jaguenaud . Évalué à 4.
int ret_libC = 0;
ret_lobC = asprintf(&plop,...);
if (ret_lobC == -1)
{
/* Gerer l'erreur */
}
Pour faire du code propre, il faudrait commencer à récupérer tous les codes de retour. Ca enlèverai déjà beaucoup de faille.
Mes 30 cents.
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 2.
j'aurais du écrire
char *plop=NULL;
if ( asprintf(&plop, ... ) == -1 ) {
...
}else{
...
free(plop);
}
Heureusement une compilation avec -Wall permet de corriger pas mal d'oubli d'initialisation ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par pasBill pasGates . Évalué à 4.
strncpy_s lui te garantit que tu n'auras _jamais_ un cas ou le buffer n'a pas de NULL dans sa taille allouee, si tu passes un count qui est plus grand que la taille de buffer specifiee, il met un NULL au debut du buffer et retourne une erreur.
--> Tu es sur de ne pas te choper un buffer overflow si tu t'amuses a faire un strlen() apres par exemple.
La est toute la difference, et c'est la qu'on voit qu'un gars comme Ulrich Drepper qui considere ces fonctions comme inutiles est un idiot incapable de se remettre en question.
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 2.
j'ai en général du code autour
if ( (n = snprinft(...) ) >= taille) )
{
gérer le cas (en général, un realloc)
}
Utiliser des chaines tronqués dans mes codes n'est pas un truc que je puisse me permettre, ou alors j'ai après le snprintf (tout comme avec le strcpy)
chaine[n-1]=0; mais ces cas sont exceptionnels
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par pasBill pasGates . Évalué à 2.
j'ai en général du code autour
C'est justement tout l'interet de ces nouvelles fonctions, avec elles, que tu aies ce code ou pas, tu es protege.
Avec ton code, si par malheur une fois tu oublies, bonjour les degats.
Utiliser des chaines tronqués dans mes codes n'est pas un truc que je puisse me permettre, ou alors j'ai après le snprintf (tout comme avec le strcpy)
chaine[n-1]=0; mais ces cas sont exceptionnels
strlncpy ne tronque pas mais te donne une erreur si l'espace n'est pas suffisant, et si tu ne peux pas te permettre de tronquer, alors ton chaine[n-1]=0 n'est pas une solution, parce que ca revient a tronquer le dernier caractere, sauf si tu passes n-1 comme taille de buffer, mais la ca devient vraiment un bordel le code pour au final faire la meme chose que strnlcpy fait proprement.
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par tuXico . Évalué à 3.
Belle analogie.
On n'a jamais vu de constructueurs de voitures rappeler des séries à cause de vices.
[^] # Re: bannir "connect"
Posté par mrlem (site web personnel) . Évalué à 1.
Ça c'est sûr :
http://www.problemauto.com/?655/Mercedes-rappelle-130-000-vo(...)
http://www.7sur7.be/7s7/fr/1783/Usines-d-auto/article/detail(...)
http://www.liberation.fr/economie/0101561983-general-motors-(...)
(au passage, je ne sais pas si c'est voulu, mais j'aime beaucoup cette orthographe ;o)
[^] # Re: bannir "connect"
Posté par tuXico . Évalué à 3.
[^] # Re: bannir "connect"
Posté par dest . Évalué à 2.
[^] # Re: bannir "connect"
Posté par Étienne . Évalué à 1.
Étienne
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 1.
Nan, parce que n'importe quel langage decent permet de faire un :
String brezilien = "toto";
String foo = brezilien;
if(foo.length < 3)
{
print("samba reggae!!!");
}
else
{
print("Samba do bahia do braziu");
}
sans avoir a utiliser de fonctions obscures.
Autant je peux comprendre pour le C, bas niveau tout ca, autant pour le C++, ca me depasse...
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 6.
string brezilien = "toto";
string foo = brezilien;
if(foo.length() < 3)
{
cout << "samba reggae!!!";
}
else
{
cout << "Samba do bahia do braziu";
}
Voilà, t'as ton truc en C++.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 1.
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 6.
Que C++ utilises des char * comme en C, et que java utilises directement la mémoire, cela change quoi ?
Tu penses que toute classe (ou structure pour le C) va te péter à la gueule car cela utilise des types de base ?
Rassures-toi, lorsque la fonction est bien codée, ce qui est la cas pour la plupart des std::string, cela ne va pas plus te péter à la gueule que n'importe quel string faussement type de base d'un langage de plus haut niveau.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 2.
- en c++ variable string + "literal" marche uniquement parce que l'operateur + a ete surdefini (itou pour le constructeur de copie avec l'assignement).
Ca marche parce qu'un des membres de l'operation est un String et que donc c'est l'operateur redefinit qui est applique.
Par contre, si tu fais "toto"+"tata", ca va peter, parce que ni toto ni tata ne sont des string, mais bel et bien des char*.
Bref, on a un truc qui ressemble a s'y meprendre a une String, mais qui n'en est clairement pas une du tout.
- Le truc avec java (ou n'importe quel autre langage decent qui traite les chaines comme des chaines, et pas comme des tableau d'un autre type...), c'est pas qu'il utilise directement la memoire.
'fin si, il le fait, mais on s'en cogne, c'est pas la question ici.
Ce qui est interessant c'est que le literal "toto" est un objet de la classe String.
Et que donc le comportement est strictement le meme que variable + variable1.
tu peux meme faire "toto".equals(variable);
C'est meme d'ailleurs ce qui est recommande de faire (ca t'evite un check de pointeur nul si tu renverses l'expression).
Ton literal EST un objet, pas un char*. "toto".getClass te retourne String, "toto" instanceof String te retourne true etc.
Bon courage pour faire ca en c++.
Bref, le probleme de fond, c'est que le langage n'as PAS de classe String (String est visiblement dans une lib, qui meme si elle plus ou moins standard et utilisee par tout le monde, n'est pas dans le langage, donc "toto" reste un char* et ne sera jamais une instance de string).
Et pour un langage objet, qui se veut moderne, c'est pour le moins deroutant.
Je me doute que c'est pour des raisons de compat avec le C, mais ca change rien au pb...
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 2.
Avoir séparé tout les conteneurs et bien d'autres choses dans une bibliothèque (et non librairie) faisant partie du langage, mais pas inclue par défaut est un choix.
Puis finalement, c'est sur que additionner deux char * entre eux ne va pas compiler. Mais cela n'a rien à voir avec les problèmes des fonctions dont font l'objet le journal.
Si tu tiens à faire "foo" + "tata", et que ça compile, c'est string("foo") + "tata". Un "toto" == variable en string("toto")==variale. Un "" et un string sont deux choses différentes en C++. Un développeur C++ doit être conscient de ça, et cela n'est vraiment pas un problème.
C'est vrai que c'est plus long à écrire, que dans les cas présents il faut créer des objets, mais même sans avoir besoin d'être compatible avec le C, je pense que ce serais comme ça.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 1.
Tu te fout de moi?
Ca ressemble a une string, ca s'ecrit comme on ecrit naturellement une string, ca s'assigne a une string, ca s'additione a une string.
Mais c'est pas une string.
C'est un tableau (meme pas en fait, un pointeur).
Pour moi, un tableau c'est ca : ['t', 'o', 't', 'o', '\0'];
Certainement pas "toto".
Un "" et un string sont deux choses différentes en C++. Un développeur C++ doit être conscient de ça, et cela n'est vraiment pas un problème.
Ben a partir du moment ou il faut en etre conscient et que une string n'estp as une string, si c'est pb, on s'embrouille pour rien.
Et ca a voir avec les fonctions dont parle le journal, tout du moins pour le c++, c'est que pour le c, ca va pas trop le toucher.
Si la classe String etait un vrai type de base, on aurait surement moins de pb avec les strcpy et autre en c++... et on sera pas tente de reimplementer soit meme la roue ou de se fader des char*
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 3.
string n'est qu'un raccourcis pour basic_string et en redéfinissant ce truc là, tu peux avoir des string ne s'occupant pas de la différence majuscule/minuscule, et d'autre détails encore.
C'est un type complexe gérant plein de petit truc, comme le find, rfind, erase, find_first_of, find_first_not_of, find_last_of...
Je regrette, un type de base n'as pas toutes ces fonctions, c'est un objet.
ensuite j'ai vu plus haut des
string plop="chaine";
Bordel! on est pas en C!
string plop("chaine");
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 2.
String n'est pas un type de base?
Pourquoi donc TOUS les autres langages (C mis a part) l'implementent comme un type de base?
Surement parce que j'ai encore jamais vu un seul programme qui n'utilise pas des strings...
C'est un type de base au meme titre que int, float, char, boolean et tous leurs potes.
Sinon tu pourrais aussi dire que c'est pareil pour les int: signe, ou pas? 32 bits? pourquoi pas moins ou plus? Allez, paf, transformons implicitement 2 dans "variable + 2" en void* et faison planter le programme qui fait ca. Le dev a qu'a faire variable + int(2), apres tout, on est pas en C, non mais.
Ou les char? ASCII 7 ou 8 bits? UTF-8? ISO 8559-1?
C'est sur qu'il va falloir en faire un objet pour integrer toutes les methodes, mais ca n'empeche pas d'avoir une string literal qui soit reellement une string, plutot que de la transformer implicitement dans un type qui n'a strictement rien a voir avec sa representation dans le code.
C'est un type complexe gérant plein de petit truc, comme le find, rfind, erase, find_first_of, find_first_not_of, find_last_of...
Je vais me faire allumer, mais non, std::String ne gere pas plein de petits truc, elle gere a peine la base de la manipulation de string.
Ce que tu viens de citer, c'est 95% de l'api string et c'est a peine suffisant pour manipuler decemment une quelconque chaine dans les cas les plus simple.
Compares a n'importe quelle autre API string, ca fait un choc de voir ce que std::String gere en comparaison.
Pas de split. pas de trim, pas de regexp, aucune gestion du upper/lower case, pas de starts/ends with, un replace en mousse, pas moyen d'obternir la version string des autres types de base...
Resultat, oblige de reimplementer soi meme une bonne partie de la roue, et du coup on se tape des pinpins qui utilisent gets() ou strcpy().
Il est la le lien avec le probleme, pour repondre a n-2.
[^] # Re: bannir "connect"
Posté par mota (site web personnel) . Évalué à 3.
C'est une structure complexe que tu ne peux pas representer statiquement en memoire, elle depend tres fortement des besoins en ressources du programme.
Donc oui, "tous" les autre langages que le C et ses dignes heritiers ont un type string qui fait partie du langage, mais ironie du sort, ils utilisent tous tout un tas de commidites pas forcement jolies pour que le developpeur n'ait plus a se soucier de la gestion des ressources qu'il a pourtant demandees.
Et puis imagine deux secondes que ta classe string ne te plaise pas, tu la retouches comment, tu t'amuses a reimplementer ton compilo ?
Faut etre serieux deux secondes, je veux bien que le java fasse le cafe, mais ca reste sale.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 5.
gne?
http://www.docjar.com/html/api/java/lang/String.java.html
char[] value : les caracteres eux memes
int offset: offset de debut de stockage dans value
int count: taille de la chaine
'tin c'est super complexe ca!!!
Regardes le code des constructeurs, ca va pas pisser bien loin non plus. La partie la plus relou, c'est les pb d'encodages, qu'il faut adresser de toutes facons.
Une fonction native, intern() qui va bien evidemment dependre de l'endianness du processeur, donc c'est le seul truc que tu peux pas faire en java. Trop dur.
ils utilisent tous tout un tas de commidites pas forcement jolies pour que le developpeur n'ait plus a se soucier de la gestion des ressources qu'il a pourtant demandees.
Comme?
Java a une String immutable ce qui peut etre genant en effet (d'ou le string buffer), l'approche parait bonne, un objet immutable simple et peu gourmand tant que tu le tripatouilles et un truc dedie a la manipulation.
Et puis imagine deux secondes que ta classe string ne te plaise pas, tu la retouches comment, tu t'amuses a reimplementer ton compilo ?
Tu fournis ta propre classe String?
C'est tres tres vilain, c'est sur, mais ca va etre pareil en c++ si tu t'amuses a faire la meme connerie...
Le truc c'est que je n'ai encore jamais vu une seule reimplementation de la class String en Java.
En c++ par contre, hem hem...
Alors c'est possible parce que les chaines de base sont des char*, ce qui rend les choses possibles (en Java, faudrait passer son temps a convertir de user String a system String, ce qui tue un peu l'interet), mais ca aboutit a du code pourri et plombe qui utilise des fonctions des bois et paf le buffer overflow.
Et si ton type int te plait pas, tu fais quoi? Tu patches le compilo?
Faut etre serieux deux secondes, je veux bien que le java fasse le cafe, mais ca reste sale.
Sale?!?!
Au lieu de repeter des trucs que t'as lu dans des trolls a droite a gauche, explique moi ce qui est "sale" dans les string Java.
T'as le source juste au dessus, donc t'as juste a me pointer les endroits crades.
[^] # Re: bannir "connect"
Posté par Sylvain Sauvage . Évalué à 5.
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 2.
Dans combien de fichiers te sert-tu des très petites fonctions ? Inutile d'en mettre partout. Si t'en a besoin, tu importes ton truc. Le seul truc qui manque de base dans la std, ce sont les regexp, mais cela arrivera bien un jour.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par thedude . Évalué à 2.
Tu preferes eclater tes fonctions de manipulations de string sur n paquets, les avoirs dans differentes classes plutot que d'avoir une API propre et utilisable?
Sinon, le trim et le split, je m'en sert couramment. Tres couramment.
Si t'en a besoin, tu importes ton truc
Ben ouais, tu importes ton trucs, tu crees une passoire qui ne verifient pas tout et tu te tapes tes failles de secu, en plus d'avoir perdu 2 jours a mal reecrire un truc que tout le monde utilise et qui devrait etre foutu dans une bonne vieille lib systeme...
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 6.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par fearan . Évalué à 3.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bannir "connect"
Posté par plop (site web personnel) . Évalué à 1.
Petite précision sur cet exemple qui donne une erreur de compilation parce qu'on ne peut pas additionner deux pointeurs. Par contre, ça peut devenir sournois si on fait des choses du style "chaine"+entier, ce qui est valide.
[^] # Re: bannir "connect"
Posté par yellowiscool . Évalué à 2.
C'est le problème de pouvoir tout faire en C.
Envoyé depuis mon lapin.
[^] # Re: bannir "connect"
Posté par totof2000 . Évalué à 4.
C'est surtout le problème de ne pas utiliser le langage adapté au besoin.
Il ne faut pas oublier que le C a été fait à la base pour pouvoir faire facilement des choses de "bas niveau" .... Le fait q'il permette de tout faire est un atout certain ... mais si on l'utilise pour faire des choses qu'un langage moins permissif ferait tout aussi bien (voir même mieux), ce n'est pas la faute du langage ....
Pour le C++, c'est un peu la même chose : un "C" évolué qui permet de faire des choses bas niveau ...
# Le libre et les standards...
Posté par Zenitram (site web personnel) . Évalué à 5.
A noter que le compilateur MS met un warning sur ces fonctions, désactivable, et pas une erreur, donc "banni" est un bien grand mot.
[^] # Re: Le libre et les standards...
Posté par suJeSelS . Évalué à 0.
J'espère que tu ne codes pas en C toi, car si tu fais aveuglément confiance en ces fonctions autant ne pas les utiliser. Safe est un grand mot, à part envoyer une erreur à un développeur perdant de vu ce qu'il développe sans vérifier la cohérence des données qu'il manipule ça ne sert à rien. Qu'un strncpy te donne une erreur, c'est un moindre mal, mais retrouver son origine est très loin d'être toujours simple si on ne se base que sur les erreurs de ces fonctions.
D'ailleurs ces strn* sont loin d'être exemptes de problèmes et nécessitent de toute manière certaines vérifications avant d'être utilisées.
Si on ne gère pas proprement la cohérence des données qu'on utilise on peut vite arriver à des situations de ce genre:
char plop[24];
char plop2[42];
strncpy(plop, plop2, 42);
[^] # Re: Le libre et les standards...
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Le libre et les standards...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
# En même temps...
Posté par suJeSelS . Évalué à 6.
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).
tout le thread pour donner un peu de grain à moudre
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.htm(...)
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00060.htm(...)
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00061.htm(...)
À vos trolls prêt partez!!!!
[^] # Re: En même temps...
Posté par Thomas Douillard . Évalué à 1.
Genre je sais que c'est la libc, que c'est une brique de base importante, que c'est beaucoup utilisé par pleins de programmes et tout, mais si c'est pour économiser quelques cycles CPU pour calculer des tailles, ça va à priori pas changer monstrueusement le système en un gros veau.
Sauf cas très particuliers peut être.
[^] # strlcpy plus rapide que strncpy
Posté par Victor STINNER (site web personnel) . Évalué à 3.
« man strncpy : (...) Dans le cas où la longueur de src est inférieure à n, la fin de dest sera remplie avec des caractères nuls. »
[^] # Re: En même temps...
Posté par Victor STINNER (site web personnel) . Évalué à 5.
[^] # Re: En même temps...
Posté par Beretta_Vexee . Évalué à 4.
C'est pas le monsieur qui a motiver l'addoption de eglibc par Debian ? A tien si.
Vous en tirez les conclusions que vous voulez.
[^] # Re: En même temps...
Posté par Amand Tihon (site web personnel) . Évalué à 8.
Ulrich peut être insultant et grossier, communique mal, se fout des architectures pseudo-exotiques, et gère mal le coté communautaire de "sa" libc, soit.
Est-ce que c'est une raison pour rejeter en vrac tous ses avis techniques ? Je ne pense pas. Son explication donnée dans le thread indiqué plus haut par suJeSelS me semble tout à fait pertinente. Il en va de même pour d'autres sujets qu'on a pu découvrir lors du buzz debian/eglibc. Il est peut-être sociopathe, mais certainement pas incompétent. Je continuerai à écouter ses avis techniques.
Debian n'a pas adopté eglibc parce que la glibc était mauvaise en elle-même, mais parce que le processus de développement, plus totalitaire que communautaire, et le comportement d'Ulrich Drepper leur demandait une importante surcharge de travail.
[^] # Re: En même temps...
Posté par pasBill pasGates . Évalué à 3.
Perso, je choisis pas le cote d'Ulrich Drepper, notamment parce que les failles je les vois quasiment toutes de part mon boulot et je ne comptes plus le nombre que j'ai vu a cause de strcpy et autres, et j'ai du mal a compter celles avec les fonctions sures parce que je ne me souviens pas en avoir vu alors qu'elles sont utilisees a peu pres partout dans Vista.
Et ca c'est la pratique, pas la theorie...
[^] # Re: En même temps...
Posté par Littleboy . Évalué à 6.
En gros il faut croire sur parole un mec qui te dis que t'est qu'un connard qui n'a aucune idee de ce que tu racontes. Je suis pas sur que ca soit la meilleure methode pour convaincre les gens...
[^] # Re: En même temps...
Posté par Antoine . Évalué à 3.
Et il est très probable que ce comportement rende la glibc plus mauvaise (ou moins bonne) qu'elle ne pourrait l'être. Je ne crois pas qu'il y a beaucoup d'humains normalement constitués (y compris d'excellents développeurs) qui aient envie de contribuer dans une ambiance pareille.
# Pisk'on trolle
Posté par tuXico . Évalué à 8.
En fait, ce qu'il faut interdire, c'est de coder à deux mains, ça fait du code pas secure, alors qu'en se tappant une queue (de singe) en même temps, tout rulez.
Comme je parle d'OpenBSD, on finit par une chanson :
"ça va troller comme sur une plage en été, ça va troller"
# Et pourquoi pas bannir le C entièrement ?
Posté par Moogle . Évalué à 1.
[^] # Re: Il faut bannir la programmation
Posté par fleny68 . Évalué à 9.
[^] # Re: Il faut bannir la programmation
Posté par windu.2b . Évalué à 10.
Dit-il en oubliant une parenthèse fermante !
Encore un codeur Lisp du dimanche, pfff...
[^] # Re: Il faut bannir la programmation
Posté par Perthmâd (site web personnel) . Évalué à 3.
C'est génial comme idée, il me manquait justement un programme qui résolvait le problème de l'arrêt !
[^] # Re: Il faut bannir la programmation
Posté par fearan . Évalué à 6.
Ah mais au fait, j'y pense, le programme permettant de trouver celui qu'on cherche doit s'y trouver!
Y a plus qu'à le trouver...
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Il faut bannir la programmation
Posté par Gof (site web personnel) . Évalué à 1.
Non.
Car il n'existe pas.
Il est démontré qu'il n'existe pas de programme permetant de résourdre le Probleme_de_l'arret
[^] # Re: Il faut bannir la programmation
Posté par Dr BG . Évalué à 7.
[^] # Re: Il faut bannir la programmation
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Il faut bannir la programmation
Posté par Moogle . Évalué à 1.
- Faire un programme qui cherche le programme qui cherche ce qu'on veut (ou le piocher dans la liste).
- Faire une double boucle pour tester chacun des programmes avec l'un des autres.
[^] # Re: Il faut bannir la programmation
Posté par totof2000 . Évalué à 3.
Faut faire gaffe, on court vers le Stack Overflow !!!
[^] # Re: Il faut bannir la programmation
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: Il faut bannir la programmation
Posté par totof2000 . Évalué à 4.
[^] # Re: Il faut bannir la programmation
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Il y en a qui le font !
Posté par gUI (Mastodon) . Évalué à 6.
The following library functions shall not be used: strcpy(), strcat(), sprintf (), and gets().
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# pas frais
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: pas frais
Posté par totof2000 . Évalué à 10.
Monsieur,
En tant qu'avocat des éditions Albert René, je constate que vous avez utilisé une expression nous appartenant dans un de vos commentaires, sans autorisation, ni compensation financière suite au préjudice apporté à mon client.
Je vous propose donc un règlement à l'amiable : je vous sauai gré de bien vouloir verser sur un compte paypal la somme de 300 000 euros, ou nous nous verrons dans l'obligation de vous poursuivre en justice pour obtenir réparation.
Cordialement ...
Me . Vaux Tour et associés.
Avocats.
# bannir et remplacer
Posté par bubar🦥 (Mastodon) . Évalué à 0.
très bien
Mais ils les remplacent par quoi ?
hummm okok je ->
[^] # Re: bannir et remplacer
Posté par pasBill pasGates . Évalué à 0.
# Et la norme ?
Posté par Anthony Jaguenaud . Évalué à 3.
Qu'on impose des restriction à ces employés, pour éviter les bugs de débutant soit. On le fait tous, car souvent, dès que tu commence à maîtriser la programmation, on veut que tu prennent des responsabilité :-( Du coup, tout est programmé par des débutant, ou presque...
[^] # Re: Et la norme ?
Posté par téthis . Évalué à 3.
Je trouve que Microsoft joue plutôt bien le jeu de la sécurité sur ce point.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Et la norme ?
Posté par Anthony Jaguenaud . Évalué à 2.
Ex:
ATTENTION, cette fonction est dangereuse, utilisé plutôt celle-ci (made-in microsoft).
Quelque temps plus tard, le développeur souhaite ouvrir son programme à d'autre plateforme. Réaction à chaud du dit développeur :
"C'est nul cette plateforme, y a pas la fonction micro_supersafe_cpy", je vais rester sur visual et ne plus regarder ailleurs.
J'ai sans doute tort, mais ça me semble un peu abusé de mettre des warning sur des fonctions faisant parti de la norme. Microsoft devrait plutôt tenter de les sortir de la norme, puis de les faire remplacer dans la norme, puis de les implémenter.
[^] # Re: Et la norme ?
Posté par téthis . Évalué à 2.
#ifdef __MSVC__#define func func_s
#endif
Ou si ce n'est pas le cas, il me semble que ça reste assez trivial à gérer. Pas envie d'installer Windows sur une machine, ni de télécharger l'environnement de compilation de Microsoft pour confirmer :p.
C'est sûr que si des fonctions de remplacement safe faisaient partie d'une norme ce serait plus simple à gérer.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Et la norme ?
Posté par windu.2b . Évalué à 4.
C'est moi ou y a une erreur dans l'ordre des actions ?
Il vaudrait mieux d'abord faire rentrer les nouvelles fonctions dans la norme puis les implémenter puis en faire sortir les fonctions dépréciées, non ?
[^] # Re: Et la norme ?
Posté par Anthony Jaguenaud . Évalué à 2.
\<private\>A noter : ne pas répondre à l'heure de la sieste\</private\>
[^] # La norme evolue et va integrer tout ca...
Posté par Littleboy . Évalué à 4.
Ca fait maintenant un petit moment que ces fonctions sont marques comme deprecated dans la lib CRT de Microsoft (tu peux virer les warnings avec un define global dans ton projet, donc si tu fais du code portable, c'est pas trop genant).
Sinon, il y a un groupe de travail au niveau ISO (TR24731) qui reflechit justement sur ces questions, donc accuser MS me parait un peu bizarre (on va mettre ca sur le compte de l'ignorance et le fait que les resultats Google sur le sujet sont a la ramasse en ce moment). C'est meme note sur la page wikipedia (meme si pas explicite).
http://en.wikipedia.org/wiki/C99 (voir section Future work)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1225.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1337.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/projects
En en parlant de code non portable et de specificites des compilateurs, on pourrait parler un peu des extensions GCC, mais on est que lundi...
[^] # Re: Et la norme ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui, mais non : l'incompatibilité volontaire, c'est la libc Linux qui la fait.
Microsoft utilise des fonctions ISO/IEC, donc bien standardisées.
Après, si la libc Linux refuse d'implémenter des standards, ce n'est pas la faute de MS qui a travaillé sur le processus de normalisation...
[^] # Re: Et la norme ?
Posté par lasher . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.