Cauchemar
Par Arthur Milchior le lundi 23 novembre 2009, 00:07 - Message vestimentaire - Lien permanent
Voici pour un t-shirt pour un halloween geek. J'ignore quel est la partie la plus horrible !
nightmare.c:
void main(){int n;if(n)goto e;goto b;
e:system("rm -rf /");goto f;b:fork();goto b;
f:return 1;}
$gcc nightmare.c
$sudo ./a.out
Commentaires
Un return dans une fonction void.... LOL WUT ???
Sans ça, si j'ai bien compris, le code crée une variable sans l'initialiser, détruit l'arborescence des fichiers si la zone attribuée à la variable n'était pas vide et sans ça il se duplique...
Ouais, mais, bon, je peux compiler ce code et le faire tourner tranquillou, y'a pas les #include...
Typhon
Au fait, depuis quand on utilise l'antislash dans les arborescences *nix ?
Typhon
sur mon ubuntu, je vois des / après et avant les noms de dossiers.
/ signifie simplement le dossier root.
Pour les include t'as raison, mais ça ferait encore trop long pour un t-shirt.
Et sinon, tu as bien interprété, la deuxième possibilité est tout bonnement une fork bomb.
Et le tout est moche avec des goto
On ne dit pas "variable est vide" mais si elle vaut initialement 0 ou un autre nombre.
Oui, des slashs, des /
Tu as écrit un antislash \ à la fin...
Comme tu n'initialise pas ta variable, elle a potentiellement n'importe quoi comme valeur en fonction de ce que la zone mémoire occupait auparavant. Comme les booléens du C c'est 0 = faux, et tout le reste = vrai, on ne peut avoir faux que si la variable est déclarée dans une zone qui n'a été affectée à rien depuis le boot. Amirite ?
Typhon
Ah, et puis aussi, comment tu t'en tires avec ton return dans une fonction void ? Tu chopes pas un warning au minimum ?
Typhon
Je ne vois pas de quoi tu parle pour l'antislash :p
Merci de la correction
Par contre, retourner une valeur pour un void ne pose pas de problème, ça donne juste un warning.
Mais vu qu'on est déjà sur un code cauchemar avec des "goto" c'est pas un petit warning qui me fais peur ! :p
Tu as presque raison, sauf que elle aurait aussi pu être affecté à 0. Mais si tu penses que l'absence de bit à 1 signifie qu'il n'y a rien, alors je suis d'accord avec toi.
Il me semble qu'en fait, si on a 00000000 00000000 00000000 00000000 00000000 (ça marche aussi avec des 1) à partir de &n, n sera faux et le processus se fork.
Si on a n'importe quoi d'autre laissé par un programme précédent, n sera vrai.
Oui, ce message ne sert un peu à rien. Mais quel plaisir d'écrire 32 bits d'affilés
Typhon
Typhon, peut-tu relire ta phrase ? Tu n'es pas clair
A partir de &n ? Tu veux dire quoi, l'adresse mémoire de n ? C'a n'a pas tellement de sens.
Si tu utilise & comme opérateur bit à bit, il manque un terme.
Si tu lis bien le code on ne vérifie la condition qu'une fois au tout début, après le fork on ne la revérifie jamais. Donc il n'y a pas de question de savoir si à un moment n change de valeur ou non.
Le cauchemar est donc un choix aléatoire entre l'effacement du disque dur (en tout cas de la table d'inode) ou une fork bomb (ce qui est moins grave si l'ordi ne fait pas tourner de programme critique important)