On 20/02/2012 17:21, Iain Buclaw wrote:
<snip>
> c_long and c_ulong are guaranteed to match target long size
<snip>

Which means what, exactly?

Stewart.

Am Mon, 20 Feb 2012 17:26:53 +0000
schrieb Stewart Gordon <smjg_1998@yahoo.com>:

> On 20/02/2012 17:21, Iain Buclaw wrote:
> <snip>
> > c_long and c_ulong are guaranteed to match target long size
> <snip>
> 
> Which means what, exactly?
> 
> Stewart.

Exactly what's written there, c_long and c_ulong always match the C long/ulong types, whatever size those may be. It's mostly (only?) useful for C bindings.

On 20 February 2012 19:21, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 20 February 2012 16:20, Manu <turkeyman@gmail.com> wrote:
> > On 20 February 2012 16:03, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >>
> >> On 20 February 2012 11:14, Manu <turkeyman@gmail.com> wrote:
> >> > On 20 February 2012 10:31, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >> >>
> >> >> On 19 February 2012 18:27, Manu <turkeyman@gmail.com> wrote:
> >> >> > On 19 February 2012 20:07, Timon Gehr <timon.gehr@gmx.ch> wrote:
> >> >> >>
> >> >> >> On 02/19/2012 03:59 PM, Manu wrote:
> >> >> >>>
> >> >> >>> Okay, so it came up a couple of times, but the questions is, what
> >> >> >>> are
> >> >> >>> we
> >> >> >>> going to do about it?
> >> >> >>>
> >> >> >>> size_t and ptrdiff_t are incomplete, and represent
> >> >> >>> non-complimentary
> >> >> >>> signed/unsigned halves of the requirement.
> >> >> >>> There are TWO types needed, register size, and pointer size.
> >> >> >>> Currently,
> >> >> >>> these are assumed to be the same, which is a false assumption.
> >> >> >>>
> >> >> >>> I propose size_t + ssize_t should both exist, and represent the
> >> >> >>> native
> >> >> >>> integer size. Also something like ptr_t, and ptrdiff_t should
> also
> >> >> >>> exist, and represent the size of the pointer.
> >> >> >>>
> >> >> >>> Personally, I don't like the _t notation at all. It doesn't fit
> the
> >> >> >>> rest
> >> >> >>> of the D types, but it's established, so I don't expect it can
> >> >> >>> change.
> >> >> >>> But we do need the 2 missing types.
> >> >> >>>
> >> >> >>> There is also the problem that there is lots of code written
> using
> >> >> >>> the
> >> >> >>> incorrect types. Some time needs to be taken to correct phobos
> too
> >> >> >>> I
> >> >> >>> guess.
> >> >> >>
> >> >> >>
> >> >> >> Currently, size_t is defined to be what you call ptr_t, ptrdiff_t
> is
> >> >> >> present, and what you call size_t/ssize_t does not exist. Under
> >> >> >> which
> >> >> >> circumstances is it important to have a distinct type that denotes
> >> >> >> the
> >> >> >> register size? What kind of code requires such a type? It is
> >> >> >> unportable.
> >> >> >
> >> >> >
> >> >> > It is just as unportable as size_t its self. The reason you need it
> >> >> > is
> >> >> > to
> >> >> > improve portability, otherwise people need to create arbitrary
> >> >> > version
> >> >> > mess,
> >> >> > which will inevitably be incorrect.
> >> >> > Anything from calling convention code, structure layout/packing,
> >> >> > copying
> >> >> > memory, basically optimising for 64bits at all... I can imagine
> >> >> > static
> >> >> > branches on the width of that type to select different paths.
> >> >> > Even just basic efficiency, using 32bit ints on many 64bit machines
> >> >> > require
> >> >> > extra sign-extend opcodes after every single load... total waste of
> >> >> > cpu
> >> >> > time.
> >> >> >
> >> >> > Currently, if you're running a 64bit system with 32bit pointers,
> >> >> > there
> >> >> > is
> >> >> > absolutely nothing that exists at compile time to tell you you're
> >> >> > running a
> >> >> > 64bit system, or to declare a variable of the machines native type,
> >> >> > which
> >> >> > you're crazy if you say is not important information. What's the
> >> >> > point
> >> >> > of a
> >> >> > 64bit machine, if you treat it exactly like a 32bit machine in
> every
> >> >> > aspect?
> >> >>
> >> >> gdc offers __builtin_machine_(u)int for word size, and
> >> >> __builtin_pointer_(u)int for pointer size via gcc.builtins module.
> >> >> Nevermind though, it's not quite a "standard" :~)
> >> >
> >> >
> >> > That's beautiful though! Can we alias them, and produce a true D type
> >> > that
> >> > represents them? :)
> >> >
> >> > My basic issue with these size_t/c_int/core.stdc... stuff, is that it
> >> > seems
> >> > the intent is to go out of the way to maintain compatibility with C,
> at
> >> > the
> >> > expense of sucking C's messy and poorly defined types into D, which
> is a
> >> > shame. It just results in D having the same crappy archaic typing
> >> > problems
> >> > as C.
> >> > I appreciate that the C types should exist for interoperability with C
> >> > (ie,
> >> > their quirks should be preserved for any given compiler/architecture),
> >> > but
> >> > I'd also like to see strictly defined types in D with no respect to
> any
> >> > C
> >> > counterpart, guaranteed by the language to be exactly what they claim
> to
> >> > be,
> >> > and not confused depending which compiler you try to use.
> >> >
> >> > These 2 GCC intrinsics would appear to be precisely what I was looking
> >> > for
> >> > at the start of this thread...
> >>
> >>
> >> Well, as Walter said, these could be aliased in core.stdc.config.
> >
> >
> > I don't think they are 'standard c' though ;)
>
> OK, I'm just having a trudge through druntime:
>
> intptr_t and uintptr_t are guaranteed to match pointer size.
>
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stdint.d#cl-70
>
> c_long and c_ulong are guaranteed to match target long size (here
> would also go c_int and c_uint ;-).
>
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/config.d#cl-22
>
> This needs fixing, as wchar_t may not be same size across all targets (some change size of wchar_t based on compile time switches).
>
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stddef.d#cl-28
>
> This needs fixing, as wint_t may not be same size across all targets.
>
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/wchar_.d#cl-29
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

