Obvious Things C Should Do

[Dukc]

On Monday, 13 January 2025 at 17:53:36 UTC, Walter Bright wrote:
> On 1/13/2025 8:13 AM, Dukc wrote:
>> On Monday, 13 January 2025 at 08:16:48 UTC, Walter Bright 
>> wrote:
>>> D's CTFE does not allow undefined behavior.
>> 
>> It's pretty simple in D since it has the @safe subset where 
>> everything is defined behaviour anyway.
>
> It's a bit more than that. It doesn't allow shift counts larger 
> than the size of the field being shifted. It's too expensive to 
> add such a check to runtime code.
>
>
>> But we're talking about C and there it'd be different. For 
>> example, using uninitialised values and signed int overflows. 
>> In the specific case of DMD those are probably still simple 
>> since it can just do what D does in the same situation. But if 
>> you were writing (a formal proposal to change) the C standard, 
>> how would you address those? I suspect it'd be complicated.
>
> It wouldn't be hard for the engine to mark uninitialized 
> variables.

You're thinking about implementing the engine. But I'm talking 
about rewrite of the standard. Wouldn't the committee suddently 
have to remove and define the majority of undefined behaviours 
from the spec, at least when executed at compile time? Just think 
how many undefined behaviours C has. I think it'd mandate lots 
and lots of extra paperwork and design debates.

I'm not saying it couldn't be done, but it's hardly the obvious 
low-hanging fruit your article claims.