Je vais avoir besoin de savoir ce que tu appelle programme un peu complexe et aussi d'exemple d'undefined behavior qu'on ne peut éviter.
Un programme un peu complexe c'est à dire tout programme un peu plus utile que hello world.
Et des undefined behavior c'est, par exemple, overflow de signed integer, ou déréférence d'un pointeur invalide, ou un cast sur un mauvais type, ou une data race.
Il me semble que les undefined behavior du C correspondent à des cas très précis et le plus souvent documenté par l'implémentation.
Ne pas confondre « undefined behavior » et « implementation defined behavior ».
Si tu fait du C, la spec du hardware n'a aucun intérêt, sauf si tu utilise des extension genre asm ou autre intrinsics. Et en particulier, si tu crois que la spec du hardware rends les undefined behavior prévisible, tu fait une belle erreur.
[^] # Re: Aucun !
Posté par Gof (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 5.
Un programme un peu complexe c'est à dire tout programme un peu plus utile que hello world.
Et des undefined behavior c'est, par exemple, overflow de signed integer, ou déréférence d'un pointeur invalide, ou un cast sur un mauvais type, ou une data race.
Ne pas confondre « undefined behavior » et « implementation defined behavior ».
Si tu fait du C, la spec du hardware n'a aucun intérêt, sauf si tu utilise des extension genre
asmou autre intrinsics. Et en particulier, si tu crois que la spec du hardware rends les undefined behavior prévisible, tu fait une belle erreur.À lire: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html