This has not much to do with OpenBSD.
As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
Any other type of machine that is not covered by these two types will
not run OpenBSD.
In both cases size_t is defined as unsigned long which is the same as
uintptr_t and the same size as pointer.
Now if SIZE_MAX is the highest address is a different thing.
On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
it covers actually more then what is possible). The highest valid
address is in most cases less than SIZE_MAX.
--
:wq Claudio
On Thu, Feb 27, 2020 at 01:36:39AM +0100, zeurk...@volny.cz wrote:
> 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!
>
