www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ABI array format

reply Kenny B <funisher gmail.com> writes:
Commonly in C API's you will see something of the following:

size_t byte_chr(void* haystack, size_t len, char needle);

or

uint mc_hash(memcache *mc, char *key, size_t len);

I have never seen the pointer and length in reverse order. Why then, is
the ABI for the arrays in reverse order...

(length, pointer)

I know this is a real long shot, but it'd be super awesome (and also
break every %.*s in printf, if those were reversed). I could rewrite
those API's to be

size_t byte_chr(void* haystack, string needle);

uint mc_hash(memcache *mc, string key);

and it'd be about 500 times more awesome.

Thanks for listening,
Kenny
Dec 19 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Kenny B wrote:

 Commonly in C API's you will see something of the following:
 
 size_t byte_chr(void* haystack, size_t len, char needle);
 
 or
 
 uint mc_hash(memcache *mc, char *key, size_t len);
 
 I have never seen the pointer and length in reverse order. Why then, is
 the ABI for the arrays in reverse order...
 
 (length, pointer)
 
 I know this is a real long shot, but it'd be super awesome (and also
 break every %.*s in printf, if those were reversed). I could rewrite
 those API's to be
 
 size_t byte_chr(void* haystack, string needle);
 
 uint mc_hash(memcache *mc, string key);
 
 and it'd be about 500 times more awesome.



Correct me if I'm wrong but the ABI for arrays is not set in concrete by 
the D specification.  Therefore any code which relies on the ABI of 
arrays is inherently a little bit evil.

I believe there was a proposal to change the ABI for arrays to:
   (start pointer, end pointer)

Something to do with iterator support, I have only a vague idea.  This 
change will kill the printf thing and also what you want to do above.

Regan
Dec 19 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Regan Heath wrote:

 Correct me if I'm wrong but the ABI for arrays is not set in concrete by 
 the D specification.  Therefore any code which relies on the ABI of 
 arrays is inherently a little bit evil.



Luckily the D specs didn't make the same mistake as the C++ specs did by 
*not* specifying the ABI: http://www.digitalmars.com/d/abi.html
Dec 19 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Jascha Wetzel wrote:

 Regan Heath wrote:

 Correct me if I'm wrong but the ABI for arrays is not set in concrete 
 by the D specification.  Therefore any code which relies on the ABI of 
 arrays is inherently a little bit evil.



 Luckily the D specs didn't make the same mistake as the C++ specs did by 
 *not* specifying the ABI: http://www.digitalmars.com/d/abi.html



Shows what I know. <g>
Thanks.
Dec 19 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Jascha Wetzel wrote:

 Regan Heath wrote:

 Correct me if I'm wrong but the ABI for arrays is not set in concrete 
 by the D specification.  Therefore any code which relies on the ABI of 
 arrays is inherently a little bit evil.



 Luckily the D specs didn't make the same mistake as the C++ specs did by 
 *not* specifying the ABI: http://www.digitalmars.com/d/abi.html



Now if only GDC complied to the D ABI :-)

By the way, the ABI really should be expanded to encompass x86-64 and 
ideally exception handling as well.  As it is, the ABI really isn't 
sufficient to allow code built by one compiler to be linked to code 
built by another compiler, which is really the point of an ABI, isn't it?


Sean
Dec 19 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Sean Kelly wrote:

 Now if only GDC complied to the D ABI :-)
 
 By the way, the ABI really should be expanded to encompass x86-64 and 
 ideally exception handling as well.  As it is, the ABI really isn't 
 sufficient to allow code built by one compiler to be linked to code 
 built by another compiler, which is really the point of an ABI, isn't it?



indeed, maybe when llvmdc gets to the next level, this topic becomes 
more relevant, especially x86-64.
Dec 20 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kenny B wrote:

 Why then, is
 the ABI for the arrays in reverse order...
 
 (length, pointer)



It was so you could pass a D string to printf and print using the %.*s 
format.
Dec 19 2007
next sibling parent reply Kenny B <funisher gmail.com> writes:
Walter Bright wrote:

 Kenny B wrote:

 Why then, is
 the ABI for the arrays in reverse order...

 (length, pointer)



 It was so you could pass a D string to printf and print using the %.*s
 format.



that's what I figured. printf has almost completely been phased out. is
it possible that this format can be reversed when printf is a thing from
the past?

Thanks man,
Kenny
Dec 19 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kenny B wrote:

 Walter Bright wrote:

 Kenny B wrote:

 Why then, is
 the ABI for the arrays in reverse order...

 (length, pointer)



 format.



 that's what I figured. printf has almost completely been phased out. is
 it possible that this format can be reversed when printf is a thing from
 the past?



I recommend treating array contents as an opaque type, and call the C 
functions using array.ptr and array.length. That way, you'll be insured 
against implementation changes.
Dec 19 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:

 On 12/20/07, Walter Bright <newshound1 digitalmars.com> wrote:

 I recommend treating array contents as an opaque type, and call the C
 functions using array.ptr and array.length. That way, you'll be insured
 against implementation changes.



 Obviously, I agree with that. But...
 
 I recommend changing the documentation on
 http://www.digitalmars.com/d/abi.html, which states in black and white
 not only that the layout is not opaque, but tells you what's inside
 it. Folk can hardly be blamed for relying on that.



ABIs are for things like link compatibility between implementations.
Dec 19 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/20/07, Walter Bright <newshound1 digitalmars.com> wrote:

 I recommend treating array contents as an opaque type, and call the C
 functions using array.ptr and array.length. That way, you'll be insured
 against implementation changes.



Obviously, I agree with that. But...

I recommend changing the documentation on
http://www.digitalmars.com/d/abi.html, which states in black and white
not only that the layout is not opaque, but tells you what's inside
it. Folk can hardly be blamed for relying on that.
Dec 19 2007