Re: Patch for graphics/lcms2 (alignment issues on sparc)

[Greg Troxel <gdt%lexort.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> On Sat, Oct 31, 2026 at 09:05:04PM -0400, Greg Troxel wrote:
>  > > Maybe this should be alignof(max_align_t) instead?  I expect this
>  > > affects more than just sparc32.
>  > 
>  > In this case, we really need to know the alignment for doubles, as I
>  > understand it.  Having some other type with even biggger alignment would
>  > cause max_align_t to be bigger, and that would be wasteful.
>  > 
>  > Anyone with a retro arch that needs more then 4 for doubles, please
>  > speak up.
>
> You can do something like
>
>    union foo {
>            int y;
>            double x;
>            char *z;
>    };
>
> that specifically includes exactly the types needed, and ask for its
> alignment.
>
> In the absence of alignof, it's probably sufficient to also do
>
>    struct bar {
>            unsigned char a;
>            union foo b;
>    };
>
> and take offsetof(struct bar, b). There's no guarantee that compilers
> won't insert extra padding in structs, but reasonable ones don't.

Yes, someone could do all that.  But we are in a situation where
upstream is intentionally disinterested, and we have a simple adjustment
for sparc that has a near-zero chance of causing problems on !sparc.  I
don't think it's ok to block adding that simple accomodation because in
theory someone could make a more general fix.

I am not interested in working on the more complicated change.  That's
partly because I don't want to persistently maintain differences from
upstream if it's not really necessary.  And partly because we haven't
even identified another specific platform with this issue.

I don't have any objection to a more complete fix arriving (if it
doesn't worsen memory usage on any platform that works now), as long as
it doesn't result in future merge conflicts.