It seems the problem is already MUCH worse than in D already :( .. this was
precisely my fear.
Why all these redundant aliases? Just for C compatibility?

Exactly one identifier for each concept should be nominated and promoted as
'standard' in D, and everyone use that same thing...
The myriad of aliases may still be useful for extern(C) I suppose, but I
think this is a major problem that needs careful consideration.

I think one of the most insidious side effects of this problem is that programmers don't fully understand what each type is meant to represent exactly, and they accidentally select the wrong one that just appears to do the job correctly on their machine/platform at that particular moment. I'm sure this is the reason behind C compilers messing up the definition of these themselves types so frequently.

On Feb 20, 2012, at 3:16 AM, Walter Bright wrote:

> On 2/20/2012 3:02 AM, Manu wrote:
>> ? I must have misunderstood something... I've never seen a 64bit C compiler where 'int' is 64bits.
> 
> What are you using in C code for a most efficient integer type?

I can't answer for Manu, but I imagine one should probably use int_fast32_t, etc.

On 20 February 2012 20:07, Artur Skawina <art.08.09@gmail.com> wrote:

> On 02/20/12 13:32, Stewart Gordon wrote:
> > On 20/02/2012 03:44, Artur Skawina wrote:
> > <snip>
> >>> Why would you want to do that, as opposed to use one of the pointer
> types (which is
> >>> indeed required for GC to work correctly)?
> >>
> >> That's how it can be used in *C*.
> >>
> >> And the reason it needs to be exposed to D code is for interoperability
> with C.
> >
> > IINM, C calling conventions care only about the size of a type, not the
> name or intrinsic nature of it.  Therefore this is a non-issue.
>
> struct S { uintptr_t a; };
> extern (C) uintptr_t f(S* s, uintptr_t* blah);
>
> "uintptr_t" is not the best example here (because it will rarely appear in
> C
> APIs), but still shows the problem - you need to know what it is -
> otherwise
> you're left with guessing and eg assuming that uintptr==size_t.
>
> Fixing historical mistakes can be hard.
>
> There are basically three types of integer types:
>
> a) known fixed size types, such as a 32-bit wide unsigned int
> b) types, that are not explicitly sized, but meet certain criteria,
>     eg: sizeof(short)<=sizeof(int)<=sizeof(long)
> c) externally defined types, which must always have the same
> representation,
>    the above uintptr_t example falls into this category.
>
> 'C' didn't have the (a) types, so everybody had to redefine u8/s16/u32/s64
> etc.
> 'D' added these as builtin types so that problem was solved. Unfortunately,
> instead of eg using the de facto std s16/s32/s64, D reused short/int/long.
> 'C's short/int/long were poorly (too loosely) defined, but what should have
> been done is defining them in 'D' as, for example:
>
> int:  efficient integer type, fitting in a CPU register and at least 32 bit wide;
>

