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
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
parent 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