On 22/02/12 06:16, Walter Bright wrote:
> On 2/21/2012 6:07 PM, Juan Manuel Cabo wrote:
>> 16bit intel had 16bit segments and offsets, so memory was segmented
>> and you couldn't address more than 64kb at a time.
>> So you couldn't have grabbed^H^H"allocated" more than 64kb in real
>> mode in intel
>> in a single linear block.
>
> size_t was 16 bits on all 16 bit memory models except the 'huge' one.

I expected that for ptrdiff_t, but for size_t as well?

So sizeof(int *) was larger than size_t ?

On 22 February 2012 17:16, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> On 22/02/2012 07:24, Jacob Carlborg wrote:
>
>> On 2012-02-22 06:24, Walter Bright wrote:
>>
>>> On 2/21/2012 2:11 PM, Stewart Gordon wrote:
>>>
>> <snip>
>
>  Are we going to have c_long_long as well?
>>>>
>>>
>>> Probably.
>>>
>>
>> Wouldn't that always be a "long" in D? Or is it the same as with "long" in C.
>>
>
> long in D is 64 bits.
> long in C is 32 bits (on Win16/32 at least).
>
> If the C standard sets in stone the size of a long long, then we can do away with a c_long_long and just use long.  Otherwise, if we're going to have c_int and c_long, it only makes sense to have c_long_long as well.


The C standard is completely irrelevant to D, and should not be considered.
The C 'standard' is a guideline at best. I've worked with so many compilers
over the years that fail, or ignore the standard in all kinds of ways.
Their decisions towards the declaration of these fundamental types is a
classic fuck up on lots of compilers.
I can't trust anything in D defined to be "what c says".. if it's not
defined and guaranteed by D, consider it as not-portable, and you'll
probably need to start aliasing your own types inside super-portable
libraries; version the hell out of it for every compiler you can find, just
like C libs do. (Hello GLint (OpenGL), hkFloat(Havok), DWORD (windows),
etc... can you think of a single super-portable library that DOESN'T
redefine its primitive types?).
As D cross compilers become more and more common, or other D compiler
implementations begin to appear, the magnitude of the error will get more
and more obvious, and also the longer it's left, the more impossible it
will be to change.
GDC takes its types from GCC verbatim, and they'll be every bit as broken
as they would be in the corresponding C compiler.

I just want D to define its types (including pointer (u)int, and native
(u)int) explicitly in the D standard, and try and enforce it somehow to the
tragedy never appears in D.

On 22 February 2012 17:39, Don Clugston <dac@nospam.com> wrote:

> On 22/02/12 06:16, Walter Bright wrote:
>
>> On 2/21/2012 6:07 PM, Juan Manuel Cabo wrote:
>>
>>> 16bit intel had 16bit segments and offsets, so memory was segmented
>>> and you couldn't address more than 64kb at a time.
>>> So you couldn't have grabbed^H^H"allocated" more than 64kb in real
>>> mode in intel
>>> in a single linear block.
>>>
>>
>> size_t was 16 bits on all 16 bit memory models except the 'huge' one.
>>
>
> I expected that for ptrdiff_t, but for size_t as well?
>
> So sizeof(int *) was larger than size_t ?
>

I've worked on platforms where sizeof(void*) was smaller than sizeof(size_t)