Sujet : Re: Computer architects leaving Intel...
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.archDate : 04. Sep 2024, 08:20:10
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vb91na$3nlvo$4@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 03/09/2024 21:30, Stefan Monnier wrote:
Specifications are an agreement between the supplier and the client. The
The problem here is that the C standard, seen as a contract, is unfair
to the programmer, because it's so excruciatingly hard to write code
that is guaranteed to be free from UB.
That's what I do for a living. And I'm not exactly unique here. If we charge money for a product with code, and there's a bug in the code, that is covered by the product's guarantee, just like design faults in the hardware.
Basically, hitting UB at run-time means a bug in the code because the program does not do what you intended. And if you hit a bug in the code, then the behaviour is not what you defined in the code specifications - it is UB.
As I see it, the task of avoiding UB in general is simply the task of writing bug-free code. That can definitely be hard, regardless of the language.
But if you are thinking specifically of "popular" UB in C, such as dereferencing null pointers, overflowing signed arithmetic, using pointers after "free", or accessing arrays out of bounds, then no, I don't think it is hard at all. Seriously, it is extremely rare that I have bugs in my code from such UB, even during early development. Maybe it is the type of code I write (it's a somewhat niche field), or the way I do my development, but it just is not a problem. (I can have plenty of other kinds of bugs, of course!)
What /definitely/ does not help is for a language to define incorrect behaviour in order to say it doesn't have undefined behaviour. A classic example is defining signed integer overflow as two's complement wrapping. That does not fix any errors in the code - it just guarantees that the code will produce incorrect answers which can later lead to nasal daemons, but that it won't launch the nasal daemons immediately. So your tools can't do as much to help catch the errors (from static error checking, debuggers or sanitizers), and the compiler can't generate as efficient results for correct code.