Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

people.kernel.org

Post reply on HN
Print view View original

121–126 of 126 posts

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

#121

Post by planede »

WalterBright wrote: post #116
planede wrote: post #94

Earlier quoted context omitted.

The problem is that this would have one specific ABI, which probably wouldn't match many existing structs with a flexible array member at the end. Could potentially be used for new code (while requiring every user to upgrade the standard they compile with), but has the risk of not usable for modernizing old code.

You're right that bounds checked arrays do nothing at all for existing code. But they can be added incrementally to an existing code base, as a normal part of working on the code. In that aspect it's like when prototypes were added to C. Nothing changed for existing code, but prototypes are so advantageous people would retrofit existing code incrementally when doing routine maintenance.

I presume prototypes could be added to transform much of existing code without compatibility problems (ABI nor API), which is a clear advantage compared to checked arrays. Checked arrays might worth it regardless, but it's not applicable in most of the article's use cases.

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

#122

Post by WalterBright »

planede wrote: post #121
WalterBright wrote: post #116

Earlier quoted context omitted.

You're right that bounds checked arrays do nothing at all for existing code. But they can be added incrementally to an existing code base, as a normal part of working on the code. In that aspect it's like when prototypes were added to C. Nothing changed for existing code, but prototypes are so advantageous people would retrofit existing code incrementally when doing routine maintenance.

I presume prototypes could be added to transform much of existing code without compatibility problems (ABI nor API), which is a clear advantage compared to checked arrays. Checked arrays might worth it regardless, but it's not applicable in most of the article's use cases.

> Checked arrays might worth it regardless

I can attest that they are.

> it's not applicable in most of the article's use cases

I don't believe that.

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

#123

Post by [deleted] »

WalterBright wrote: post #76
downvotetruth wrote: post #71

Earlier quoted context omitted.

Starting with "That's nice" is extremely flippant and is an immediate turn off to any subsequent statement. A stronger opening to discredit the [..] proposal would be to take the closing quote "We've been doing that with D for over 20 years" and point out that storing the length of an array of a certain type is a specialization to arrays of dependent typing that has been around since Howard and de Bruijn extended lam…

I didn't say D invented it, so no need to discredit it. I said D has been using it for 20 years and proves it works famously with C style pointers and arrays.

[deleted]

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

#124

Post by downvotetruth »

WalterBright wrote: post #76
downvotetruth wrote: post #71

Earlier quoted context omitted.

Starting with "That's nice" is extremely flippant and is an immediate turn off to any subsequent statement. A stronger opening to discredit the [..] proposal would be to take the closing quote "We've been doing that with D for over 20 years" and point out that storing the length of an array of a certain type is a specialization to arrays of dependent typing that has been around since Howard and de Bruijn extended lam…

I didn't say D invented it, so no need to discredit it. I said D has been using it for 20 years and proves it works famously with C style pointers and arrays.

And no claim was made about what D invented. Continuous use does not prevent door latch bushings from disintegrating; How long some thing has been used for is not proof that the replacement will work.

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

#125

Post by downvotetruth »

ImprobableTruth wrote: post #90
downvotetruth wrote: post #71

Earlier quoted context omitted.

Starting with "That's nice" is extremely flippant and is an immediate turn off to any subsequent statement. A stronger opening to discredit the [..] proposal would be to take the closing quote "We've been doing that with D for over 20 years" and point out that storing the length of an array of a certain type is a specialization to arrays of dependent typing that has been around since Howard and de Bruijn extended lam…

Fat pointers are a purely value level construct. STLC alone covers that. Non-determinism isn't really related to the lambda cube, even CoC is deterministic.

A pointer type is understood "to point" at a memory address with no restriction on being stack allocated. CoC is ambiguous as many different versions of the theory of constructions have been formulated that are not all equivalent and not necessarily bounded & deterministic.

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

#126

Post by uecker »

WalterBright wrote: post #120
uecker wrote: post #117

Earlier quoted context omitted.

We have bounds-checkable arrays already since C99: int ( p)[n] = malloc(sizeof p); (*p)[i] = 1; // run-time bounds check https://godbolt.org/z/vb8dqx1od But yes, having a type that included the bound makes sense. But I do not think using array syntax for pointers as in your proposal makes any sense. Dennis Ritchie got it right: https://www.bell-labs.com/usr/dmr/www/vararray.pdf Ritchie DM. Variable-size arrays in C.…

> We have bounds-checkable arrays already since C99 void foo(int n, int (*p)[n]) { (*p)[n] = 1; } which has failed to catch on, because it still stores the pointer and the length as two separately handled objects. > Dennis Ritchie got it right "This paper proposes to extend C by allowing pointers to adjustable arrays and arranging that the pointers contain the array bounds necessary to do subscript calculations and c…

It is unclear why it has failed to catch on. One reason probably was that Microsoft decided at one point that it will not support C99 because everything should program in C++ which put a damper on the adoption of newer C features. The other reason is that compilers did not actually supported bounds checking here (I added it in GCC for UBSan in 2015) and it is still possible to lose the bound at function calls (I have patch to GCC I hope I can submit for the next version). So for a long time most people thought that VM-types were useful only for numerics.

Having said this, I fully agree with you that having a wide pointer that combines length and pointer would be a useful feature. I just think that the syntax proposed by Dennis Ritchie fits naturally into C.

Post reply on HN