David Marec a écrit 472 commentaires

Effectivement, le pointeur n'est pas initialisé, enfin… pas toujours

En fait, le pointeur n'est probablement pas initialisé, quand il existe.
L'optimisation a probablement réduit l'instruction à:

#include <iostream>

int main(void) {

    std::cout << 0 << "\n" ;
    return 0;
}

Par non défini, il faut comprendre «non défini par la norme». Le compilateur, lui, va suivre ses propres règles, qui peuvent varier d'une cible à l'autre.

On en a déjà causé dans cet autre journal.

C'est une excellente nouvelle que FreeBSD arrive à se débarasser d'outils comme les r-machins.

Par contre, pour ruptime(1), rwho(1) et rwhod(8), c'est reporté à la 12.
- Errata publié le 9 août -

Enfin, Hammer2, je ne suis pas sûr que Hammer fasse du copy-on-write.

[lldb GUI] C'est m'en servir, que je n'ai pas réussi. Bon, je parle de la version de Debian aussi, devait être debian 7, donc ça a dû changer pas mal.

En fait, il suffit de lancer les mêmes commandes au clavier (s/n/c/ etc.) pour suivre l'évolution dans le code. Ça reste simple.
Par contre, il ne fonctionne pas, ou très mal, chez moi sous (u)rxvt, je n'ai pas encore trouvé d'où venait le problème.

bmake

C'est le make issu de NetBSD et c'est un make considéré comme portable. Il a été adopté sous FreeBSD 10 de mémoire et a remplacé pmake. Le make gnu est dans les ports, le cas échéant.

getaddrinfo(1)

C'est une commande, un wrapper, autour de la routine getaddrinfo(3) qui elle, existe depuis au moins FreeBSD 4 ( elle a du arriver quelque part en 3.x).
Elle est là pour tenir compagnie aux netstat et autres sockstat.

lldb

J'ai trouvé assez simple l'utilisation de la gui lldb pour ma part, il suffit de taper gui à l'invite. Je conseille quand même de charger le code et les breakpoints avant. C'est bien plus utilisable que le mode tui de GDB.

Partage de code

Il y a toujours une coopération et du partage de code entre les différents BSD, de Open à Dragonfly.
- pf, bmake, procctl, balcklistd, pilotes … C'est aussi une question de réseaux je pense. Les développeurs se rencontrent lors des BSDCon et communiquent leurs expériences plus facilement au sein de la famille.

N'oubliez pas la coopération avec illumos, notamment avec zfs, dtrace et bientôt mdb ?

La disparition de groff est également une excellente nouvelle,
la documentation va pouvoir être uniformisée.

Notez que mandoc ,
- C'est un projet indépendant -
branché sur la 1.14, a subit beaucoup de modifications; entre autres, il ne dépend plus de sqlite.

La question était juste "Est-ce que la qualité intrinsèque du code des noyaux BSD peut expliquer le faible nombre de CVE ?".

Oui, et donc ? Combien de CVE ?

L'étude démontre qu'en regardant de plus près le code on trouve plein de bugs

Plein ?

donc la réponse à la question est "Non".

Mouais, au vu du peu de rigueur de l'étude, la réponse reste «'faut voir.»

---

Des bugs, des commits, tout plein: https://freshbsd.org/

Donc on ne sait pas si les BSD ont un faible nombre de CVE d'une part,
et on ne sait pas, si c'est le cas, à quoi c'est vraiment dû.

Et on ne sait pas non plus si les bugs qu'il a trouvé méritaient un CVE.

---

Et puis pour répondre à Ted, FreeBSD propose reallocarray maintenant.

Je n'ai pas bien compris quel était le problème en fait. Sans doute parce que je ne sais pas ce que fait OpenBSD pour s'installer sur des ARM.
Je «configure» l'installation sur le disque depuis une console et non par l'installeur, même sur un PC classique, en fait. Ensuite, bsdinstall(8) peut se lancer à n'importe quel moment.

Mais il serait cependant plus judicieux pour moi dans mon apprentissage comme pour le dev, de publier cela d'une facon officielle

• FreeBSD Mastery: Storage Essentials
  • MBR/disklabel partitioning, used by older and embedded systems
  • Custom FreeBSD installs

C'est une excellente nouvelle que FreeBSD arrive à se débarrasser d'outils comme les r-machins.

