The problem seems likely to be related to odd compiler handling of
alignment. Consider this code bit, which extracts the essentials:
struct x {
int x;
} __attribute__((__aligned__(32)));
struct s1 {
int a;
struct x b[1];
True, it's not actually odd, it's just surprising the first time
one comes across it.
Also, I goofed in the text:
>> With the flexible array, (sizeof(struct uma_cache)) is going to be
>> 32 bytes smaller than without it.
It's `struct uma_zone` that shrinks by (potentially) more than one
would ex
>I don't know much about CMSG*, so I wouldn't have if you didn't ask :-).
One thing to know about the CMSG (control message) stuff is that
it is badly broken, at least on I32LP64 systems. Not the CMSG_*
aligning macros themselves (the alignment is linked to stuff I did
back in the early sparc-por
>> Can you explain a little bit about the badly behaved ordering of
>> unsigned integers? I am not familiar with that.
>
>The strongest ordering properties for real numbers depend on the existence
>of negative numbers (and zero). E.g., x >= y if and only if x - y >= 0.
>To apply that, you need th
POSIX committee or something.
(I also wrote some halfway useable reentrant getpw* and getgr*
functions but they need more thought and do not play well with
nsswitch so I am not including them here. NB: rfuncs.h just
contains declarations for these reentrant r_* functions.)
Chris
---
/*
>That was what I was complaining about. div.c is for C90 (misspelled
>"ANSI").
It wasn't misspelled when I wrote it. :-) The 1989 ANSI C
standard was formally ratified in Dec 1989, and the draft was
pretty firm by the time I wrote the code (which I am sure was also
1989, despite the 1990 copyri
