www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Obvious Things C Should Do

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/item?id=42669637
Jan 11
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
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?
Jan 11
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2025 4:57 PM, monkyyy wrote:

 Why do you still follow c's (basicly nonexistent) development after 3 decades
of 
 shipping your own compiler?


It inspires a lot of discussion about D.
Jan 11
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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.
Jan 12
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
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
Jan 12
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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
Jan 12
parent reply matheus <matheus gmail.com> writes:
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.
Jan 13
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2025 9:26 AM, matheus wrote:

 "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."


"wide pointers (a native pointer + size construct)"

!!!
Jan 13
prev sibling parent reply Zz <zz zz.com> writes:
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
Jan 13
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 13 January 2025 at 17:00:39 UTC, Zz 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:

 [...]


 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


Interesting, thanks for sharing.
Jan 13
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2025 9:00 AM, Zz wrote:

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3423.pdf


With all the features listed below, they'd be better off using D:

 TrapC is a C language extension that improves code safety

 TrapC memory management is automatic, cannot memory leak, with pointers 
lifetime managed not garbage collected"

 TrapC pointers may look the same as in C/C++, but all pointers are
diligently 
compiler managed and memory safe

 TrapC pointers have Run-Time Type Information (RTTI), with typeof(),
nameof() and
other details accessible

 TrapC reuses a few code safety features from C++, notably member functions,
constructors, destructors and ‘new’

 TrapC adds 2 keywords unique to TrapC: ‘trap’ (error handling) and
‘alias’ 
(operator,
function and data overloading)

 TrapC removes 2 keywords: ‘goto’ and ‘union’, as unsafe and having
been widely
deprecated from use

 TrapC uses castplates to make C containers typesafe, without the complexity
of C++
templates

 TrapC printf() and scanf() are typesafe, overloadable, and have JSON and 
localization
support built in

 TrapC has an integer-based ‘decimal’ fixed-point data type suitable for
use in 
financial
transactions

 TrapC is one-way ABI compatible with C, such that TrapC functions may call
any C
function as-is

 Passing a raw C pointer safely to a TrapC function requires extra steps, 
because TrapC
pointers have hidden RTTI

 TrapC has API-compatible versions of C POSIX and C++ STL standard
libraries, 
to not
return raw pointers

 TrapC doesn’t do more than C for thread safety to prevent race
conditions, but 
may in the
future
Jan 13
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2025 3:31 PM, Walter Bright wrote:

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


Now the top story!

https://news.ycombinator.com/news
Jan 11
prev sibling next sibling parent reply Johan <j j.nl> writes:
On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote:

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


Typo in section "Importing Declarations": `floo.d` should be 
`floo.c`
Jan 12
parent Walter Bright <newshound2 digitalmars.com> writes:
Thanks. Fixed.
Jan 13
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
On Saturday, 11 January 2025 at 23:31:14 UTC, Walter Bright wrote:

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


I can't access this URL, can someone share the URL (If it is 
pointing to) or copy 'n paste the content here please?

Matheus.
Jan 12
parent reply Derek Fawcus <dfawcus+dlang employees.org> writes:
On Sunday, 12 January 2025 at 11:33:23 UTC, matheus wrote:

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

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


 I can't access this URL, can someone share the URL (If it is 
 pointing to) or copy 'n paste the content here please?

 Matheus.


https://www.digitalmars.com/articles/Cobvious.html
Jan 12
parent reply matheus <matheus gmail.com> writes:
On Sunday, 12 January 2025 at 12:18:30 UTC, Derek Fawcus wrote:

 On Sunday, 12 January 2025 at 11:33:23 UTC, matheus wrote:

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

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


 I can't access this URL, can someone share the URL (If it is 
 pointing to) or copy 'n paste the content here please?

 Matheus.


 https://www.digitalmars.com/articles/Cobvious.html


Thank you.

Matheus.
Jan 12
parent reply matheus <matheus gmail.com> writes:
On Sunday, 12 January 2025 at 12:56:07 UTC, matheus wrote:

 On Sunday, 12 January 2025 at 12:18:30 UTC, Derek Fawcus wrote:

 On Sunday, 12 January 2025 at 11:33:23 UTC, matheus wrote:

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

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


 I can't access this URL, can someone share the URL (If it is 
 pointing to) or copy 'n paste the content here please?

 Matheus.


 https://www.digitalmars.com/articles/Cobvious.html


 Thank you.

 Matheus.


I read the article thanks to Derek Fawcus' URL.

The features presented are nice, but since they are only 
supported by ImportC (Which again is nice), but if the Standard 
don't adopt any of these it will be barely used out there right?

Matheus.
Jan 12
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/12/2025 5:16 AM, matheus wrote:

 but if the Standard don't adopt any of these it will be 
 barely used out there right?


Right. Which is why I started D in the first place.
Jan 13
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
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.

