6 ms·

Here's what I don't understand: > As long as this usage remains, the checking tools built into both compilers must treat any trailing array in a structure as i

Here's what I don't understand: > As long as this usage remains, the checking tools built into both compilers must treat any trailing array in a structure as if it were flexible; that can disable overflow checking on that array entirely. No, they don't? Why couldn't they just have a mechanism to suppress the check for this particular struct (like a whitelist)?

oersted 2y ago
Yeah it's interesting that a (relatively) small quirk in the Linux source has the "political leverage" to impact the whole C ecosystem. I suppose C was made for Unix at Bell Labs and GCC is also inextricably tied, you could say that C is first and foremost the language of Linux, fair enough.
- nine_k 2y ago
  I suspect that the problem is a problem in many code bases, but only a hugely important project like Linux has the leverage to try and have it addressed at the ecosystem level.
AshamedCaptain 2y ago
I'd think this is an extremely common pattern anyway (with the declared array length been 1, or even some other "minimal storage value"), and likely struct sockaddr's use of it is the cherry on the top.
- dataflow 2y ago
  The only embedded sizes I've ever seen are flex, 0, 1, and 14 (sockaddr's). It's trivial enough to exclude all of them.
  - AshamedCaptain 2y ago
    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.
    - dataflow 2y ago
      > 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.
      - AshamedCaptain 2y ago
        Everything is an ABI issue. Dunno what the point or alternative is here.
        dataflow 2y ago
        No? Not every struct is exposed to clients who can't change their code.
        AshamedCaptain 2y ago
        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'.
  - garaetjjte 2y ago
    >flex, 0, 1 And each one can behave differently: https://lwn.net/Articles/908817/ https://lwn.net/Articles/908817/
- poincaredisk 2y ago
  It is in C, but not in the Linux kernel (according to TFA). That's why they're planning a big refactoring to get rid of this structure from the kernel

oersted 2y ago

Yeah it's interesting that a (relatively) small quirk in the Linux source has the "political leverage" to impact the whole C ecosystem. I suppose C was made for Unix at Bell Labs and GCC is also inextricably tied, you could say that C is first and foremost the language of Linux, fair enough.

nine_k 2y ago
I suspect that the problem is a problem in many code bases, but only a hugely important project like Linux has the leverage to try and have it addressed at the ecosystem level.

AshamedCaptain 2y ago

I'd think this is an extremely common pattern anyway (with the declared array length been 1, or even some other "minimal storage value"), and likely struct sockaddr's use of it is the cherry on the top.

dataflow 2y ago
The only embedded sizes I've ever seen are flex, 0, 1, and 14 (sockaddr's). It's trivial enough to exclude all of them.
- AshamedCaptain 2y ago
  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.
  - dataflow 2y ago
    > 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.
    - AshamedCaptain 2y ago
      Everything is an ABI issue. Dunno what the point or alternative is here.
      - dataflow 2y ago
        No? Not every struct is exposed to clients who can't change their code.
        AshamedCaptain 2y ago
        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'.
- garaetjjte 2y ago
  >flex, 0, 1 And each one can behave differently: https://lwn.net/Articles/908817/ https://lwn.net/Articles/908817/
poincaredisk 2y ago
It is in C, but not in the Linux kernel (according to TFA). That's why they're planning a big refactoring to get rid of this structure from the kernel