On Thu, Feb 27, 2020 at 02:07:36PM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Claudio Jeker" <cje...@diehard.n-r-g.com> wrote:
> > This has not much to do with OpenBSD.
>
> On the contrary: these issues touch the fundaments of UNIX programming.
>
> > 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.
>
> Oh yes, this is not NetBSD, me's well aware... And yet, metries hard to
> satisfy basic portability when feasible. This is consistent with OpenBSD
> practice, at least if the manual pages are anything to go by.
>
> > In both cases size_t is defined as unsigned long which is the same as
> > uintptr_t and the same size as pointer.
>
> Of course, in practice that's the case. You'll really get no argument
> from me there.
>
> > 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.
>
> Yes, the {,in}famous halfway split... for calculations involving
> already valid {addresse,offset,size}s that hardly matters, however.
>
> What *does* matter, is the potential lack of equivalence of the types.
> Which, as you pointed out, does not affect OpenBSD (at this time), yet
> might be a portability issue. Hence me raising it.
The times of non ILP32 or I32LP64 UNIX systems is over (at least when it
comes to userland processes). If you want a UNIX-like OS where code will
work then those are your only options. The ecosystem is not able to handle
anything else anymore. All the other discussions are theortical and will
not result in anything that is usable to run UNIX software.
--
:wq Claudio
