tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



> 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.
> Thanks!
> -Garrett

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?


.mrg.


Home | Main Index | Thread Index | Old Index