The Problem with C (2020) • Hacker News Board

Re: The Problem with C (2020)

#71

Post by pjmlp » Tue, Feb 01, 2022, 11:19 AM UTC

tialaramex wrote: post #67

pjmlp wrote: post #58

Earlier quoted context omitted.

C did it already in 1979, yet people keep ignoring it. > Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find inter…

We've been here before with other aspects of human behaviour. If you really don't want people to do it, make it impossible and then they can't. You can't write an integer overflow in WUFFS because that doesn't compile. You can't use your Google.com WebAuthn credentials to sign into fakegoogle.example, even if you really, really want to, even if you're 100% sure this is a good idea, it can't be done. Any time you stop…

Agreed, the only way to enforce something is to make part of the type system, and that is how we land on C folks complaining about straightjacket programming languages.

Re: The Problem with C (2020)

#72

Post by pjmlp » Tue, Feb 01, 2022, 11:22 AM UTC

scoutt wrote: post #66

pjmlp wrote: post #60

Earlier quoted context omitted.

Have fun reading these ones instead of relying on Wikipedia, https://news.ycombinator.com/item?id=30160590 Also you forgot the endless amount of compiler specific language extensions.

Let's see what (and how it) lands in C2x. Of course, as any other language, C might be taken over in the future by a new generation and be bloated , too. But so far, it is contained. In any case, nobody can deny the amount of bloat in C++ has no parallel. > Naturally at this point one could ask why not just use C++ instead I might do, in a limited and simpler form, as I said before. Of course I am not developing some…

There is no denial about that, except most languages suffer from similar bloat.

When people count the amount of pages on ISO C++, they forget to include the standard library on the process.

Which on C's case it includes the expectation that POSIX is also available.

Re: The Problem with C (2020)

#73

Post by colonwqbang » Tue, Feb 01, 2022, 11:34 AM UTC

foldr wrote: post #33

colonwqbang wrote: post #22

Earlier quoted context omitted.

