5 ms·

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

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.

db48x 2y ago
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.
dzaima 2y ago
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.
olliej 2y ago
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]

db48x 2y ago

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.

dzaima 2y ago

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.

olliej 2y ago

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]