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