I hope they don't, at the very least we can afford to choose a new keyword. Even if auto was infrequently used, it's no good to silently change the meaning of existing valid programs.

Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So auto x = 7; is equivalent to auto int x = 7; which is equivalent to int x = 7; (since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following: auto str = "foo"; Such code…

A simple example would be

  auto pi = 3.14;
  double result = 2 * pi;
  printf("the circumference of the unit circle is %g\n", result);

When interpreted as C89 program, this computes the value 6. Compiled with a C++ compiler it computes 6.28. This is exactly due to that both languages have an auto keyword, but they mean different things.

This situation is perhaps not so likely to occur in real usage, but I think it could and should have been avoided.

Re: The Problem with C (2020)

#74

Post by throwawaylinux » Tue, Feb 01, 2022, 11:44 AM UTC

sirwhinesalot wrote: post #68

throwawaylinux wrote: post #59

Earlier quoted context omitted.

> That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language needs to do a copy to pass a string to C, even C++ (for string_view at least). I don't think that's what he's talking about. No matter what glue you had, you need to pass NUL terminated strings to C code that uses NUL terminated strings. The glue interface does not require any such thing though. > A lack…

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one.

> Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks.

The C interface glue is not the problem here. You can write the library with a completely different language and using fat pointers, and simply adjust the calling convention at the C interface, and it can be called by a different language that uses fat pointers and everything can use fat pointers.

The actual problem is you can't just say that your interface glue is going to have all these wonderful features and that therefore everything will magically work and use them.

> By necessity this involves using standard types available in C otherwise the other languages have nothing to go on, they'd just have a bunch of opaque types and no way to create them.

Using C interface glue does not require you to even write a line of C code let alone C types if your compiler knew how to call the APIs.

> If C had better builtin constructs, these "extern C" APIs could be much better semantically, such that automatically generating wrappers to this C API would result in safer, more efficient, and more ergonomic code in the host language.

Again there's no reason your language can not wrap those and expose your desired higher level semantics or features to your code on the other side of the wrapper layer.

Re: The Problem with C (2020)

#75

Post by foldr » Tue, Feb 01, 2022, 11:44 AM UTC

colonwqbang wrote: post #73

foldr wrote: post #33

Earlier quoted context omitted.

Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So auto x = 7; is equivalent to auto int x = 7; which is equivalent to int x = 7; (since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following: auto str = "foo"; Such code…

A simple example would be auto pi = 3.14; double result = 2 * pi; printf("the circumference of the unit circle is %g\n", result); When interpreted as C89 program, this computes the value 6. Compiled with a C++ compiler it computes 6.28. This is exactly due to that both languages have an auto keyword, but they mean different things. This situation is perhaps not so likely to occur in real usage, but I think it could a…

Ah good point. I was forgetting that implicit conversion from double to int is defined.

Re: The Problem with C (2020)

#76

Post by smorgusofborg » Tue, Feb 01, 2022, 11:53 AM UTC

sirwhinesalot wrote: post #68

throwawaylinux wrote: post #59

Earlier quoted context omitted.

> That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language needs to do a copy to pass a string to C, even C++ (for string_view at least). I don't think that's what he's talking about. No matter what glue you had, you need to pass NUL terminated strings to C code that uses NUL terminated strings. The glue interface does not require any such thing though. > A lack…

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one.

You are free to expose an API where strings are not null terminated, etc. Anyone in any language is going to have to work their data into the API you provide so if it is alternatively complicated to make an intermediary language happy that's not really helping.

Re: The Problem with C (2020)

#77

Post by badsectoracula » Tue, Feb 01, 2022, 12:07 PM UTC

pjmlp wrote: post #53

my123 wrote: post #26

Earlier quoted context omitted.

> C is the glue interface that connects all the different languages together. That's one of the issues in most UNIX systems. Windows sidestepped it with COM (and a much improved WinRT as a successor, with a .NET-y object model). On Apple systems, Obj-C is pretty much usable from other languages too, being the standard ABI to glue it all. My takeaway: bring one of those two options properly to Linux, which is needed h…

Yes, people mistake OS ABI with C, not understanding that is only a reality on pure C OSes. You forgot mainframes or even Android (C ABI without JNI is of not much help), or ChromeOS (WASM yeah). Linux has such an option, D-BUS, now adopting it at scale is another matter.

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).

Re: The Problem with C (2020)

#78

Post by sirwhinesalot » Tue, Feb 01, 2022, 12:11 PM UTC

smorgusofborg wrote: post #76

sirwhinesalot wrote: post #68

Earlier quoted context omitted.

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one. You are free to expose an API where strings are not null terminated, etc. Anyone in any language is going to have to work their data into the API you provide so if it is alternatively complicated to make an intermediary language happy that's not really helping.

You can, but then you cannot automatically generate a wrapper that can convert language B strings to language A strings disguised as an opaque type C, because there is no way for the wrapper generator to know it is a string type, unless you wrote the wrapper generator yourself for your API specifically.

Re: The Problem with C (2020)

#79

Post by pjmlp » Tue, Feb 01, 2022, 12:18 PM UTC

badsectoracula wrote: post #77

pjmlp wrote: post #53

Earlier quoted context omitted.

Yes, people mistake OS ABI with C, not understanding that is only a reality on pure C OSes. You forgot mainframes or even Android (C ABI without JNI is of not much help), or ChromeOS (WASM yeah). Linux has such an option, D-BUS, now adopting it at scale is another matter.

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).

It can run in-proc and fits the scenarios being given on previous comment.

I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of.

In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.

Re: The Problem with C (2020)

#80

Post by sirwhinesalot » Tue, Feb 01, 2022, 12:19 PM UTC

throwawaylinux wrote: post #74

sirwhinesalot wrote: post #68

Earlier quoted context omitted.

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one. > Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. The C interface glue is not the problem here. You can write the library with…

I'm sorry, maybe I'm not making myself clear and we're talking in circles. Yes the C interface is the problem.

Lets say I'm developing an API in Rust that I want everyone to be able to use. I wrap this API in some C functions. I use fat pointers (slices), strings with length, etc. all custom struct types. I choose to signal errors in some my_err* parameter.

Then someone developing in Java wants to use my library. If they use an automatic wrapper generator (which knows nothing of my API), all the semantic information on slices, strings and errors is lost. They need to make an additional wrapper on top of the stuff the automatic wrapper generator did.

If C had better builtin types, the slices exposed by the "extern C" API in Rust would just be standard C slices. The strings just standard C strings, the errors just standard C errors. The semantic information would be preserved at the C level, and therefore the automatic wrapper generator could add code to automatically translate slices, strings and errors into the appropriate types in the host language.

You seem entirely focused on the fact that the C ABI can be used to implement stuff like COM or SWIG for language interoperability. True, but not really relevant.