View mode: basic / threaded / horizontal-split · Log in · Help
February 20, 2012
Re: size_t + ptrdiff_t
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.
February 20, 2012
Re: size_t + ptrdiff_t
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.
February 21, 2012
Re: size_t + ptrdiff_t
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)
February 21, 2012
Re: size_t + ptrdiff_t
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
February 21, 2012
Re: size_t + ptrdiff_t
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.
February 21, 2012
Re: size_t + ptrdiff_t
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.
February 21, 2012
Re: size_t + ptrdiff_t
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.
February 21, 2012
Re: size_t + ptrdiff_t
> 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
February 21, 2012
Re: size_t + ptrdiff_t
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';
February 21, 2012
Re: size_t + ptrdiff_t
> 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?
> 
>
2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home