On Feb 20, 2012, at 2:34 PM, Manu wrote:
> 
> What about intptr_t/uintptr_t, are they builtins, or in core.stdc?

core.stdc.  The only aliases that currently exist are defined in object.di:

alias typeof(int.sizeof)                    size_t;
alias typeof(cast(void*)0 - cast(void*)0)   ptrdiff_t;
alias ptrdiff_t                             sizediff_t;

We probably need to add ssize_t at some point.  Not sure about anything more than that.

On 2/20/2012 3:28 AM, Manu wrote:
> Even size_t is often
> broken in C. I have worked on 64bit systems with 32bit pointers where size_t was
> still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this, but maybe my
> memory fails me)

I don't know how that could be considered C standard compliant.

> I want to be confident when I declare a numeric type that can interact with
> pointers, and also when I want the native type.

I think you're probably best off for now by doing your own alias for it.

On 21 February 2012 12:22, Walter Bright <newshound2@digitalmars.com> wrote:
> On 2/20/2012 3:28 AM, Manu wrote:
>>
>> Even size_t is often
>> broken in C. I have worked on 64bit systems with 32bit pointers where
>> size_t was
>> still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this, but maybe
>> my
>> memory fails me)
>
>
> I don't know how that could be considered C standard compliant.
>
>
>> I want to be confident when I declare a numeric type that can interact
>> with
>> pointers, and also when I want the native type.
>
>
> I think you're probably best off for now by doing your own alias for it.

I don't know much about what is considered 'standard C', non x86 platforms or the intricacies of native types, so I would like some clarification on the argument going on here.

AFAICT, The problem is that size_t is assumed to be the both the size of the pointer and the size of the native int, but sometimes the native int isn't the same as the size of the pointer? So you can have 64bit native ints and 32bit pointers (and maybe even vice-versa)?

I also saw reference to register sizes, which I assumed, but am now guessing to be wrong, were the same size as pointers. So the problem seems to be that there are the following things that are all different sizes:

 * fixed int (32 bit)
 * native int
 * pointer
 * register

But some types are conflating them?

The argument seems to be confusing me because it jumps rapidly from talking about different processors to different OSes to the C standard.

If the only problem is that we need some more types, can't we add them in? I don't see the problem with having verbose, import-only names for things outside the norm, alias them if you want, longer names are better for newcomers. For example, what is ptrdiff_t? I have never seen that before, and the name doesn't help me, from the alias in druntime, it seems to be the type that represents the difference between 2 pointers. Help me out here, what on earth would I use that for?

(On a side note to that, no way is ssize_t a good name, ever, forwards and backwards, what on earth is it? super-size_t? here to save you? shady-size_t? you have to make sure it doesn't sell you drugs? size-size_t? it has a stammer?)

I also saw a lot of talk about C compilers that don't do the right thing, is that relevant? (I mean that sincerely, not criticism)

On 02/21/12 04:12, James Miller wrote:
> If the only problem is that we need some more types, can't we add them in? I don't see the problem with having verbose, import-only names for things outside the norm, alias them if you want, longer names are better for newcomers. For example, what is ptrdiff_t? I have never seen that before, and the name doesn't help me, from the alias in druntime, it seems to be the type that represents the difference between 2 pointers. Help me out here, what on earth would I use that for?

In C, for storing the result of (a-b), where a and b are pointers.

> (On a side note to that, no way is ssize_t a good name, ever, forwards and backwards, what on earth is it? super-size_t? here to save you? shady-size_t? you have to make sure it doesn't sell you drugs? size-size_t? it has a stammer?)

It's signed, unlike the unsigned 'size_t'.


Types like ptrdiff_t are not necessary in D, because you can write portable code using 'auto' and 'typeof()' - std C didn't have these, so a type had to be invented for everything.

D only lacks the 'native' types; while you can, in most cases, find them out using import and version(), the compiler obviously already knows what they are for every supported target. So it's just about exposing them to the compiled code in a std, defined way.

The 'C' types are only needed for interoperability, for example - the glib bindings needed these:
> import core.stdc.limits: c_long, c_ulong;
> alias  int c_int;  // Assumes 32-bit wide int.
> alias uint c_uint; // Assumes 32-bit wide int.
> import core.sys.posix.sys.types : time_t, ssize_t;

IIRC I did not find the C int types conveniently defined anywhere and didn't want to use GCC extensions. ssize_t is std and common enough that it could live outside that sys.posix module. Maybe this is also true for time_t and a few others that weren't needed in this case.

artur

On 21 February 2012 01:22, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/20/2012 3:28 AM, Manu wrote:
>
>> Even size_t is often
>> broken in C. I have worked on 64bit systems with 32bit pointers where
>> size_t was
>> still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this, but maybe
>> my
>> memory fails me)
>>
>
> I don't know how that could be considered C standard compliant.


I don't know about you, but I very rarely get to work with a C compiler
that is 'standards compliant'.. that concept is kinda like a cruel joke in
my experience. Does one even exist? :)
I would like to have seen size_t and ptrdiff_t (and friends) also live in
core.stdc... and D define and implement its own strictly compliant
concepts. As is, any GDC build will have those types defined exactly as in
the C compiler... broken or not, and since they're used to interact with C
code, it can't be any other way.

