{"id":2385,"date":"2020-04-28T14:22:53","date_gmt":"2020-04-28T14:22:53","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=2385"},"modified":"2021-09-30T13:36:27","modified_gmt":"2021-09-30T13:36:27","slug":"interfacing-d-with-c-arrays-and-functions-arrays-part-two","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2020\/04\/28\/interfacing-d-with-c-arrays-and-functions-arrays-part-two\/","title":{"rendered":"Interfacing D with C: Arrays and Functions (Arrays Part 2)"},"content":{"rendered":"

\"Digital<\/p>\n

This post is part of an ongoing series<\/a> on working with both D and C in the same project. The previous post explored the differences<\/a> in array declaration and initialization. This post takes the next step: declaring and calling C functions that take arrays as parameters.<\/p>\n

Arrays and C function declarations<\/h2>\n

Using C libraries in D is extremely easy. Most of the time, things work exactly as one would expect, but as we saw in the previous article there can be subtle differences. When working with C functions that expect arrays, it’s necessary to fully understand these differences.<\/p>\n

The most straightforward and common way of declaring a C function that accepts an array as a parameter is to to use a pointer in the parameter list. For example, this hypothetical C function:<\/p>\n

void f0(int *arr);<\/pre>\n
In C, any array of int<\/code> can be passed to this function no matter how it was declared. Given int a[]<\/code>, int b[3]<\/code>, or int *c<\/code>, the function calls f0(a)<\/code>, f0(b)<\/code>, and f0(c)<\/code> are all the same: a pointer to the first element of each array is passed to the function. Or using the lingo of C programmers, arrays decay<\/em> to pointers<\/p>\n
Typically, in a function like f0<\/code>, the implementer will expect the array to have been terminated with a marker appropriate to the context. For example, strings in C are arrays of char<\/code> that are terminated with the \\0<\/code> character (we’ll look at D strings vs. C strings in a future post). This is necessary because, without that character, the implementation of f0<\/code> has no way to know which element in the array is the last one. Sometimes, a function is simply documented to expect a certain length, either in comments or in the function name, e.g., a vector3f_add(float *vec)<\/code> will expect that vec<\/code> points to exactly 3 elements. Another option is to require the length of the array as a separate argument:<\/p>\n
void f1(int *arr, size_t len);<\/pre>\n
None of these approaches is foolproof. If f0<\/code> receives an array with no end marker or which is shorter than documented, or if f1<\/code> receives an array with an actual length shorter than len<\/code>, then the door is open for memory corruption. D arrays take this possibility into account, making it much easier to avoid such problems. But again, even D’s safety features aren’t 100% foolproof when calling C functions from D.<\/p>\n
There are other, less common, ways array parameters may be declared in C:<\/p>\n
void f2(int arr[]);\nvoid f3(int arr[9]);\nvoid f4(int arr[static 9]);<\/pre>\n
Although these parameters are declared using C’s array syntax, they boil down to the exact same function signature as f0<\/code> because of the aforementioned pointer decay. The [9]<\/code> in f3<\/code> triggers no special enforcement by the compiler; arr<\/code> is still effectively a pointer to int<\/code> with unknown length. The [9]<\/code> serves as documentation of what the function expects, and the implementation cannot rely on the array having nine elements.<\/p>\n
The only potential difference is in f4<\/code>. The static<\/code> added to the declaration tells the compiler that the function must take an array of, in this case, at least<\/em> nine elements. It could have more than nine, but it can’t have fewer. That also rules out null pointers. The problem is, this isn’t necessarily enforced. Depending on which C compiler you use, if you shortchange the function and send it less than nine elements you might see warnings if they are enabled, but the compiler might not complain at all. (I haven’t tested current compilers for this article to see if any are actually reporting errors for this, or which ones provide warnings.)<\/p>\n
The behavior of C compilers doesn’t matter from the D side. All we need be concerned with is declaring these functions appropriately so that we can call them from D such that there are no crashes or unexpected results. Because they are all effectively the same, we could declare them all in D like so:<\/p>\n
extern(C):\nvoid f0(int* arr);\nvoid f1(int* arr, size_t len);\nvoid f2(int* arr);\nvoid f3(int* arr);\nvoid f4(int* arr);<\/pre>\n
But just because we can do a thing doesn’t mean we should. Consider these alternative declarations of f2<\/code>, f3<\/code>, and f4<\/code>:<\/p>\n
extern(C):\nvoid f2(int[] arr);\nvoid f3(int[9] arr);\nvoid f4(int[9] arr);<\/pre>\n
Are there any consequences of taking this approach? The answer is yes, but that doesn’t mean we should default to int*<\/code> in each case. To understand why, we need first to explore the innards of D arrays.<\/p>\n
The anatomy of a D array<\/h2>\n
The previous article showed that D makes a distinction between dynamic and static arrays:<\/p>\n
int[] a0;\nint[9] a1;<\/pre>\n
a0<\/code> is a dynamic array and a1<\/code> is a static array. Both have the properties .ptr<\/code> and .length<\/code>. Both may be indexed using the same syntax. But there are some key differences between them.<\/p>\n
Dynamic arrays<\/h3>\n
Dynamic arrays are usually allocated on the heap (though that isn’t a requirement). In the above case, no memory for a0<\/code> has been allocated. It would need to be initialized with memory allocated via new<\/code> or malloc<\/code>, or some other allocator, or with an array literal. Because a0<\/code> is uninitialized, a0.ptr<\/code> is null<\/code> and a0.length<\/code> is 0<\/code>.<\/p>\n
A dynamic array in D is an aggregate type that contains the two properties as members. Something like this:<\/p>\n
struct DynamicArray {\n    size_t length;\n    size_t ptr;\n}<\/pre>\n
In other words, a dynamic array is essentially a reference type, with the pointer\/length pair serving as a handle that refers to the elements in the memory address contained in the ptr<\/code> member. Every built-in D type has a .sizeof<\/code> property, so if we take a0.sizeof<\/code>, we’ll find it to be 8<\/code> on 32-bit systems, where size_t<\/code> is a 4-byte uint<\/code>, and 16<\/code> on 64-bit systems, where size_t<\/code> is an 8-byte ulong<\/code>. In short, it’s the size of the handle and not the cumulative size of the array elements.<\/p>\n
Static arrays<\/h3>\n
Static arrays are generally allocated on the stack. In the declaration of a1<\/code>, stack space is allocated for nine int<\/code> values, all of which are initialized to int.init<\/code> (which is 0<\/code>) by default. Because a1<\/code> is initialized, a1.ptr<\/code> points to the allocated space and a1.length<\/code> is 9<\/code>. Although these two properties are the same as those of the dynamic array, the implementation details differ.<\/p>\n
A static array is a value type, with the value being all of its elements<\/em>. So given the declaration of a1<\/code> above, its nine int<\/code> elements indicate that a1.sizeof<\/code> is 9 * int.sizeof<\/code>, or 36<\/code>. The .length<\/code> property is a compile-time constant that never changes, and the .ptr<\/code> property, though not readable at compile time, is also a constant that never changes (it’s not even an lvalue, which means it’s impossible to make it point somewhere else).<\/p>\n
These implementation details are why we must pay attention when we cut and paste C array declarations into D source modules.<\/p>\n
Passing D arrays to C<\/h2>\n
Let’s go back to the declaration of f2<\/code> in C and give it an implementation:<\/p>\n
void f2(int arr[]) {\n    for(int i=0; i<3; ++i)\n        printf("%d\\n", arr[i]);\n}<\/pre>\n
A na\u00efve declaration in D:<\/p>\n
extern(C) void f2(int[]);\n\nvoid main() {\n    int[] a = [10, 20, 30];\n    f2(a);\n}<\/pre>\n
I say na\u00efve because this is never the right answer. Compiling f2.c<\/code> with df2.d<\/code> on Windows (cl \/c f2.c<\/code> in the “x64 Native Tools” command prompt for Visual Studio, followed by dmd -m64 df2.d f2.obj<\/code>), then running df2.exe<\/code>, shows me the following output:<\/p>\n
3\n0\n1970470928<\/pre>\n
There is no compiler error because the declaration of f2<\/code> is pefectly valid D. The extern(C)<\/code> indicates that this function uses the cdecl<\/code> calling convention. Calling conventions affect the way arguments are passed to functions and how the function’s symbol is mangled. In this case, the symbol will be either _f2<\/code> or f2<\/code> (other calling conventions, like stdcall<\/code>—extern(Windows)<\/code> in D—have different mangling schemes). The declaration still has to be valid D. (In fact, any D function can be marked as extern(C)<\/code>, something which is necessary when creating a D library that will be called from other languages.)<\/p>\n
There is also no linker error. DMD is calling out to the system linker (in this case, Microsoft’s link.exe<\/code>), the same linker used by the system’s C and C++ compilers. That means the linker has no special knowledge about D functions. All it knows is that there is a call to a symbol, f2<\/code> or _f2<\/code>, that needs to be linked with the implementation. Since the type and number of parameters are not mangled into the symbol name, the linker will happily link with any matching symbol it finds (which, by the way, is the same thing it would do if a C program tried to call a C function which was declared with an incorrect parameter list).<\/p>\n
The C function is expecting a single pointer as an argument, but it’s instead receiving two values: the array length followed by the array pointer.<\/p>\n
The moral of this story is that any C function with array parameters declared using array syntax, like int[]<\/code>, should be declared to accept pointers in D. Change the D source to the following and recompile using the same command line as before (there’s no need to recompile the C file):<\/p>\n
extern(C) void f2(int*);\n\nvoid main() {\n    int[] a = [10, 20, 30];\n    f2(a.ptr);\n}<\/pre>\n
Note the use of a.ptr<\/code>. It’s an error to try to pass a D array argument where a pointer is expected (with one very special exception, string literals, which I’ll cover in the next article in this series), so the array’s .ptr<\/code> property must be used instead.<\/p>\n
The story for f3<\/code> and f4<\/code> is similar:<\/p>\n
void f3(int arr[9]);\nvoid f4(int arr[static 9]);<\/pre>\n
Remember, int[9]<\/code> in D is a static array, not a dynamic array. The following do not match the C declarations:<\/p>\n
void f3(int[9]);\nvoid f4(int[9]);<\/pre>\n
Try it yourself. The C implementation:<\/p>\n
void f3(int arr[9]) {\n    for(int i=0; i<9; ++i)\n        printf("%d\\n", arr[i]);\n}<\/pre>\n
And the D implementation:<\/p>\n
extern(C) void f3(int[9]);\n\nvoid main() {\n    int[9] a = [10, 20, 30, 40, 50, 60, 70, 80, 90];\n    f3(a);\n}<\/pre>\n
This is likely to crash, depending on the system. Rather than passing a pointer to the array, this code is instead passing all nine array elements by value! Now consider a C library that does something like this:<\/p>\n
typedef float[16] mat4f;\nvoid do_stuff(mat4f mat);<\/pre>\n
Generally, when writing D bindings to C libraries, it’s a good idea to keep the same interface as the C library. But if the above is translated like the following in D:<\/p>\n
alias mat4f = float[16];\nextern(C) void do_stuff(mat4f);<\/pre>\n
The sixteen floats will be passed to do_stuff<\/code> every time it’s called. The same for all functions that take a mat4f<\/code> parameter. One solution is just to do the same as in the int[]<\/code> case and declare the function to take a pointer. However, that’s no better than C, as it allows the function to be called with an array that has fewer elements than expected. We can’t do anything about that in the int[]<\/code> case, but that will usually be accompanied by a length parameter on the C side anyway. C functions that take typedef’d types like mat4f<\/code> usually don’t have a length parameter and rely on the caller to get it right. <\/p>\n
In D, we can do better:<\/p>\n
void do_stuff(ref mat4f);<\/pre>\n
Not only does this match the API implementor’s intent, the compiler will guarantee that any arrays passed to do_stuff<\/code> are static float arrays with 16 elements. Since a ref<\/code> parameter is just a pointer under the hood, all is as it should be on the C side.<\/p>\n
With that, we can rewrite the f3<\/code> example:<\/p>\n
extern(C) void f3(ref int[9]);\n\nvoid main() {\n    int[9] a = [10, 20, 30, 40, 50, 60, 70, 80, 90];\n    f3(a);\n}<\/pre>\n
Conclusion<\/h3>\n
Most of the time, when interfacing with C from D, the C API declarations and any example code can be copied verbatim in D. But most of the time<\/em> is not all of the time<\/em>, so care must be taken to account for those exceptional cases. As we saw in the previous article, carelessness when declaring array variables can usually be caught by the compiler. As this article shows, the same is not the case for C function declarations. Interfacing D with C requires the same care as when writing C code.<\/p>\n
In the next article in this series, we’ll look at mixing D strings and C strings in the same program and some of the pitfalls that may arise. In the meantime, Steven Schveighoffer’s excellent article, “D Slices”, is a great place to start<\/a> for more details about D arrays.<\/p>\n
Thanks to Walter Bright and \u00c1tila Neves for their valuable feedback on this article.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
This post is part of an ongoing series on working with both D and C in the same project. The previous post explored the differences in array declaration and initialization. This post takes the next step: declaring and calling C functions that take arrays as parameters. Arrays and C function declarations Using C libraries in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[26,29,30],"tags":[],"_links":{"self":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/2385"}],"collection":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/comments?post=2385"}],"version-history":[{"count":24,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/2385\/revisions"}],"predecessor-version":[{"id":2863,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/2385\/revisions\/2863"}],"wp:attachment":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/media?parent=2385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/categories?post=2385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/tags?post=2385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}