Modernizing C arrays for greater memory safety: a case study in the Linux kernel
1–10 of 126 posts
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#2Call 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.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#3> 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?
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#4Call 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
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#5Call 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
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 handled this in a cleaner way. I forget some of the specfics but there was a way to specify to the compiler that one field of a record specified the length of the following array, allowing the same pattern in a type safe way.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#6Call 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
Kind of:
> If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object
So it may actually allocate (although the allocation is unusable).
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#7Earlier quoted context omitted.
both c and c++ have the concept of zero-length arrays, if you malloc them - int * a = malloc(0); is ok
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.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#8Call 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
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?
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#9Earlier quoted context omitted.
both c and c++ have the concept of zero-length arrays, if you malloc them - int * a = malloc(0); is ok
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 article, it's better to use the new flexible array syntax (int arr[]) instead of the old zero-length syntax (int arr[0]), because that allows the compiler emit better warning messages.
Re: Modernizing C arrays for greater memory safety: a case study in the Linux kernel
#10Earlier 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?
Implementation defined. I've heard of returning null (under the case that your free() implementation allows nulls to be passed in) or returning a pointer to a zero length object on the heap like you're suggesting. Really just about the only requirement is that the pointer can subsequently be given to free() since dereferencing the pointer is UB.