Since I've added this call, my program will sometimes but not always either generate a core dump or a seg fault. It seems that the issue is with the const char * parameter.

I don't have a good grasp of the difference between the way D and C work for char * types. The call to loadTexture uses a literal for the file name, i.e. "resources/ball.png".

// d lang bindings for C function
alias void SDL_Renderer;
alias void SDL_Texture;
extern (C) SDL_Texture * IMG_LoadTexture(SDL_Renderer * renderer, const char * file);

// d lang call to extern (C) function
SDL_Texture* loadTexture( SDL_Renderer * ren,  const char * file )
{
	SDL_Texture * loadedImage = IMG_LoadTexture( ren, file );
	return loadedImage;
}

On 10/15/2014 08:18 PM, dysmondad wrote:

> Since I've added this call, my program will sometimes but not always
> either generate a core dump or a seg fault. It seems that the issue is
> with the const char * parameter.
>
> I don't have a good grasp of the difference between the way D and C work
> for char * types. The call to loadTexture uses a literal for the file
> name, i.e. "resources/ball.png".
>
> // d lang bindings for C function
> alias void SDL_Renderer;
> alias void SDL_Texture;
> extern (C) SDL_Texture * IMG_LoadTexture(SDL_Renderer * renderer, const
> char * file);
>
> // d lang call to extern (C) function
> SDL_Texture* loadTexture( SDL_Renderer * ren,  const char * file )
> {
>      SDL_Texture * loadedImage = IMG_LoadTexture( ren, file );
>      return loadedImage;
> }

I wouldn't expect to see strings represented as 'const char *' on D side. The more convenient and safer option is to use 'string' on the D side and pass it through toStringz() before calling C.

The D function now takes 'string' and calls toStringz() on it:

SDL_Texture* loadTexture( SDL_Renderer * ren,  string file )
{
     SDL_Texture * loadedImage = IMG_LoadTexture( ren, file.toStringz);
     return loadedImage;
}

However, note the lifetime issue:

  http://dlang.org/phobos/std_string.html#.toStringz

Ali

On 10/16/2014 12:18 PM, dysmondad wrote:
> Since I've added this call, my program will sometimes but not always
> either generate a core dump or a seg fault. It seems that the issue is
> with the const char * parameter.
>
> I don't have a good grasp of the difference between the way D and C work
> for char * types.

Strings in C are arrays of chars ending with the nul terminator. Strings in D are not required to be nul terminated. String literals in D *are* nul terminated. When passing a string to a C function that takes const char*, use toStringz as Ali showed in his post.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On 10/16/2014 4:54 PM, Mike Parker wrote:
> On 10/16/2014 12:18 PM, dysmondad wrote:
>> Since I've added this call, my program will sometimes but not always
>> either generate a core dump or a seg fault. It seems that the issue is
>> with the const char * parameter.
>>
>> I don't have a good grasp of the difference between the way D and C work
>> for char * types.
>
> Strings in C are arrays of chars ending with the nul terminator. Strings
> in D are not required to be nul terminated. String literals in D *are*
> nul terminated. When passing a string to a C function that takes const
> char*, use toStringz as Ali showed in his post.
>
>
Forgot to mention -- toStringz in std.string will add the nul terminator if it is not already there.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On Thursday, 16 October 2014 at 07:55:24 UTC, Mike Parker wrote:
> On 10/16/2014 4:54 PM, Mike Parker wrote:
>> On 10/16/2014 12:18 PM, dysmondad wrote:
>>> Since I've added this call, my program will sometimes but not always
>>> either generate a core dump or a seg fault. It seems that the issue is
>>> with the const char * parameter.
>>>
>>> I don't have a good grasp of the difference between the way D and C work
>>> for char * types.
>>
>> Strings in C are arrays of chars ending with the nul terminator. Strings
>> in D are not required to be nul terminated. String literals in D *are*
>> nul terminated. When passing a string to a C function that takes const
>> char*, use toStringz as Ali showed in his post.
>>
>>
> Forgot to mention -- toStringz in std.string will add the nul terminator if it is not already there.
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com


Thank you very much. Because of your help, my application has far fewer seg faults and core dumps.

Now, if I can just figure out why the SDL_RenderPresent call is having problems. I suspect that has more to do with the way I'm using the library than the calling convention.