No, this would be very very bad. People would use 'int' out of habit in
data structures, and mess up binary compatibility and alignment rules.
I personally quite like D's int types as they are, but note there are some
'missing' (well, not missing, as we're discussing, but they are not well
defined, or named, and needlessly aliased)


> long: efficient integer type, fitting in a CPU register and as wide as a GPR.
>

I don't think the term 'long' here, as opposed to 'int' draws this distinction... so I really can't buy into this logic.


> Fixing things up now, with for example "nativeInt" (maps to "int" above)
> and
> "widestInt" (the "long" above), is not easy. They are needed, that's why
> threads like this one appear, but simply adding them to the language or std
> library [1] wouldn't be enough. Why? Think literals, promotion and auto --
> I'm afraid programmers working with 'native' ints may not be expecting
> expressions evaluating to a narrower type.
>
> So there probably is no ideal simple solution for D2. For 64-bit platforms
> and
> a future D3 language, the int/long, as defined above, would be a mostly
> backward
> compatible change.
>

I prefer to explicitly identify these types personally. Predictable sized
types are better to have people punching away with no real consideration to
the specific use case.
People should only use these resizing types deliberately when they know
what they're doing.


> artur
>
> [1] fundamental types like these should not require any imports, so
> object.d
>    and/or compiler is the best place for them.
>

On Feb 20, 2012, at 11:43 AM, Manu wrote:

