Haai,
"Marc Espie" <es...@nerim.net> wrote:
>>> You're looking at the wrong type. size_t is very good for what it does.
>>
>> Yes; meproblem is with the 'what it does' part.
>
> It represents memory sizes. It works on anything with a sane
> memory model.
The way meunderstands it, it's just an offset, plain and simple. Which
on a sane machine is indeed of the same type as an address[0].
Unfortunately, C99 does not appear to reflect that. Now, to what degree
(if!) we should respect C99, or take it much seriously at all, is
another matter...
>>> Try uintptr_t
>>
>> Are you proposing a change to struct iovec?
>
> Why should I ? readv works with sizes, so size_t is adequate.
Yes, why should you? That was me implied question. You told me to use
uintptr_t, but that will hardly solve things on the exact problem mewas
working on (medidn't specify what it was, and you didn't ask), unless we
change struct iovec (cue an 'over my dead body' response from theo, and
with respect to compat, he'd be damn right).
> You were mentionning caddr_t earlier. intptr_t and uintptr_t are
> the adequate types for working with addresses. size_t is the adequate
> family for working with sizes.
Me's found that such statements emerge from a shallow understanding of
the nature of C. C doesn't know sizes: indeed, it barely knows indices
and offsets. If sizeof() would have been defined to return the index
of the final byte, instead of the count of bytes, then the C99
definition for size_t would've been pre-empted.
> POSIX kind-of implies readv, which means that both realms tend of
> mesh.
Yes, that's an obvious layer error. C as a language should not be
confused with libc, or UNIX in general. In fact, C and UNIX appear to
only have two concrete things in common: ASCII, and the byte as the
fundamental type. That's it.
> If you're on something where they don't, you're fucked.
Me's never been the type to play it safe. The path forward is not blind
obedience to the ravings of committees, especially those that pretend to
set a universal standard.
> Good luck.
Thanks. Me's decided to ditch the {read,write}v compat wrappers and take
the performance hit. It's all preperation for a real OS, after all:
me'll do it right in there.
> What are you doing asking questions on an OpenBSD list, btw ?
nnx runs on OpenBSD. You must be confusing it with NetNIX, which is the
OS that will eventually emerge.
NetNIX will not have size_t.
Baai,
--zeurkous.
[0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
of the problems if SIZE_MAX is not guaranteed to be the highest
address...
--
Friggin' Machines!
