Panne sur les abonnements Programmez!

Les informations relatives aux abonnements et les accès aux archives PDF liés aux abonnements papier ne fonctionnent plus depuis plusieurs jours dans les comptes utilisateur sur notre site. Comme vous l'avez constaté, ou lu dans les medias, de nombreux éditeurs de presse connaissent une situation similaire. Cette situation est due à une panne informatique de grande ampleur chez le Groupe GLI, la société qui gère nos abonnements papier. Cette panne générale a fait tomber les bases de données et les API Web, empêchant toute connexion entre le site de Programmez! et la base des abonnés située chez notre prestataire. Cette situation dure depuis dimanche soir. Programmez! n'est pas le seul magazine concerné par cette défaillance. Nous essayons d'avoir des informations plus précises de la part du groupe GLI. Nous vous tiendrons informés de l'évolution de la situation.

Tout fonctionne normalement en ce qui concerne les abonnements PDF et les accès aux archives PDF liés, ceux-ci étant gérés par notre site seul.

En dépit de ce problème, toutes les commandes de nouveaux abonnements ou de réabonnements passées sur notre site seront traitées et honorées normalement.

Programmez! a toutefois su reconstituer sa base abonnés quasi intégralement. Programmez! 198 sera expédié normalement à la fin de ce moi de juin. Un envoi supplémentaire pour les abonnés non livrés sera fait dès que GLI aura restauré son système.

Ce code est un non sens, il ne compile que par accident !

Par:
fredericmazue

ven, 26/02/2016 - 14:04

Voilà qui pourrait faire suite à l'actualité Faut-il tout réécrire en Rust que nous avons publié en milieu de semaine.

Dans cet article, un développeur de Mozilla, considère qu'il faudrait utiliser Rust en lieu et place de C/C++ car Rust est un 'langage sûr' en comparaison des deux autres. L'utiliser serait selon lui un moyen de prévenir les failles de sécurité.

Mais le problème est-il dans le langage ou entre la chaise et le clavier (ou encore dans les carences de temps et de budget) ? Telle est peut-être la question.

Le compilateur libre GCC 6 va sortir en version finale en avril prochain. Red Hat a tenté de recompiler avec lui les quelques 17 000 paquets de la distribution Fedora, et l'expérience montre que les échecs de compilation se comptent par milliers.

Un billet d'un responsable de Fedora pointe du doigt le fait que si un bon nombre d'erreurs sont dues à des bugs du compilateur ou à des régressions de celui-ci, l'expérience révèle aussi de très mauvaises pratiques de programmation. Very poor programming practices. Mauvaises pratiques en l'occurrence révélées notamment parce que GCC 6 adopte le standard C++14 par défaut et non plus C++98.

Une discussion connexe, repérée par developpez.com est assez éloquente. Un développeur, qui reconnaît qu'un code est douteux et non respectueux du standard, demande malgré tout aux développeurs de GCC 6 que celui-ci n'émette plus un message d'erreur mais seulement un avertissement. Avec finalement pour seuls arguments que GCC 5 acceptait le code et que désormais il n'est plus possible d'utiliser l'API de Julia. (Ce qui en d'autres termes revient à dire que l'API du langage Julia est mal foutue :-)

Le code, réduit à ce qui génère l'erreur de compilation :

typedef struct mytype {
    struct mytype *fieldptr0[];
    struct mytype *fieldptr[];
} mytype; 

int main(int argc, char** argv) {
  return 0;

La réponse d'un des développeurs de GCC 6 est sans appel :

Ce code est un non sens. Qu'est-il supposé faire ? Il ne sert à rien et compile seulement par accident. L'autoriser avec le commutateur à compiler les ordures -fpermissive  pourrait peut peut-être faire sens toutefois...

The code is nonsense, what's it even supposed to do?
It would be invalid in C (where flexible arrays are actually standard) because flexible arrays can only be the last member, *and* because apart from the flexible arrays it's an otherwise empty struct. It's useless, and only compiled by accident.
Allowing it with -fpermissive might make sense though, as that flag allows all kinds of terrible rubbish to compile.

C'est dit...

Alors les problèmes de sécurité et plus généralement de code foireux, sont-ils fondamentalement situés dans le langage utilisé, ou entre la chaise et le clavier ?

Qu'en pensez-vous ?

Commentaires

C'est vrai que la source des codes foireux est toujours située entre la chaise et le clavier. Mais l'erreur est humaine, et même le meilleur des développeurs finira tôt ou tard par être à l'origine d'un code foireux. Et c'est là que les langages "sûrs" surpassent les langages permissifs, en évitant un certain nombre de ces erreurs.

Et puis, le "meilleurs des développeurs" qui ne ferait que très exceptionnellement des erreurs, je ne l'ai pas encore rencontré...