I don't think the existing binary problem CAN be solved - unless the code calls some function to enquire about the alignment, and then uses that. That of course assumes first and foremost that there is a suitable API to provide this information in the first place.
But having a constant that "if you just recompile, it will be fine" is a better solution than "you have to change your constant that you invented for your code to n, then recompile". And it gets more interesting when architecture A needs alignment of 8, architecture B needs 4, and architecture C needs alignment of 16. For portable code, this is quite a lot of work - unless you assume "largest of the different values", but using 16 can be quite a lot of overhead with many small allocations (linked lists and trees with small members, for example). -- Mats On 13 December 2014 at 19:18, Joerg Sonnenberger <[email protected]> wrote: > On Sat, Dec 13, 2014 at 06:43:03PM +0000, mats petersson wrote: > > If the alignment, then surely "SuitableAlignment" should also change? It > > "SuitableAlignment" isn't the right thing to use for "largest alignment", > > then perhaps a new member is needed, but I thought that > "SuitableAlignment" > > was for "The alignment you need to ensure that data is aligned correctly. > > But such change doesn't help *existing* binaries. We've had such fun in > NetBSD with the Unix Domain Socket control message interface before, > encoding "maximum alignment" implicitly in the ABI is not fun. That's > why I am asking what the future compatibility promises around this > interface are. > > Joerg > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