I want to be confident when I declare a numeric type that can interact with
>> pointers, and also when I want the native type.
>>
>
> I think you're probably best off for now by doing your own alias for it.
>

Fair enough I guess. Consider it though. I really don't want to rely on
core.stdc; that idea makes me feel very uneasy, considering how badly C
stuffs all this stuff up.
I also don't want to have to import something to access the most basic of
types.

On Sunday, 19 February 2012 at 16:23:50 UTC, Manu wrote:
> On 19 February 2012 18:03, Vladimir Panteleev
> <vladimir@thecybershadow.net>wrote:
>
>> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>>
>>> There is code that assumes size_t is the width of the pointer
>>
>> When is this not true? I can only think of 16-bit far pointers.
>>
> word/pointer width mismatch does happen

I know there are many systems with mismatching machine word and pointer size. I asked about cases where size_t.sizeof != (void*).sizeof.

On 20/02/2012 19:11, Johannes Pfau wrote:
<snip>
> 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.

So in other words, it just means whatever somebody has decreed that the "long" keyword in C shall mean on that platform.

When did C gain a type called ulong, anyway?

Are we going to have c_long_long as well?

Stewart.

> 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

That is so good! Thanks!

Currently, htod translates "unsigned long" to uint, which is wrong in linux 64 bits. Translating to size_t fixes that for linux, but I fear that a C "unsigned long" is not 64bit in all 64bit systems (windows):

    "About size_t and ptrdiff_t"
    http://www.codeproject.com/Articles/60082/About-size_t-and-ptrdiff_t

Ran into this problem with mysql.h:

	typedef st_mysql_field {
            ...
            unsigned long length;
            unsigned long max_length;
            unsigned int name_length;
            ...
        }

The only adequate fix, is your c_long that matches C's long.

This is because uint doesn't change when in 64bit, and size_t fixes it for linux but maybe not for windows.


The C standard only guarantees that:

  sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(size_t)

Which is insane. At some point in history, a C int meant the native register size for fast integer operations. But now C int seems to have been frozen to 32bits to avoid struct hell.

So, in conclusion, my opinion is that there is no sane way
of mapping C types to D types but to use something like your
c_int, c_uint, c_long, c_ulong. Otherwise, the insanity
of non-standard sizes and portability never stops.

Love the intptr_t!

A REQUEST: how about adding a c_size_t too?

--jm

On 21 February 2012 22:45, Juan Manuel Cabo <juanmanuel.cabo@gmail.com> wrote:
>
> A REQUEST: how about adding a c_size_t too?
>

Eh?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

> Eh?

All the type sizes vary in broken ways in C. The only sane way
to port C structs to D is to use c_<type> that has the size of the
C compiler in the target platform.

If there is a single C compiler has a different sized size_t
than D's, then one has achieved nothing with the c_int, c_long, etc.

So that is why it'd be nice, in my opinion, to have c_size_t (and c_ssize_t) if we are going to have c_int, c_long, etc.


Sorry for requesting things though!! I still don't know my way around here.

--jm


On 02/21/2012 08:35 PM, Iain Buclaw wrote:
> On 21 February 2012 22:45, Juan Manuel Cabo <juanmanuel.cabo@gmail.com> wrote:
>>
>> A REQUEST: how about adding a c_size_t too?
>>
> 
> Eh?
> 
>