IRC, unknown channel, unknown date.
<pinotree> d'oh, broken defines for ioctl()! <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines <pinotree> tschwinge: ↑ know anything about this? <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header <youpi> that's possible <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' <youpi> ah, that's not a bug then <youpi> see the ioctl section of the porting page of the wiki <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough * pinotree looks <youpi> it's not to be done so simply <youpi> see the page :) <youpi> I'm afraid _IOT_arpreq can't be properly defined * pinotree is not finding it... <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html <youpi> that's it yes <youpi> I mean, that's the kind of thing <youpi> but not the wiki page, let me look <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html <pinotree> i also saw a glib patch adding few types like that (char, short, int) <youpi> yes that's the same kind of thing <pinotree> i see <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char <pinotree> so basically it would support at most 3 elements in a passed struct? <pinotree> s/elements/fields/ <youpi> 3 kinds of fields <youpi> as you provide a count <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? <pinotree> ie the order of the fields in the struct does not matter, it seems? <youpi> the order of the fields does matter <youpi> as this encodes how mig will read the struct to send them <pinotree> uhm <youpi> also, _IOTS(struct sockaddr) won't work <pinotree> yeah i should define it too <youpi> no, it even needs to be replaced by its content <pinotree> ah <pinotree> it is possible to compose the _IOTS()? <pinotree> (to build structs with more than 3 kind of fields) <youpi> no <pinotree> d'oh <youpi> that's a hard shortcoming of the whole ioctl encoding * pinotree scratches his head <youpi> there's no way but redefining ioctl(), really <youpi> it was a funny trick to encode it this way, but unrealistic <pinotree> i see, yes <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig <pinotree> indeed <youpi> actually it's not mach's ioctl issue <youpi> as mach doesn't know ioctl <youpi> but the hurd ioctl interface <pinotree> right <youpi> which might end up in mach, other processes, other machines, etc. * pinotree s/Mach/Hurd/ :)