tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New userspace fetch/store API
[thorpej]
> My intent was to cover the â??naturalâ??[*] fixed-size types for a
> particular arch, and then provide convenience aliases for the common
> basic C types: char, short, int, long, pointer.
C does not have a `pointer' type; what it has is a `pointer to
OTHER-TYPE' for each type OTHER-TYPE.
On all NetBSD ports I'm aware of, this is a distinction without a
difference, since all memory is the same and all pointers are just
memory addresses. Whether this is something to care about depends on
how much you are willing to depend on the compiler letting you get away
with things that C does not, strictly, promise.
[still thorpej, but another message]
> If weâ??re concerned about portability of the things using this API,
> then we simply specify the alignment to be sizeof(type). That check
> is straight-forward in MI C.
Not really. There is no MI way to check the alignment of a pointer.
Pointers cannot be arguments to & or %, and there is nothing MI about
converting a pointer to an integer.
Again, on all NetBSD ports I'm aware of, the situation is nicer; it
would be reasonable to say that it's straightforward in MI NetBSD code,
but it's not really MI C.
[dholland, replying to the second of the above quotes]
> No, even if you know what the alignment's supposed to be, you can't
> legally check it.
Well, you can check it, certainly. But such checking works, when it
does, only because the compiler happens to implement certain
implementation-dependent aspects of C in whichever way the checking
code you use expects.
[dholland, same message]
> Also, these days you can expect the compiler to simply remove such
> checks on the grounds that all pointers to types with required
> alignment are expected to be already aligned.
Such a compiler is not suitable for compiling kernels, because of
exactly this sort of thing. Compilers have a lot of latitude according
to the C spec, yes, but compilers that take advantage of it (and cannot
be told to not do so) are not suitable for building implementation
infrastructure, such as even malloc(), never mind a kernel.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index