Re: Bi-arch 64-bit/32-bit bug in *chflags(2) on NetBSD / standardizing *chflags(2)?

[Garrett Cooper <yanegomi%gmail.com@localhost>]

On Mon, Jan 17, 2011 at 11:16 PM, matthew green <mrg%eterna.com.au@localhost> 
wrote:
>
>> Hello NetBSD folks,
>>     I just ran into this issue today (variable length unsigned long
>> used in chflags syscalls) on FreeBSD and I wasn't sure if anyone was
>> aware of the issue yet on NetBSD [1] . Just wanted to let you guys
>> know so that maybe the 3 major BSDs could get on the same page as far
>> as definitions go to reduce external developer pain in other projects
>> like Python [2], etc (I chose to standardize on fflags_t for clarity
>> as it already appeared to have been standardized to some degree in the
>> FreeBSD sourcebase, but that appears to be a FreeBSD-specific
>> typedef).
>>     Please let me know if I need to redirect this message to an alternate 
>> list.

...

> garrett.
>
>
> this is the right list, and thanks for the report.
>
> however, i'm pretty sure we don't have this bug.  all our *chflags()
> pass unsigned long, and our "netbsd32" compat has always converted
> the flags from 64 bit to 32 bit long.  deeper layers seem to convert
> to uint32_t at some point but this seems to be for on-disk format.
>
>
> i'm not sure i see much point of fflags_t at this point -- it would
> have to be typedef of "unsigned long" and would thus need _LP64
> #ifdef or platform specific #define's, which seems uglier than leaving
> it as unsigned long, though i'm not 100% wedded to this idea.
>
> what do others think?

Hi Matthew,
    Something someone reminded me of on the freebsd-fs list: what
about mixed archs or non-BE archs like ARM or MIPS :)?
Thanks,
-Garrett