4 ms·

The real blocker is that the various solutions are almost certainly never ABI-compatible with existing code, and for most people it's unrealistic to recompile t

by o11c 3y ago

The real blocker is that the various solutions are almost certainly never ABI-compatible with existing code, and for most people it's unrealistic to recompile the world (and even if you can forbid inline asm elsewhere, libc is nasty). (edit: I suppose WASM is sort of forcing that though, but unfortunately it didn't take the opportunity to allow dynamically fixing this) A solution is mostly possible with a segmented allocator, which is quite reasonable on 64-bit platforms (32-bit allocation ID, 32-bit index within the allocation). But keep in mind that "buffer overflow within a struct" is often considered a feature. I think the best approach is "design a new, 'safe' language that compiles to reasonable C code, and make it easy to port to that new language incrementally".

mlindner 3y ago
> But keep in mind that "buffer overflow within a struct" is often considered a feature. Yes this is used rampantly in any kind of code that's running in basically all of the world's network appliances that do packet processing. I'd even say it's considered "best practice" by most C programmers.
- layer8 3y ago
  It's been an explicit language feature (flexible array members) since C99.
raverbashing 3y ago
> But keep in mind that "buffer overflow within a struct" is often considered a feature. Yes, one of those "features" designed to work around limitations of the language C is "simple" in the same way a chainsaw without guards or brakes is "simpler" than one with those attachments
- layer8 3y ago
  The C standard defines which array accesses are valid or not in the C abstract machine. This definition isn’t simple at all. A C implementation can in principle add runtime machinery to check all accesses during execution. C implementations generally don't, due to performance and ABI compatibility reasons. But C the language doesn’t prohibit it. Most existing programs making use of "buffer overflow within a struct" probaby aren't actually conforming C programs.
Animats 3y ago
> "buffer overflow within a struct" is often considered a feature. That's lying to the compiler, because there's no way to say what you meant. That's why I proposed the syntax typedef struct msgitem { const size_t len; char itemvalue[len]; }; struct msgitem firstmsg = { 100, 0 }; // empty msgitem, size 100 The last item of a struct could be a variable sized array. That's sound, and enough for things such as network packets. It's important to avoid bikeshedding.
- dataflow 3y ago
  What do you do when the length isn't a field in the same struct?
  - Animats 3y ago
    There must be an expression which can be evaluated to determine the length of the array, and which can thus be used for checking. Without that, the code has little chance of working, since something had better define the size of that array.
    - dataflow 3y ago
      I mean the expression doesn't have to come from the same struct, though. It could be provided somewhere else.
      - Dylan16807 3y ago
        If the somewhere else can't be located in a straightforward way, I'd say just change the code.
        dataflow 3y ago
        > If the somewhere else can't be located in a straightforward way It might very well be straightforward to obtain, just not located in that struct itself. > I'd say just change the code. And if the code isn't available to you to change?

by o11c 3y ago

mlindner 3y ago

> But keep in mind that "buffer overflow within a struct" is often considered a feature. Yes this is used rampantly in any kind of code that's running in basically all of the world's network appliances that do packet processing. I'd even say it's considered "best practice" by most C programmers.

layer8 3y ago
It's been an explicit language feature (flexible array members) since C99.

raverbashing 3y ago

> But keep in mind that "buffer overflow within a struct" is often considered a feature. Yes, one of those "features" designed to work around limitations of the language C is "simple" in the same way a chainsaw without guards or brakes is "simpler" than one with those attachments

layer8 3y ago
The C standard defines which array accesses are valid or not in the C abstract machine. This definition isn’t simple at all. A C implementation can in principle add runtime machinery to check all accesses during execution. C implementations generally don't, due to performance and ABI compatibility reasons. But C the language doesn’t prohibit it. Most existing programs making use of "buffer overflow within a struct" probaby aren't actually conforming C programs.

Animats 3y ago

> "buffer overflow within a struct" is often considered a feature. That's lying to the compiler, because there's no way to say what you meant. That's why I proposed the syntax typedef struct msgitem { const size_t len; char itemvalue[len]; }; struct msgitem firstmsg = { 100, 0 }; // empty msgitem, size 100 The last item of a struct could be a variable sized array. That's sound, and enough for things such as network packets. It's important to avoid bikeshedding.

dataflow 3y ago
What do you do when the length isn't a field in the same struct?
- Animats 3y ago
  There must be an expression which can be evaluated to determine the length of the array, and which can thus be used for checking. Without that, the code has little chance of working, since something had better define the size of that array.
  - dataflow 3y ago
    I mean the expression doesn't have to come from the same struct, though. It could be provided somewhere else.
    - Dylan16807 3y ago
      If the somewhere else can't be located in a straightforward way, I'd say just change the code.
      - dataflow 3y ago
        > If the somewhere else can't be located in a straightforward way It might very well be straightforward to obtain, just not located in that struct itself. > I'd say just change the code. And if the code isn't available to you to change?