Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 11, 2005 calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
I am trying to call the C function findfirst. It fills a struct with file information. I have converted the parts of the C header io.h that I believe are required. It links, it runs, it gets garbage. I have attached my code (b.d) and a test done in C (test.c). Running both you can see the address and size of each struct member involved. Anyone know what I am doing wrong? Regan |
April 11, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "Regan Heath" <regan@netwin.co.nz> wrote in message news:opso2eamu423k2f5@nrage.netwin.co.nz... > Anyone know what I am doing wrong? I'm not sure but it may be the align(8) directives. Align takes the number of bytes to align to, not bits. As of now it's aligning the members on 8-byte boundaries! So you'd want to write "align(1)" instead. |
April 11, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | On Mon, 11 Apr 2005 16:53:33 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote: > "Regan Heath" <regan@netwin.co.nz> wrote in message > news:opso2eamu423k2f5@nrage.netwin.co.nz... >> Anyone know what I am doing wrong? > > I'm not sure but it may be the align(8) directives. Align takes the number > of bytes to align to, not bits. As of now it's aligning the members on > 8-byte boundaries! So you'd want to write "align(1)" instead. Tried it, no luck. After posting I looked at the io.h in the dmc.zip (the linker zip for D) from digital mars, it does not contain #pragma pack(push,8) like the MSVC one did, I have tried without align, and with align 1 or 8 it makes no difference. Regan |
April 11, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "Regan Heath" <regan@netwin.co.nz> wrote in message news:opso25soy023k2f5@nrage.netwin.co.nz... > Tried it, no luck. After posting I looked at the io.h in the dmc.zip (the linker zip for D) from digital mars, it does not contain #pragma pack(push,8) like the MSVC one did, I have tried without align, and with align 1 or 8 it makes no difference. Hm. Well I tried running your program, and this is what I got: > Executing: C:\ConTEXT\ConExec.exe "C:\dmd\proj\dtest\run.bat" 4282528 0012fe20 0012fe20 4 0012fe24 4 0012fe28 4 0012fe2c 4 0012fe30 4 0012fe34 260 0 0 0 0 0 (Error: Access Violation The access violation is because you're using %s as the format modifier. Using %.*s, or using data.name.ptr instead makes it work. But then it's just filled with character 255 (default character value). I don't know what to tell you. |
April 11, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | On Mon, 11 Apr 2005 17:27:17 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote: > "Regan Heath" <regan@netwin.co.nz> wrote in message > news:opso25soy023k2f5@nrage.netwin.co.nz... >> Tried it, no luck. After posting I looked at the io.h in the dmc.zip (the >> linker zip for D) from digital mars, it does not contain #pragma >> pack(push,8) like the MSVC one did, I have tried without align, and with >> align 1 or 8 it makes no difference. > > Hm. Well I tried running your program, and this is what I got: > >> Executing: C:\ConTEXT\ConExec.exe "C:\dmd\proj\dtest\run.bat" > > 4282528 > > 0012fe20 > 0012fe20 4 > 0012fe24 4 > 0012fe28 4 > 0012fe2c 4 > 0012fe30 4 > 0012fe34 260 > > 0 > 0 > 0 > 0 > 0 > (Error: Access Violation Yep. That's what I get also. > The access violation is because you're using %s as the format modifier. Which should be correct for a C string. Right? > Using %.*s, or using data.name.ptr instead makes it work. But then it's > just filled with character 255 (default character value). I tried that also. It appears to be treating the char as a D char, not a C char, should I be using byte instead perhaps? Basically it needs to be a fixed size block of memory that is not a D array. > I don't know what to tell you. Well, at least that means I haven't missed something obvious, which is good and bad all at the same time. Hopefully Walter (or someone else) knows what's going on. Regan |
April 12, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "Regan Heath" <regan@netwin.co.nz> wrote in message news:opso27fqem23k2f5@nrage.netwin.co.nz... > I tried that also. It appears to be treating the char as a D char, not a C char, should I be using byte instead perhaps? Basically it needs to be a fixed size block of memory that is not a D array. char[260] is a D char array. It's static, but it still has the same layout as a dynamic char array -- length, then pointer to the data. Thus, you still must use %.*s, or use %s with the .ptr of the array. |
April 12, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | On Mon, 11 Apr 2005 20:52:02 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opso27fqem23k2f5@nrage.netwin.co.nz...
>> I tried that also. It appears to be treating the char as a D char, not a C
>> char, should I be using byte instead perhaps? Basically it needs to be a
>> fixed size block of memory that is not a D array.
>
> char[260] is a D char array. It's static, but it still has the same layout
> as a dynamic char array -- length, then pointer to the data. Thus, you
> still must use %.*s, or use %s with the .ptr of the array.
char[] a;
char[100] b;
char c[100];
I *thought* 'c' was different to 'b'. I guess not.
How do you represent a C array of chars/bytes/ints/longs etc?
The conversion guide says to use "byte" in place of C's "signed char", but the same problem occurs as "byte c[100]" is a D style array, yes?
So that leaves "byte* c". However, this will effect the size of the struct and the C function will write "past the end" of the struct passed to it, right?
I am at a loss...
Regan
|
April 12, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | Regan Heath wrote:
> On Mon, 11 Apr 2005 20:52:02 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opso27fqem23k2f5@nrage.netwin.co.nz...
>>
>>> I tried that also. It appears to be treating the char as a D char, not a C
>>> char, should I be using byte instead perhaps? Basically it needs to be a
>>> fixed size block of memory that is not a D array.
>>
>>
>> char[260] is a D char array. It's static, but it still has the same layout
>> as a dynamic char array -- length, then pointer to the data. Thus, you
>> still must use %.*s, or use %s with the .ptr of the array.
>
>
> char[] a;
> char[100] b;
> char c[100];
>
> I *thought* 'c' was different to 'b'. I guess not.
>
> How do you represent a C array of chars/bytes/ints/longs etc?
>
> The conversion guide says to use "byte" in place of C's "signed char", but the same problem occurs as "byte c[100]" is a D style array, yes?
>
> So that leaves "byte* c". However, this will effect the size of the struct and the C function will write "past the end" of the struct passed to it, right?
>
> I am at a loss...
>
> Regan
I think that you are correct - otherwise things are very broken...
struct A
{
char a[12];
}
int main(char [][]args)
{
printf("sizeof a %i\n", A.sizeof);
}
Gives the expected output of 12, no hidden length marker.
Brad
|
April 12, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to brad | On Tue, 12 Apr 2005 14:29:56 +1200, <brad@domain.invalid> wrote:
> Regan Heath wrote:
>> On Mon, 11 Apr 2005 20:52:02 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opso27fqem23k2f5@nrage.netwin.co.nz...
>>>
>>>> I tried that also. It appears to be treating the char as a D char, not a C
>>>> char, should I be using byte instead perhaps? Basically it needs to be a
>>>> fixed size block of memory that is not a D array.
>>>
>>>
>>> char[260] is a D char array. It's static, but it still has the same layout
>>> as a dynamic char array -- length, then pointer to the data. Thus, you
>>> still must use %.*s, or use %s with the .ptr of the array.
>> char[] a;
>> char[100] b;
>> char c[100];
>> I *thought* 'c' was different to 'b'. I guess not.
>> How do you represent a C array of chars/bytes/ints/longs etc?
>> The conversion guide says to use "byte" in place of C's "signed char", but the same problem occurs as "byte c[100]" is a D style array, yes?
>> So that leaves "byte* c". However, this will effect the size of the struct and the C function will write "past the end" of the struct passed to it, right?
>> I am at a loss...
>> Regan
>
> I think that you are correct - otherwise things are very broken...
> struct A
> {
> char a[12];
> }
>
> int main(char [][]args)
> {
> printf("sizeof a %i\n", A.sizeof);
> }
>
> Gives the expected output of 12, no hidden length marker.
I suspect they're identical. I suspect they're both C type arrays. I suspect the compiler replaces things like "b.length" with the actual length at compile time. I dont think this is related to the original problem.
struct A {
char[] a;
}
struct B {
char[100] b;
}
struct C {
char c[100];
}
int main(char[][] args)
{
char[] a;
char[100] b;
char c[100];
A sa;
B sb;
C sc;
printf("%d %08x %08x\n",a.sizeof,&a,a.ptr);
printf("%d %08x %08x\n",b.sizeof,&b,b.ptr);
printf("%d %08x %08x\n",c.sizeof,&c,c.ptr);
printf("%d\n",sa.sizeof);
printf("%d\n",sb.sizeof);
printf("%d\n",sc.sizeof);
}
Output:
8 0012fd88 00000000
100 0012fd90 0012fd90
100 0012fdf4 0012fdf4
8
100
100
Regan
|
April 12, 2005 Re: calling C functions findfirst etc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "Regan Heath" <regan@netwin.co.nz> wrote in message news:opso2eamu423k2f5@nrage.netwin.co.nz... >I am trying to call the C function findfirst. It fills a struct with file > information. > > I have converted the parts of the C header io.h that I believe are > required. > It links, it runs, it gets garbage. > > I have attached my code (b.d) and a test done in C (test.c). > > Running both you can see the address and size of each struct member involved. > > Anyone know what I am doing wrong? > > Regan Googling for "digitalmars findfirst" turns up some links that indicate the DMC++ version of findfirst isn't like the others. Maybe try "dos_findfirst"? I'm not really sure. Check out dm/include/dos.h for dos_findfirst. |
Copyright © 1999-2021 by the D Language Foundation