News for hackers. Stuff that matters.

A comment on The trouble with struct sockaddr's fake flexible array. Parent comment

Re:The trouble with struct sockaddr's fake flexible array by AshamedCaptain on Friday November 29, 2024 @09:14AM (#42274007)
No, I have seen many people use an arbitrary value to indicate "this is the amount it makes most sense to allocate this structure with", e.g. when you allocate it on the stack. If you need more than that you allocate it with a malloc wrapper or the like, which returns one of arbitrary long size.

What I have not seen is this happening in the middle of the struct, for obvious reasons; it's always the last element in the struct.

[ Parent | on HN ]
Re:The trouble with struct sockaddr's fake flexible array by dataflow on Friday November 29, 2024 @10:12AM (#42274394)
> No, I have seen many people use an arbitrary value

Have you seen that in something that's ABI-critical, though? i.e. whose code simply cannot be changed due to backward compatibility, like is the case with sockaddr? Because otherwise I'd consider it a non-issue.

[ Parent | on HN ]
Re:The trouble with struct sockaddr's fake flexible array by AshamedCaptain on Friday November 29, 2024 @10:33AM (#42274519)
Everything is an ABI issue. Dunno what the point or alternative is here.
[ Parent | on HN ]
Re:The trouble with struct sockaddr's fake flexible array by dataflow on Friday November 29, 2024 @10:35AM (#42274529)
No? Not every struct is exposed to clients who can't change their code.
[ Parent | on HN ]
Re:The trouble with struct sockaddr's fake flexible array by AshamedCaptain on Friday November 29, 2024 @01:19PM (#42275818)
I still do not see the point. No one wants to change their code. No one wants to break their ABI. But the discussion is moot since I do not see what ABI break is being proposed here. My only guess is that the proposal you're envisioning is to forbid this pattern, which breaks a lot of perfectly working code, not just 'ABI'.
[ Parent | on HN ]