Haai,
"Claudio Jeker" <cje...@diehard.n-r-g.com> wrote:
>>> 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).
This just adds fuel to me argument that we should ditch size_t,
uintptr_t, et al., in favour of a simple 'char *' (by that or any other
name (such as caddr_t)).
> 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.
Then me'd say that it's high time the relevant standards are updated to
reflect that reality.
The latter is, of course, outside the purview of OpenBSD. (But we can
set a good example.)
Thank you.
Baai,
--zeurkous.
--
Friggin' Machines!