Le plus curieux, c'est que rwall(1) soit toujours là.

Une forme d' hommage peut-être.

La disparition de groff est également une excellente nouvelle, la documentation va pouvoir être uniformisée.

En fait, il y a plusieurs modifications sur la chaîne de mandoc(1) dont makewhatis(8). ( il y a une petite boulette dans les notes à ce sujet, mais je n'ai pas du le dire assez fort ).

L'intérêt de Microsoft et AWS pour FreeBSD est toujours présent
et c'est une excellente nouvelle qu'ils aient contribué à la couche drivers pour leurs cloud respectifs,
c'est un frein de moins pour l'adoption de FreeBSD

Il faut dire que l'intérêt affiché de compagnies comme NetAPP (qui a ses serveurs chez AWS ) ou Whatsapp ( donc Facebook ) pour FreeBSD ne doit pas être étranger à cette stratégie.

A-t'il déjà été tenté de redévelopper less avec un langage plus moderne ?

Par exemple, C11 ?

Si l'on veut rester pédant dans la définition, «déléguer» ne convient pas non plus: il n'est pas question là d' autorité ou de représentation.

GCC n'est pas l'initiateur: c'est un choix du développeur.

GCC est débarrassé d'une charge, comme un axe routier se retrouve soulagé par un itinéraire de délestage.

'optimisation choisie par le compilateur confirme ce que je pensais: si l'on doit donner une valeur au résultat (non défini d'après la doc)
ça ne peut être que la valeur 0 (la seule qui soit parfaitement logique).

En fait, non. Si vous regardez le code généré, l'optimisation va zapper tout le code et se résumer à

int main(){
 return 0;
}

Si vous forcez l'affichage du résultat, GCC7 donnera 0, CLang donnera ce qu'il trouve sous la variable.
Mais aucun des deux ne tentera de faire un shr.

Cela dit, même entre deux versions d'un seul compilateur sur un seul langage,
on pourrait aussi avoir des comportements différents
(surtout sur des comportements non définis).

Dans un monde idéal, cela ne devrait arriver que pour les comportements indéfinis.
Mais, comme on l'a vu dans une précédente dépêche sur l'ordre d'évaluation en C++, c'est aussi le cas lorsque on laisse trop le champ libre à l'interprétation.

Dans l'absolu, il faudrait en fait préciser le couple (langage, compilo) pour chaque exemple,
mais ça devient vite vachement moins facile à appréhender.

Plus traître: activez les optimisations … et vous obtiendrez 0 en C++ et en C avec GCC7 et n'importe quoi avec CLang4.
Parce qu'aucun des deux n’effectuera de shr lors de l'optimisation, en fait.

Oui,je trouve malvenu de mettre les deux langages dans le même panier pour ce genre de problème.
Si, dans le cas présent, la norme dit la même chose: «undefined behavior», il faut se méfier; ce n'est pas toujours vrai.

À vérifier, mais je crois qu'il y a eu une tentative de «normaliser» le résultat en C++.

Ce n'était nullement une alliance entre l'URSS et le troisième Reich mais un pacte de non-agression.

Foutaises. Les deux armées ont attaqué la Pologne, qu'ils s'étaient partagés au préalable.
( ainsi que d'autres pays, au passage ).
Par exemple, après avoir capturé la forteresse de Brest-Litovsk, les allemands ont sagement attendu l'armée rouge pour lui refiler les clefs. Ils ont même paradé ensemble dans la ville.

Ensuite, Staline a tout fait pour plaire à Hitler. tout; jusqu'à ignorer les avertissements et les rapports de ses services de renseignements.

Faudrait pas oublier que la « grande Russie », à l’époque l’URSS,
a été notre alliée
au même titre que les USA pour nous débarrasser du fascisme hitlérien.

Non. Absolument pas.

L'URSS de l'époque était l'allié des USA et du RU
( et encore, pour ce dernier, c'est moins clair ).
La France avait jeté l'éponge et ouvert la porte aux armées allemandes. Staline n'a pas manqué de le rappeler, à Yalta.

Et, peu de temps auparavant, l' URSS était l'allié de l'Allemagne, sur le dos des polonais, allié de la France.

Cela dépend du point de vue.

Du point de vue du développeur, stricto sensu, c'est un outil de gestion de projet.
Il n'est pas utile pour produire, déverminer ou tester (quoique) son code.

Il sert à le publier.
D'un autre coté, c'est utile pour le maintenir.

Pourquoi ne mentionner que CLang ?
Pour les plus curieux, d'autres sont disponibles:

• Portable C Compiler ;
• Tiny C compiler;
• Et d'autres, propriétaires.

J'ajouterais:

• tous les outils de débuggage comme truss ou strace, nm, ltrace, ktrace, kdump et cie.
• ceux lié au linker (ld), comme ldd.
• ceux lié à la maintenance patch, diff.

En faîtes,

'gaffe à la chute.

j'utilise la variable,

ifeq ($(OS), UNIX)
COMPILER = $(CXX)

C'est curieux, parce que le retour donné au départ de ce fil utilisait bel et bien g++ et non c++.
Manifestement $(C++) est routé vers g++ dans ce cas.
Mais bon, je ne suis pas un expert en paquets .deb.

je pensait que sauf version serveur tous les système disposait d'un compilateur C++.

Itou, et il ne s'agit pas toujours de g++; j'ai par exemple un système où c++ est lié à g++7 …
Ce que provoquerait la même erreur, de fait.

g++ est le nom du compilateur et c++ est le nom du langage

c++ (langage:C++) et cc (langage:C) sont des liens vers le compilateur livré avec le système en général.

:~$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
...
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

ou

:~>c++ -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.3
Thread model: posix
Selected GCC installation:

D'un autre coté, pourquoi « g++ » plutôt que «c++ » ?

L'usage du mot backdoor dans l'affaire What's app est bel et bien usurpé. Il n'y a même pas de faille AMA,
juste un comportement par défaut choisi pour ne pas faire fuir les utilisateurs.
Là réside un problème plus général: Si l'on veut que le chiffrement soit efficace, il faut que ce soit simple à utiliser et à comprendre.
Imaginons que What's app notifie à chaque fois qu'une clef publique change.
Que va faire l'utilisateur en face ? Si ça l'emmerde sur le moment, il va accepter ce changement et basta. Le résultat en terme de sécurité sera le même que de ne pas faire de notification.
J'associerai ce comportement à celui des pop-up que l'utilisateur acceptera sans en lire le contenu ou les alertes des pare-feux logiciels.
Pour que chaque utilisateur fasse le choix d'accepter ou de refuser le changement de clefs, il faudrait leur expliquer de quoi il s'agit.
A moins que chaque utilisateurs de la chaîne, veuillent réellement une communication confidentielle … bon courage.

Ensuite sur signal, il faudrait effectivement que le code soit complètement ouvert pour être sûr qu'une
porte dérobée n'y est pas cachée.
Récemment, des représentants de gouvernements, dont le notre, reprochaient à Signal son système de chiffrement trop sûr; et ce, bruyamment.
En parallèle, nos forces de l'ordre interpellaient un certains nombres de présumés terroristes qui "communiquaient via Signal".
Je ne peut m’empêcher de croire qu'il y a anguille sous roche; pas nécessairement une backdoor, les services de renseignements ont certainement beaucoup d'imagination.

Je verrais plutôt quelque chose de similaire à ce que vous avez utilisé pour l' endianness.
C'est à dire une directive pour indiquer la taille minimum de stockage d'une donnée ou/et quelque chose de plus générique comme 8/16/32/64.

Cela donnerais quelque chose comme les std::setiosflags du C++ pour formater les flux.

.big-endian
.decimal,2bytes
123
456
.decimal,4bytes
5
-98
.text,utf8
"coucou"
.text,utf8,iso8859-1
"@èà−Ç"

On pourrait même faire les deux et gérer les crochets pour n'affecter que la donnée en cours, mais ça alourdirait la syntaxe sans apporter grand chose à mon avis.

D'ailleurs, il faudrait préciser l' endianness affecte aussi les textes, dans les cas où l'encodage prend plus d'un caractère.

Sinon, bravo, j'adore l'idée.

Décision de justice = État de droit, pas décision de justice = censure d'État

N'oubliez pas l' auto-censure et la censure dirigée depuis la maison mère du FAI.
On peut imaginer, mais c'est de la science-fiction, qu'un FAI lié par son groupe à un marchand de produit culturel censure les sites coupable de contrefaçons de ces mêmes produits.