Does anyone know what is the status of their refactoring effort to update all the flexible array declarations in the kernel? How far along are they?
Modernizing C arrays for greater memory safety: a case study in the Linux kernel
11–20 of 126 posts
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#12Earlier quoted context omitted.
both c and c++ have the concept of zero-length arrays, if you malloc them - int * a = malloc(0); is ok
Hang on, let me think this through... If malloc(0) gets called as first malloc in the program the system break does not need to be moved, as there is always 0 bytes space available... but malloc does like to move sysbreak by a large amount at a time to reduce the need for repeated calls... I'm guessing malloc(0) does not move sysbreak and simply returns a pointer to the bottom of the heap?
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
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#13TL;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)));
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#14> Is it actually a 4 element array, or is it sized by the bytes member? i give up, what does sizeof say? and why would it be sized by bytes?
The previous paragraph says
> ...due to yet more historical situations (e.g. struct sockaddr, which has a fixed-size trailing array that is not supposed to actually be treated as fixed-size), GCC and Clang actually treat all trailing arrays as flexible arrays.
But I don't know, that doesn't seem to match the result I am getting with clang 13.1.6. It does seem to respect the array size declared in the struct, not treat it as a flexible array. I get -Warray-bounds warnings if I try to access anything past o->variable[3]. Maybe I'm misunderstanding what they're saying or my example is screwed up.
Edit: Actually, I guess it does end up treating it like a flexible array -- it produces -Warray-bounds warnings when compiling, but the resulting binary works (and doesn't trigger asan). Not sure I entirely understand it though.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#15Earlier quoted context omitted.
I think the parent is talking about the c pattern of having the last member of a struct be a zero length array, which is actually a dynamically sized array that the struct is only the header to (ostensibly with another field of the struct specifying the length of the array). It's fallen a bit out of favor, but it is a handy way to commingle the header and array with one allocation/pointer. And interestingly COBOL han…
According to the C spec, zero length arrays are explicitly illegal. > Zero-length array declarations are not allowed, even though some compilers offer them as extensions (typically as a pre-C99 implementation of flexible array members). However, as they say, gcc (and therefore clang) have an extension that allows it. So does MSVC but it works slightly differently.
you should be specific about which C spec you are referring to, you talk about "the C spec" and then you mention the "pre-C99 implementation". Maybe you mean they've always been illegal in every version, but it would be more clear.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#16Call me crazy, but zero length arrays are a great abstraction, when you working with implicit data-structures. Not safe, but elegant and performant. Many codebases could be 2x faster if their designers embraced that concept.
both c and c++ have the concept of zero-length arrays, if you malloc them - int * a = malloc(0); is ok
Then you have two allocations instead of one and related data is now likely to be farther away, possibly even in a different page.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#17TL;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.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#18Good 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...
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#19Earlier quoted context omitted.
According to the C spec, zero length arrays are explicitly illegal. > Zero-length array declarations are not allowed, even though some compilers offer them as extensions (typically as a pre-C99 implementation of flexible array members). However, as they say, gcc (and therefore clang) have an extension that allows it. So does MSVC but it works slightly differently.
you should be specific about which C spec you are referring to, you talk about "the C spec" and then you mention the "pre-C99 implementation". Maybe you mean they've always been illegal in every version, but it would be more clear.
[deleted]
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#20Call me crazy, but zero length arrays are a great abstraction, when you working with implicit data-structures. Not safe, but elegant and performant. Many codebases could be 2x faster if their designers embraced that concept.
both c and c++ have the concept of zero-length arrays, if you malloc them - int * a = malloc(0); is ok
malloc() doesn't allocate arrays. It allocates blocks of memory. Hence sizeof doesn't work the same for malloc() objects as it does on arrays.