Comments (23)
Could you give an example that reproduces this bug? E.g. a code snippet with the problematic types?
from dstep.
An example is converting a function like this:
int gsl_dft_complex_forward (const double data[], const size_t stride, const size_t n, double result[]);
The output you get is this:
int gsl_dft_complex_forward (<unimplemented> data, const size_t stride, const size_t n, <unimplemented> result);
from dstep.
Works for me on master. Very likely that I have accientally fixed it as a side effect of a35b6ea
from dstep.
Works for me on master. Very likely that I have accientally fixed it as a side effect of a35b6ea
On master it converts:
int func (const double data[], double result[]);
to
int func (const double[] data, double[] result);
@Dicebot, @dataPulverizer
Is it correct? Shouldn't it convert the C-arrays to pointers. I suppose D-arrays are slightly different, as there is a way to get the length of the array...
from dstep.
@ciechowoj, yes I think it needs to translate the C arrays to pointers. A D array is twice as large as a pointer (the extra length as you mentioned).
from dstep.
Yep: https://dlang.org/spec/interfaceToC.html#passing_d_array
from dstep.
I'm trying to fix this, don't you know what the following comment from dstep/translatorType.d
means?
// extern static arrays (which are normally present in bindings)
// have same ABI as extern dynamic arrays, size is only checked
// against declaration in header. As it is not possible in D
// to define static array with ABI of dynamic one, only way is to
// abandon the size information
return elementType ~ "[]";
from dstep.
It is an old comment from me and I think it is wrong - I didn't know at the time of writing it that ref T[42]
will use same ABI as T[42]
in C. Of course it likely should have used *
instead of []
anyway as mentioned by @jacob-carlborg
from dstep.
(but original use case I had was for global extern variables, not for function parameters - please check if ABI is different there)
from dstep.
Hmm, I do not know at the moment how to check it other way than experimentally.
Compiled with gcc -c lib.c && dmd test.d lib.o && ./test
// lib.c
const int tab[] = {
42,
42,
24
};
Segmentation fault.
// test.d
extern (C) extern __gshared const (int)[] tab;
int main()
{
import std.stdio;
writeln(tab[0]);
return 0;
}
Segmentation fault.
// test.d
extern (C) extern __gshared const (int)* tab;
int main()
{
import std.stdio;
writeln(tab[0]);
return 0;
}
42
// test.d
extern (C) extern __gshared const (int)[3] tab;
int main()
{
import std.stdio;
writeln(tab[0]);
return 0;
}
It seems like the only way to translate this is to compute the size of an array somehow during translation...
from dstep.
Hmm, worse if the array is declared with extern
already in the header file...
extern const int tab[];
from dstep.
On forum.dlang they suggested to declare an one element array instead.
https://forum.dlang.org/post/[email protected]
from dstep.
What if you make it a pointer?
from dstep.
Sorry for my silence on this I think the conversion const T[]
to const (T)* x
is the right thing to do. The Case of the global variable is an edge case that should probably be put in the readme file to make users aware of this issue. Anyway global variables like that are seriously NASTY!
from dstep.
What if you make it a pointer?
Segmentation fault.
// test.d
extern (C) extern __gshared const (int)* tab;
int main()
{
import std.stdio;
writeln(tab[0]);
return 0;
}
from dstep.
Hm, how about extern (C) extern __gshared const int[0] tab
? With some luck it may behave thesame as variadic length struct trick.
from dstep.
Hm, how about extern (C) extern __gshared const int[0] tab? With some luck it may behave the same as variadic length struct trick.
dmd
will not allow you to access directly, statically checking bounds, warning that the array is too short. On the forum I got an advice to use length 1, but there is the same issue with element access. The workaround is to use .ptr
for indexing, e.g. tab.ptr[42]
.
from dstep.
I suppose we could fix it for the time being by declaring an array with 0 or 1 length.
from dstep.
Is this something that needs fixing in D itself? Is the inability to consistently allow the replacement of const T x[]
with const (T)* x
not a bug?
from dstep.
@dataPulverizer sounds like a bug to me.
from dstep.
Is this something that needs fixing in D itself? Is the inability to consistently allow the replacement of const T x[] with const (T)* x not a bug?
@dataPulverizer sounds like a bug to me.
Just for curiosity, do you have an idea how it could be correctly solved/handled in D?
from dstep.
@ciechowoj nothing at all comes to mind
from dstep.
Not sure if it's related. On OS X, DMD outputs the extern
variable to __textcoal_nt
section while compiling the C code, Clang outputs the extern
variable to the __text
section.
from dstep.
Related Issues (20)
- `--normalize-modules` insert underscore in the module decl but not in the filename
- typedef function prototypes don't retain arguments HOT 5
- dub run failure - ld cannot find @linker_flags.txt HOT 4
- doc error:
- Missing import HOT 2
- Unhandled type kind objCTypeParam HOT 2
- const T arr[] gets converted to imcompatible const(T) *arr instead of a warning HOT 2
- Improper output when importing core.stdc.limits HOT 1
- Rename enum members can create invalid enum names HOT 1
- API macro erased but should be extern(System) HOT 2
- /usr/include/cuda_runtime_api.h ==> d: Error: undefined identifier `cudaError_t` HOT 6
- Assertion Failure when defining a cast from int to function pointer
- Unhandled type kind objCObject when trying to bind Foundation.framework on macOS
- enh? add enum alias (as dpp do) HOT 1
- unknown type name 'size_t' HOT 1
- `--alias-enum-members=true` shouldn't affect global anonymous enums
- Unnecessary leading dot in alias
- Add support for adding public imports
- Missing `__u/int128` support HOT 13
- How to use dstep generate PostgreSQL & MySQL binding? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dstep.