```C
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.
Jan 12
parent reply Walter Bright <newshound2 digitalmars.com> writes:
D's CTFE does not allow undefined behavior.
Jan 13
next sibling parent reply Dukc <ajieskola gmail.com> writes:
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.

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.
Jan 13
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 13
parent reply Dukc <ajieskola gmail.com> writes:
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.
Jan 29
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 29 January 2025 at 09:57:27 UTC, Dukc wrote:

 On Monday, 13 January 2025 at 17:53:36 UTC, Walter Bright wrote:

 On 1/13/2025 8:13 AM, Dukc wrote:

 [...]


 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.



 [...]


 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.


Actually they are in process of removing a few UB traps,

https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm

See "Slay Some Earthly Demons" proposals.
Jan 29
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 13 January 2025 at 16:13:10 UTC, 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.


That’s simply wrong. ` safe` code can call ` trusted` code and 
that can execute undefined behavior if it has a bug.
Jan 23
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 23 January 2025 at 16:20:21 UTC, Quirin Schroll 
wrote:

 On Monday, 13 January 2025 at 16:13:10 UTC, Dukc 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.


 That’s simply wrong. ` safe` code can call ` trusted` code and 
 that can execute undefined behavior if it has a bug.


Yes, if we're precise about it.

It doesn't contradict what I meant though. Since D has ` safe`, 
things like overflows, uninitialised variables, underflows, 
attempting to modify a string literal etc. have to be defined 
behaviour. The C standard mostly handles these by saying 
"Undefined behaviour. Just don't do it." but the D spec can't, 
otherwise ` safe` wouldn't do what it's supposed to, CTFE or no.

Because of that, the D spec doesn't require a lot of paper to 
accomodate for CTFE, but it would require a big overhaul of the C 
spec unless it can allow compile-time undefined behaviour somehow.
Jan 28
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 28 January 2025 at 12:38:25 UTC, Dukc wrote:

 On Thursday, 23 January 2025 at 16:20:21 UTC, Quirin Schroll 
 wrote:

 On Monday, 13 January 2025 at 16:13:10 UTC, Dukc 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.


 That’s simply wrong. ` safe` code can call ` trusted` code and 
 that can execute undefined behavior if it has a bug.


 Yes, if we're precise about it.

 It doesn't contradict what I meant though. Since D has ` safe`, 
 things like overflows, uninitialised variables, underflows, 
 attempting to modify a string literal etc. have to be defined 
 behaviour. The C standard mostly handles these by saying 
 "Undefined behaviour. Just don't do it." but the D spec can't, 
 otherwise ` safe` wouldn't do what it's supposed to, CTFE or no.

 Because of that, the D spec doesn't require a lot of paper to 
 accomodate for CTFE, but it would require a big overhaul of the 
 C spec unless it can allow compile-time undefined behaviour 
 somehow.


What is CTFE-able in D is pretty vague and includes UB. C++, from 
C++11 onward, went through all hurdles defining what `constexpr` 
included and what it doesn’t, making sure to absolutely catch any 
UB. That means two things:
- Ideally, `constexpr` is consistent over all compilers, and for 
the most part, it actually is.
- Things that obviously could be `constexpr` sometimes aren’t 
(e.g. `std::bitset` has `constexpr` support since C++23, but I 
see no reason why it can’t have it in C++11, except the 
`to_string` function).

D’s approach to CTFE is maximal pragmatism. If control-flow 
reaches a statement that cannot be executed at CTFE (for possibly 
many reasons among which are UB and a call to an `extern` 
function) it errors. There’s no attempt to specify what is and 
isn’t included. And it’s not even enforced in all cases.

The simplest form of UB is violating `const`; it’s easily 
observed when it happens. Let’s see for C++:
```cpp
constexpr int& f(const int& x)
{
     // UB if `x` is actually `const`
     // OK if `x` is actually mutable
     return const_cast<int&>(x) = 0;
}

constexpr int g(bool ub)
{
     const int x = 10;
     int y = 10;
     return ub ? f(x) : f(y);
}

static_assert(g(0) == 0); // passes
static_assert(g(1) == 0); // error, executes UB
```

Now D:
```d
ref int f(const ref int x) => cast()x = 0;

int g(bool ub)
{
     immutable int x = 10;
     int y = 10;
     return ub ? f(x) : f(y);
}

int h(bool ub)
{
     immutable int x = 10;
     int y = 10;
     if (ub)
     {
         f(x);
         return x;
     }
     else
     {
         f(y);
         return y;
     }
}

static assert(g(0) == 0); // passes, executes UB
static assert(g(1) == 0); // passes, executes UB

static assert(h(0) == 0); // passes, executes UB
static assert(h(1) == 0); // fails (h(1) == 10), executes UB
```
The issue here is, another compiler might give you `0` or `10` 
for any of these. Modifying `const` objects is not implementation 
defined, which would be the only way to justify it.

---

Ideally, CTFE-ing a function tests that the taken control-flow 
path is UB-free. In C++, one can do that. In D, it seems, one 
cannot rely on that. If we could, ` trusted` would be a lot 
better, actually, as one could compile-time test at least some 
` trusted` functions.
Feb 04
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Please file a bug report on this behavior. Casting away const shouldn't be 
allowed in CTFE.
Feb 04
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 4 February 2025 at 19:02:48 UTC, Walter Bright wrote:

 Please file a bug report on this behavior. Casting away const 
 shouldn't be allowed in CTFE.


Filed as https://github.com/dlang/dmd/issues/20827
Feb 05
parent Walter Bright <newshound2 digitalmars.com> writes:
Thanks!
Feb 06
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 13 January 2025 at 08:16:48 UTC, Walter Bright wrote:

 D's CTFE does not allow undefined behavior.


No language that I’ve seen allows executing undefined behavior at 
CTFE. (This does not include optimizations, which are never 
required by the language.) In fact, if a function can be executed 
at CTFE, it’s a great way to test for accidental UB.
Jan 23