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).
Modernizing C arrays for greater memory safety: a case study in the Linux kernel
101–110 of 126 posts
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#102TL;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.
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
#103Earlier 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.
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 ?
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#105Earlier 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…
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#106Earlier 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.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#107Good 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.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#108Does anyone know where I can follow these discussions?
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#109Earlier 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.
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…