On 03/02/2021 12:54, Kamil Rytarowski wrote:
This is still a valid usage and ABI breakage for userland. You cannot
blame a user for using system structures and headers that stop working
after an upgrade, at least before at least libc version bump.

For the record, I broke ABI here (it was the reverse situation, addition
of __packed).

https://github.com/NetBSD/src/commit/a833bd5cfdba983ecb5560512a3547f46f35f11e

I vote to revert and handling these structures with appropriate
functions that are aware of potentially misaligned data operations.

If we you or the project resist and insists on ABI breakage, it should
be boldly documented.

I don't buy this argument as we frequently do this:

r1.1
struct aaa {
        uint16 a;
};


r1.2
struct oaaa {
        uint16 a;
};

struct aaa {
        uint16 a;
        uint8 b;
};

Now if you choose to put your own stuff before and after in another struct, frankly you are really on your own.

Here's another example:

struct ehteripudp {
        struct etherhdr;
        struct iphdr;
        struct udphdr;
};

This still works!
However, it's potentially broken as you are making the assumption there are no options after the ip header.

Infact this is how all the network headers have been designed.
From the start of the structure you can chain header structures together until you either reach options or data.

But you *have* to interogate the headers in order to work this out.

Roy

Reply via email to