> On 20 February 2012 19:21, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> 
> OK, I'm just having a trudge through druntime:
> 
> intptr_t and uintptr_t are guaranteed to match pointer size. https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stdint.d#cl-70
> 
> c_long and c_ulong are guaranteed to match target long size (here
> would also go c_int and c_uint ;-).
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/config.d#cl-22
> 
> This needs fixing, as wchar_t may not be same size across all targets
> (some change size of wchar_t based on compile time switches).
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stddef.d#cl-28
> 
> This needs fixing, as wint_t may not be same size across all targets. https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/wchar_.d#cl-29
> 
> --
> Iain Buclaw
> 
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
> 
> It seems the problem is already MUCH worse than in D already :( .. this was precisely my fear. Why all these redundant aliases? Just for C compatibility?

core.stdc is an interface to the C99 API, so everything is preserved verbatim.  c_long and c_ulong were added because the size of C long differs between Windows and non-Windows x86_64 platforms.  Typically, int, short, etc are the same however, which is why there's currently no c_int--it was just a needless complication at the time.  The aliases for D users, if the exist at all, should be separate.

Am Mon, 20 Feb 2012 21:43:31 +0200
schrieb Manu <turkeyman@gmail.com>:

> On 20 February 2012 19:21, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> 
> > On 20 February 2012 16:20, Manu <turkeyman@gmail.com> wrote:
> > > On 20 February 2012 16:03, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> > >>
> > >> On 20 February 2012 11:14, Manu <turkeyman@gmail.com> wrote:
> > >> > On 20 February 2012 10:31, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> > >> >>
> > >> >> On 19 February 2012 18:27, Manu <turkeyman@gmail.com> wrote:
> > >> >> > On 19 February 2012 20:07, Timon Gehr <timon.gehr@gmx.ch> wrote:
> > >> >> >>
> > >> >> >> On 02/19/2012 03:59 PM, Manu wrote:
> > >> >> >>>
> > >> >> >>> Okay, so it came up a couple of times, but the questions
> > >> >> >>> is, what are
> > >> >> >>> we
> > >> >> >>> going to do about it?
> > >> >> >>>
> > >> >> >>> size_t and ptrdiff_t are incomplete, and represent
> > >> >> >>> non-complimentary
> > >> >> >>> signed/unsigned halves of the requirement.
> > >> >> >>> There are TWO types needed, register size, and pointer
> > >> >> >>> size. Currently,
> > >> >> >>> these are assumed to be the same, which is a false
> > >> >> >>> assumption.
> > >> >> >>>
> > >> >> >>> I propose size_t + ssize_t should both exist, and
> > >> >> >>> represent the native
> > >> >> >>> integer size. Also something like ptr_t, and ptrdiff_t
> > >> >> >>> should
> > also
> > >> >> >>> exist, and represent the size of the pointer.
> > >> >> >>>
> > >> >> >>> Personally, I don't like the _t notation at all. It
> > >> >> >>> doesn't fit
> > the
> > >> >> >>> rest
> > >> >> >>> of the D types, but it's established, so I don't expect
> > >> >> >>> it can change.
> > >> >> >>> But we do need the 2 missing types.
> > >> >> >>>
> > >> >> >>> There is also the problem that there is lots of code written
> > using
> > >> >> >>> the
> > >> >> >>> incorrect types. Some time needs to be taken to correct
> > >> >> >>> phobos
> > too
> > >> >> >>> I
> > >> >> >>> guess.
> > >> >> >>
> > >> >> >>
> > >> >> >> Currently, size_t is defined to be what you call ptr_t, ptrdiff_t
> > is
> > >> >> >> present, and what you call size_t/ssize_t does not exist.
> > >> >> >> Under which
> > >> >> >> circumstances is it important to have a distinct type that
> > >> >> >> denotes the
> > >> >> >> register size? What kind of code requires such a type? It
> > >> >> >> is unportable.
> > >> >> >
> > >> >> >
> > >> >> > It is just as unportable as size_t its self. The reason you
> > >> >> > need it is
> > >> >> > to
> > >> >> > improve portability, otherwise people need to create
> > >> >> > arbitrary version
> > >> >> > mess,
> > >> >> > which will inevitably be incorrect.
> > >> >> > Anything from calling convention code, structure
> > >> >> > layout/packing, copying
> > >> >> > memory, basically optimising for 64bits at all... I can
> > >> >> > imagine static
> > >> >> > branches on the width of that type to select different
> > >> >> > paths. Even just basic efficiency, using 32bit ints on many
> > >> >> > 64bit machines require
> > >> >> > extra sign-extend opcodes after every single load... total
> > >> >> > waste of cpu
> > >> >> > time.
> > >> >> >
> > >> >> > Currently, if you're running a 64bit system with 32bit
> > >> >> > pointers, there
> > >> >> > is
> > >> >> > absolutely nothing that exists at compile time to tell you
> > >> >> > you're running a
> > >> >> > 64bit system, or to declare a variable of the machines
> > >> >> > native type, which
> > >> >> > you're crazy if you say is not important information.
> > >> >> > What's the point
> > >> >> > of a
> > >> >> > 64bit machine, if you treat it exactly like a 32bit machine
> > >> >> > in
> > every
> > >> >> > aspect?
> > >> >>
> > >> >> gdc offers __builtin_machine_(u)int for word size, and
> > >> >> __builtin_pointer_(u)int for pointer size via gcc.builtins
> > >> >> module. Nevermind though, it's not quite a "standard" :~)
> > >> >
> > >> >
> > >> > That's beautiful though! Can we alias them, and produce a true
> > >> > D type that
> > >> > represents them? :)
> > >> >
> > >> > My basic issue with these size_t/c_int/core.stdc... stuff, is
> > >> > that it seems
> > >> > the intent is to go out of the way to maintain compatibility
> > >> > with C,
> > at
> > >> > the
> > >> > expense of sucking C's messy and poorly defined types into D,
> > >> > which
> > is a
> > >> > shame. It just results in D having the same crappy archaic
> > >> > typing problems
> > >> > as C.
> > >> > I appreciate that the C types should exist for
> > >> > interoperability with C (ie,
> > >> > their quirks should be preserved for any given
> > >> > compiler/architecture), but
> > >> > I'd also like to see strictly defined types in D with no
> > >> > respect to
> > any
> > >> > C
> > >> > counterpart, guaranteed by the language to be exactly what
> > >> > they claim
> > to
> > >> > be,
> > >> > and not confused depending which compiler you try to use.
> > >> >
> > >> > These 2 GCC intrinsics would appear to be precisely what I was
> > >> > looking for
> > >> > at the start of this thread...
> > >>
> > >>
> > >> Well, as Walter said, these could be aliased in core.stdc.config.
> > >
> > >
> > > I don't think they are 'standard c' though ;)
> >
> > OK, I'm just having a trudge through druntime:
> >
> > intptr_t and uintptr_t are guaranteed to match pointer size.
> >
> > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stdint.d#cl-70
> >
> > c_long and c_ulong are guaranteed to match target long size (here
> > would also go c_int and c_uint ;-).
> >
> > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/config.d#cl-22
> >
> > This needs fixing, as wchar_t may not be same size across all targets (some change size of wchar_t based on compile time switches).
> >
> > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stddef.d#cl-28
> >
> > This needs fixing, as wint_t may not be same size across all targets.
> >
> > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/wchar_.d#cl-29
> >
> > --
> > Iain Buclaw
> >
> > *(p < e ? p++ : p) = (c & 0x0f) + '0';
> >
> 
> It seems the problem is already MUCH worse than in D already :( ..
> this was precisely my fear.
> Why all these redundant aliases? Just for C compatibility?

That's exactly what those types are for and that's the reason they're in core.stdc.* . Maybe those types shouldn't be used in normal D code, but they are necessary for C bindings.

On 02/20/12 20:50, Manu wrote:
> On 20 February 2012 20:07, Artur Skawina <art.08.09@gmail.com <mailto:art.08.09@gmail.com>> wrote:
> 
>     On 02/20/12 13:32, Stewart Gordon wrote:
>     > On 20/02/2012 03:44, Artur Skawina wrote:
>     > <snip>
>     >>> Why would you want to do that, as opposed to use one of the pointer types (which is
>     >>> indeed required for GC to work correctly)?
>     >>
>     >> That's how it can be used in *C*.
>     >>
>     >> And the reason it needs to be exposed to D code is for interoperability with C.
>     >
>     > IINM, C calling conventions care only about the size of a type, not the name or intrinsic nature of it.  Therefore this is a non-issue.
> 
>     struct S { uintptr_t a; };
>     extern (C) uintptr_t f(S* s, uintptr_t* blah);
> 
>     "uintptr_t" is not the best example here (because it will rarely appear in C
>     APIs), but still shows the problem - you need to know what it is - otherwise
>     you're left with guessing and eg assuming that uintptr==size_t.
> 
>     Fixing historical mistakes can be hard.
> 
>     There are basically three types of integer types:
> 
>     a) known fixed size types, such as a 32-bit wide unsigned int
>     b) types, that are not explicitly sized, but meet certain criteria,
>         eg: sizeof(short)<=sizeof(int)<=sizeof(long)
>     c) externally defined types, which must always have the same representation,
>        the above uintptr_t example falls into this category.
> 
>     'C' didn't have the (a) types, so everybody had to redefine u8/s16/u32/s64 etc.
>     'D' added these as builtin types so that problem was solved. Unfortunately,
>     instead of eg using the de facto std s16/s32/s64, D reused short/int/long.
>     'C's short/int/long were poorly (too loosely) defined, but what should have
>     been done is defining them in 'D' as, for example:
> 
>     int:  efficient integer type, fitting in a CPU register and at least 32 bit wide;
> 
> 
> No, this would be very very bad. People would use 'int' out of habit in data structures, and mess up binary compatibility and alignment rules.

