Hacker News Reader

Comment by moralestapia | Hacker News Reader

>Maybe in another 60 it will get proper strings and arrays.

If you think this is missing, there's a big chance you don't "get" C.

Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.

View on HN

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues.

Of course, you can emulate these yourself, it's just a struct but not everyone does.

Adding opaque builtin struct types to C would be kind of a big deal though and would probably creep into other parts of the language and interact with them in unexpected ways. Features like fat pointers, slices, builtin dynamic arrays/strings or tagged unions would all require builtin opaque structs. This would be a whole different language (closer to Zig).

It really wouldn't be that hard to do. The syntax would be trivial, and the whole point is that you want it to creep so people actually use them.

There's no overhead to doing it, but you save a bunch of bugs earlier, all for stopping conflating arrays with pointers, which is something not much code does these days anyway

C99 introduced variable-length array parameters and variable-length array pointers together with variable-length arrays (VLA). These take another parameter or variable as a length-parameter. These became optional in C11 together with VLAs (for some reason) but are supposed to again become mandatory in C23. However (yet, for some reason) the pointers can (in the latest published draft, still) only be inside procedures: not in structs or in global variables.

I think it would not be impossible for a C compiler to detect and produce a warning if an index used with such an array-pointer is not checked against the array-pointer's length variable.

This would not make bounds-checks automatic, but the use of these types could make compilers point out when bounds are not checked or checked incorrectly.

People don't really get the distinction you make here, which is a shame. Often any VLA's are outlawed which is tossing the baby out with the bathwater.

Compilers can already do this:

https://godbolt.org/z/jMMa8n48r

Yes, putting them into structs is a missing feature. It is not in the draft because no compiler can do it and their is no implementation experience. I am working on it.

I surely get C, having to deal with its casualties in DevSecOps.

I have been "getting" C since 1992, across Xenix, DG/UX, HP-UX, Solaris, AIX, FreeBSD, Linux, Amiga, Windows 3.x,.....

Well, then, you must know it's not really a big deal to write code with proper memory checks.

If you think that, then you really don't get C - not as in "it's intents", but as in its actual history and repurcursions...

I have found yet another C expert.

https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...

It's a big deal, you need about 1/3 of sel4 proofs

You once claimed C requires UNIX like OS to run.

And he was right. He didn't mean it as a statement of fact (which would be wrong, and he already knew it).

No he was definitely wrong. Ask any C developer.

His comment: https://news.ycombinator.com/item?id=20828974

When I complain C's portability sucks, because it can't do anything useful without a ton of ifdefs, people tell me it's not a problem, I should just use POSIX.

https://twitter.com/rygorous/status/1224413742667988992

I claim it yet again on this very comment.

Without UNIX spreading with its free beer into universities, C would have been a footnote on the history of system programming languages.

Nope in the above comment you claim something else.

Here is where you claim C requires UNIX like OS:

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

Let me tell you, in embedded development we run C on bare metal or under RTOS. There is no UNIX in sight. And the code is portable to many CPU architectures.

A snowflake RTOS without POSIX, call me amazed.

I'm happy you learned something.

Not really, still waiting for the name of such marvelous OS.

Keil RTOS. You can also use C on bare metal without an OS. I hope you won't claim next that CPU's are UNIX like OSs.

Much more importantly, without UNIX and free beer TCP/IP there's a fair chance the Internet isn't the Network and none of this (gestures at HN and the Web) happens. That's a much bigger impact than C which is just a programming language, even if you count the influence of NUL-terminated strings, and all the semi-colon languages (including even Javascript and Rust, which are very different from C but preserve the enthusiasm for semi-colons) the Internet as Network makes more difference.

In particular it's possible X.25 could have won. JANET (the tertiary education network in the United Kingdom) was exclusively doing X.25 until 1991, when it tries an experiment offering IP. Unsurprisingly free beer TCP/IP offers a cornucopia of interesting new toys and sites are very enthusiastic about JIPS (the experimental IP service) so that by 1992 the IP service is no longer an experiment but the primary service, with X.25 maintained only until 1997.

You do get the Network anyway of course, that's what everything is leading up to after Shannon, but you probably get an X.25 flavoured Network instead of the Internet, or some other system coming from another direction, and broad deployment might have been delayed into the early 21st century rather than the 1990s depending on exactly how things work out. Stallman's GNU project doesn't happen, Tim's toy hypermedia system either doesn't exist or is a small inconsequential experiment largely unknown outside hypermedia fanatics, and Linus Torvalds probably doesn't make an operating system kernel for his 386 microcomputer. It's a very different environment, C is small potatoes by comparison.

So? I could deal with such alternative universe, after all, between 1986 and 1994, I managed to work with computers and networking just fine.

Reply on news.ycombinator.com