Haai,
"Claudio Jeker" 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
On Thu, Feb 27, 2020 at 02:07:36PM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Claudio Jeker" 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 I32L
Haai,
"Claudio Jeker" 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
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 a
Haai,
"Marc Espie" 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 si
On Wed, Feb 26, 2020 at 11:01:56PM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Marc Espie" wrote:
> > On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz 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'
Haai,
"Marc Espie" wrote:
> On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz 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.
> Try uintptr_t
Are you proposing a change to struct iovec?
--zeur
Haai,
"Anders Andersson" wrote:
> On Tue, Feb 25, 2020 at 12:14 PM wrote:
>>
>> First of all, let us reflect upon the definition of size_t in C99.
>>
>> > size_t
>> > which is the unsigned integer type of the result of the sizeof
>> > operator;
>>
>> That's not very specific. It kind-of implies
On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> The definition of size_t keeps biting me.
>
> Some background: in nnx, me's been using the equiv of caddr_t for
> counts. This works well; yet, while writing against existing code that
> uses size_t, an issue has surfa
On Tue, Feb 25, 2020 at 12:14 PM wrote:
>
> Haai,
>
> The definition of size_t keeps biting me.
>
> Some background: in nnx, me's been using the equiv of caddr_t for
> counts. This works well; yet, while writing against existing code that
> uses size_t, an issue has surfaced.
>
> First of all, let
On Thu, Oct 12, 2017 at 3:18 PM, wrote:
> On a related note, would you folks be interested in patches removing
> said assumpting of equivalence from programs like dd(1)?
I would assume yes, unless those patches broke dd on some platforms.
(Patches which break things tend to provoke a rather neg
"Ian Sutton" wrote:
>
> An important thing to ask yourself before suggesting things like this
> is "if this is such an obvious and trivial improvement, then why
> hasn't anyone already done it?". To put things in perspective, we had
> an entire release primarily predicated upon increasing the widt
On Thu, Oct 12, 2017 at 12:58 PM, wrote:
> Hi,
>
> I just discovered, to my dismay, that size_t is only 32 bits, even on
> 64-bit processors. Is there a particular pressing reason for this? A
> quick investigation reveals that even dd(1) is affected -- this is IMO
> not good.
>
> I'd suggest, giv
Hi,
"Janne Johansson" wrote:
>
>> Okay, I don't have a 64-bit machine running OpenBSD to check -- but is
>> 'long'
>> 64-bits on those?
>
> How did you manage to come to the first conclusion, given the second part
> later?
*shrugs* an incorrect assumption.
--schaafuit.
2017-10-12 20:04 GMT+02:00 :
> Hi,
>
> >> I just discovered, to my dismay, that size_t is only 32 bits, even on
> >> 64-bit processors.
> Okay, I don't have a 64-bit machine running OpenBSD to check -- but is
> 'long'
> 64-bits on those?
How did you manage to come to the first conclusion, given
theo wrote:
>
> No, not really. If you won't use the publically available source tree
> and vast amounts of documentation about POSIX but instead jump
> straight towards assertive dialogue on a mailing list, then I don't
> see how we can help.
Funny thing is, you already explained in your other me
> >> I just discovered, to my dismay, that size_t is only 32 bits, even on
> >> 64-bit processors. Is there a particular pressing reason for this? A
> >> quick investigation reveals that even dd(1) is affected -- this is IMO
> >> not good.
> >
> > You are wrong.
> >
> > limits.h:#define SIZE_T_MAX
Hi,
>> I just discovered, to my dismay, that size_t is only 32 bits, even on
>> 64-bit processors. Is there a particular pressing reason for this? A
>> quick investigation reveals that even dd(1) is affected -- this is IMO
>> not good.
>
> You are wrong.
>
> limits.h:#define SIZE_T_MAX ULONG_MAX /
> I just discovered, to my dismay, that size_t is only 32 bits, even on
> 64-bit processors. Is there a particular pressing reason for this? A
> quick investigation reveals that even dd(1) is affected -- this is IMO
> not good.
You are wrong.
limits.h:#defineSIZE_T_MAX ULONG_MAX
19 matches
Mail list logo
