Obvious Things C Should Do (page 2)

January 12

Re: Obvious Things C Should Do

Posted by Dukc
in reply to Walter Bright

Permalink

Dukc

Posted in reply to Walter Bright

Permalink

On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote:

https://news.ycombinator.com/item?id=42669637

I am suspicious that mandating CTFE in C standard would be a good idea. C is full of all sorts of undefined behaviour even in pure functions, and it'd be a security disaster if executing undefined behaviour at compile time would also be undefined behaviour. Also consider cross-compiling: the function might be different in the host and the target platform. This means it'd be quite complex to specify and implement.

Don't get me wrong, I think CTFE is a great idea. But C is intentionally only adding relatively small evolutionary changes. CTFE wouldn't fit that very well, especially since it'd be relatively limited in C thanks to lack of the garbage collector.

As for lack of forward declarations, maybe they want to avoid two different C standards compiling with different semantics.

float foo(){ return 10.0 + bar(); }
float bar(void);

I believe this would compile in C90, but with bar() in foo() "returning" an int and therefore probably corrupting the stack.

On Sunday, 12 January 2025 at 18:49:01 UTC, monkyyy wrote: > On Sunday, 12 January 2025 at 09:51:29 UTC, Paulo Pinto wrote: >> On Sunday, 12 January 2025 at 00:57:11 UTC, monkyyy wrote: >>> On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote: >>>> https://news.ycombinator.com/item?id=42669637 >>> >>> Why do you still follow c's (basicly nonexistent) development after 3 decades of shipping your own compiler? Or do you think this is good marketing? >> >> C23 just came out, and C2y is on the way. > > what amazing things have they shipped? Keep in mind I call d stagnant Plenty of stuff, for folks that want C++ without classes. https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

On Sunday, 12 January 2025 at 09:51:29 UTC, Paulo Pinto wrote: > On Sunday, 12 January 2025 at 00:57:11 UTC, monkyyy wrote: >> On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote: >>> https://news.ycombinator.com/item?id=42669637 >> >> Why do you still follow c's (basicly nonexistent) development after 3 decades of shipping your own compiler? Or do you think this is good marketing? > > C23 just came out, and C2y is on the way. > > It is still the official language of key industry standards like the ones from Khronos and Open Group (POSIX 2024 now requires C17 as minimum), so beloved by FOSS folks. > > It is more existent than it should be. TrapC: Memory Safe C Programming with No UB Paper will be presented by Robin Rowe at the upcoming ISO WG14 C Committee meeting. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3423.pdf Zz

On Sunday, 12 January 2025 at 19:39:29 UTC, Paulo Pinto wrote: > On Sunday, 12 January 2025 at 18:49:01 UTC, monkyyy wrote: >> On Sunday, 12 January 2025 at 09:51:29 UTC, Paulo Pinto wrote: >>> On Sunday, 12 January 2025 at 00:57:11 UTC, monkyyy wrote: >>>> On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote: >>>>> https://news.ycombinator.com/item?id=42669637 >>>> >>>> Why do you still follow c's (basicly nonexistent) development after 3 decades of shipping your own compiler? Or do you think this is good marketing? >>> >>> C23 just came out, and C2y is on the way. >> >> what amazing things have they shipped? Keep in mind I call d stagnant > > Plenty of stuff, for folks that want C++ without classes. > > https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu "The last meeting was pretty jam-packed, and a lot of things made it through at the 11th hour. We also lost quite a few good papers and features too, so they’ll have to be reintroduced next cycle, which might take us a whole extra 10 years to do." Ouch. Matheus.

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.

Forums