Live data from Hacker News

Modernizing C arrays for greater memory safety: a case study in the Linux kernel

people.kernel.org

101–110 of 126 posts

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#101
post #50
post #40

Earlier quoted context omitted.

Sibling already pointed out this article is not talking about VLAs, but I do like your flexible-array attribute extension proposal.

The proposal is almost exactly the same as the one in the article (near the end).

Yes, it is IMO the second most important part of the article, it seems like a good idea and it would be nice to see it in the standard.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#102
post #13

TL;DR is the introduction of C99 VLAs, not Pascal-style arrays, though a potential attribute could be added so we could do int some_int; int some_array[] __attribute__((__element_count__(some_int))); to store the size of some_array in some_int .

This has nothing to do with VLAs. The article covers FAMs at the end of structs.

I must have misunderstood, thank you for the clarification. I thought that having no size specifier in the array declaration turned it into a VLA, which could have repercussions when embedding structs, e.g.:

  struct
  {
    int a;
    /* ... */
    int b[];
  } foo;

  struct
  {
    struct foo;
    /* ... */
    int c;
  } bar;
I would expect to have issues when trying to access the other members of struct bar like c.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#103
post #38
post #12

Earlier quoted context omitted.

malloc is a user level library function - c/c++ implementers can do what they like with it assume the downvote was from someone that malloc is a system call

I downvoted for the assumption that sbrk is involved in any way. It's an implementation detail of (some) historical malloc implementations, not some inherent aspect of all implementations. The entire thought experiment is faulty.

Right, malloc uses mmap instead of sbrk, I'm an idiot. I really ought to read up on up-to-date implementation practices.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#104

> int flex[] __attribute__((__element_count__(items))); While what the article describes is clever, it is needlessly complex, and filled with various compiler switches and extensions. In contrast, here's a stupid simple approach: https://www.digitalmars.com/articles/C-biggest-mistake.html where bounds-checkable arrays are declared as: int a[..]; `a` consists of two fields, a `length` and a `pointer`. Indexing it mean…

I had always assumed it was because of backwards compat that the proposal was never accepted but since it turns out that is not the issue, do you have any idea why the proposal was never accepted ?

Objective-C and C++ never had any issues having additionaly types for arrays and strings, C could do the same, but WG14 has clearly decided they don't want to do that.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#105
post #87

Earlier quoted context omitted.

Unrelated to the article but since you seem to know this stuff, do you know what happens when a function in an “extern C” block exposes C++ types (parameters or return types)? I assume it’s broken because it’d expect the actual C++ types to be passed in despite the lack of ABI stability, and only the linking / name mangling is affected (possibly calling conventions as well?) but I’m not actually sure.

C++ types are structs and unions if you get down to the bottom of things. This is possibly not guaranteed by the standard, but AFAIK, extern "C" doesn’t ever affect the calling convention or memory layout for the parameters, only the name mangling for the linker. So in theory, if you manage to construct a valid std::string in C code (which is hard, given its invariants, and would be absolutely nonportable), then you…

You could that with a function that would map a ptr/len pair into a std::span.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#106
post #104

Earlier quoted context omitted.

I had always assumed it was because of backwards compat that the proposal was never accepted but since it turns out that is not the issue, do you have any idea why the proposal was never accepted ?

Objective-C and C++ never had any issues having additionaly types for arrays and strings, C could do the same, but WG14 has clearly decided they don't want to do that.

Yes, so why WG14 or whoever in charge has not accepted that one simple addition responsible for so many errors ? It's not like it would affect performance. For strings, it would even make it better, simply moving the lenght around with the compiler's help.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#107
post #18

Good article. If you're compiling C with MSVC then you can use SAL annotations [1] which serve the same purpose. [1] https://learn.microsoft.com/en-us/cpp/code-quality/annotatin...

Wow, such a great annotation language. Wish it were in GCC as well.

I keep hoping that the C and C++ committees will get together and standardize some of that in the form of C23/C++11 style attributes. But that is sadly likely a naïve hope.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#109
post #104

Earlier quoted context omitted.

Objective-C and C++ never had any issues having additionaly types for arrays and strings, C could do the same, but WG14 has clearly decided they don't want to do that.

Yes, so why WG14 or whoever in charge has not accepted that one simple addition responsible for so many errors ? It's not like it would affect performance. For strings, it would even make it better, simply moving the lenght around with the compiler's help.

Most likely as they have proven during the last 40 years, security is not in their agenda.

Even the Annex K design was misguided, as it expected parameters to still be separate pointer + length arguments, thus hardly changing anything regarding getting them wrong.

Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel

#110

> int flex[] __attribute__((__element_count__(items))); While what the article describes is clever, it is needlessly complex, and filled with various compiler switches and extensions. In contrast, here's a stupid simple approach: https://www.digitalmars.com/articles/C-biggest-mistake.html where bounds-checkable arrays are declared as: int a[..]; `a` consists of two fields, a `length` and a `pointer`. Indexing it mean…

You aren't going to get a lot of love from C programmers by casting malloc() result...
Post reply on HN