How to use the new counted_by attribute in C (and Linux) | Hacker News Reader

How to use the new counted_by attribute in C (and Linux)

people.kernel.org

61 pointsthunderbong9 comments

This is cool, definitely new to me. I do wonder if this just moves the problem though. As the article explains:

> One crucial requirement is that the counter must be initialized before the first reference to the flexible-array member. Another requirement is that the array must always contain at least as many elements as indicated by the counter.

This means as the array is initialized and updated, you must keep the counter updated with it. Its just as easy to screw that up than it is to screw up the general problem of accessing elements that are out-of-bounds

It’s just as easy to make that mistake, but at least then the compiler can issue a warning.

It's better than that. If you use FORTIFY_SOURCE then you will get _runtime_ bounds checking.

So, while you still have to make sure your structure is sane, now the runtime can play along too.

True, but compile time warnings beat runtime checks every time. Well, as long as people turn the warnings into errors so that they cannot just be ignored.

Worth noting the analog in MSVC is SAL annotations [1].

[1] https://learn.microsoft.com/en-us/cpp/code-quality/annotatin...

If my understanding of the article right, the counter needs to be updated by the business logic every time the underlying array is updated. This doesn't seem to solve any problems. Indeed, it's just synctatic sugar to wrap up what many developers have been doing for decades anyway. And it doesn't reduce the chances of mistakes in getting the counter and the array out of sync either.

It is just “syntactic sugar” but the idea is that it gives the compiler enough information to generate proper warnings if you do it wrong.

With a flexible array member, updating the length in-place is rather infrequent, at least in certain use cases (given that to expand it you might have to reallocate the entire struct, including the count field).

What it helps with is fortified builds, as now the compiler/libc can now get an upper bound on the intended size, whereas before it's had to just assume flexible array members are infinitely-long and thus is largely never able to add bounds checking.

You’re missing the issue being resolved. This does not impact anything in code that has no errors, because that’s not the point.

The goal of annotations like this is to 1: make it harder to make the mistakes in the first place (by making it possible for the compiler to detect failures to update, etc) and 2: make it possible for the compiler to actually prevent errors even at runtime.

Again the issue is not what happens when everything is perfect, it’s what happens when everything is not.

[edit: I don’t even think you can reasonably call this syntactic sugar as it does not do any of the actual work of updating things for you, it’s literally just telling the compiler what the semantics of the object is, you still have to do everything yourself with the only exception being guaranteed bounds checks which looks to be a compiler mode dependent behavior]

Reply on news.ycombinator.com