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

"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.

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

"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.

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

"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.

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

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

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

"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.