Explicitly sized types (ie u32 and friends) is what should be used by default in any externally visible data structures. Yes, D's attempt at redefining int and long as fixed-size integers will cause confusion. But note that the compiler could help here, by disallowing any use of int and long in aggregates not marked with an 'internal' attribute. So a relatively safe migration path might be possible.

> I personally quite like D's int types as they are, but note there are some 'missing' (well, not missing, as we're discussing, but they are not well defined, or named, and needlessly aliased)
> 
> 
>     long: efficient integer type, fitting in a CPU register and as wide as a GPR.
> 
> 
> I don't think the term 'long' here, as opposed to 'int' draws this distinction... so I really can't buy into this logic.
> 
> 
>     Fixing things up now, with for example "nativeInt" (maps to "int" above) and
>     "widestInt" (the "long" above), is not easy. They are needed, that's why
>     threads like this one appear, but simply adding them to the language or std
>     library [1] wouldn't be enough. Why? Think literals, promotion and auto --
>     I'm afraid programmers working with 'native' ints may not be expecting
>     expressions evaluating to a narrower type.
> 
>     So there probably is no ideal simple solution for D2. For 64-bit platforms and
>     a future D3 language, the int/long, as defined above, would be a mostly backward
>     compatible change.
> 
> 
> I prefer to explicitly identify these types personally. Predictable sized types are better to have people punching away with no real consideration to the specific use case.
> People should only use these resizing types deliberately when they know what they're doing.

I'd like to avoid using these long-named 'nativeInt' types when I know what I'm doing... ;)

But, other than the 'int' and 'long' names, would such two types be enough?

For D2 I'll probably end up aliasing them to something like rint/urint and wint/uwint anyway; short-term the question is only how to reliably find the alias source.

artur

On 2012-02-20 18:26, Stewart Gordon wrote:
> On 20/02/2012 17:21, Iain Buclaw wrote:
> <snip>
>> c_long and c_ulong are guaranteed to match target long size
> <snip>
>
> Which means what, exactly?
>
> Stewart.

Simplified:

32bit:

Windows long == 32bit
Posix long == 32bit

64bit:

Windows long == 32bit
Posix long == 64bit

For a complete table of the 64bit data models see:

http://en.wikipedia.org/wiki/64-bit#64-bit_data_models

-- 
/Jacob Carlborg

On 20 February 2012 21:51, Sean Kelly <sean@invisibleduck.org> wrote:

> On Feb 20, 2012, at 11:43 AM, Manu wrote:
>
> > On 20 February 2012 19:21, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >
> > OK, I'm just having a trudge through druntime:
> >
> > intptr_t and uintptr_t are guaranteed to match pointer size.
> >
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stdint.d#cl-70
> >
> > c_long and c_ulong are guaranteed to match target long size (here
> > would also go c_int and c_uint ;-).
> >
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/config.d#cl-22
> >
> > This needs fixing, as wchar_t may not be same size across all targets (some change size of wchar_t based on compile time switches).
> >
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stddef.d#cl-28
> >
> > This needs fixing, as wint_t may not be same size across all targets.
> >
> https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/wchar_.d#cl-29
> >
> > --
> > Iain Buclaw
> >
> > *(p < e ? p++ : p) = (c & 0x0f) + '0';
> >
> > It seems the problem is already MUCH worse than in D already :( .. this
> was precisely my fear.
> > Why all these redundant aliases? Just for C compatibility?
>
> core.stdc is an interface to the C99 API, so everything is preserved verbatim.  c_long and c_ulong were added because the size of C long differs between Windows and non-Windows x86_64 platforms.  Typically, int, short, etc are the same however, which is why there's currently no c_int--it was just a needless complication at the time.  The aliases for D users, if the exist at all, should be separate.


What about intptr_t/uintptr_t, are they builtins, or in core.stdc?