As long as a warning system is being worked on, it'd be nice if the compiler let
me know if I was passing in a char[] for a char* argument to an extern
(C) function.

I just ran into this doing some DerelictSDL programming.  Very strange bug, and I didn't notice it since I was so convinced I was writing "Super C" code. :-) Forgot about toStringz().

Regards,
James Dunne

James Dunne wrote:

> As long as a warning system is being worked on, it'd be nice if the compiler let
> me know if I was passing in a char[] for a char* argument to an extern (C) function.

Unless it's a string literal, right ? Since those are 0-terminated in D,
and since you would get a ton* of warnings when using C stuff otherwise.

--anders

* well, mostly from printf probably, but as long as that is in object...

char [] used to be automatically converted to char* when passing them to functions which expect char *.  I think still ?

Charlie

"James Dunne" <jdunne4@bradley.edu> wrote in message news:d0m54o$1do0$1@digitaldaemon.com...
> As long as a warning system is being worked on, it'd be nice if the
compiler let
> me know if I was passing in a char[] for a char* argument to an extern
> (C) function.
>
> I just ran into this doing some DerelictSDL programming.  Very strange
bug, and
> I didn't notice it since I was so convinced I was writing "Super C" code.
:-)
> Forgot about toStringz().
>
> Regards,
> James Dunne

The idea is, if you have a function:

extern (C) void f(char* text);

And you pass it a string, like so:

f(char_array);

You may be doing this in error; it may be that you wanted to use:

f(toStringz(char_array));

Or similar.  Personally, I think this is unnecessary.  If I was really worried, I'd write a wrapper (which better be inlined!!) to toStringz() it and take a char[] array anyway, but only if I were so worried.

-[Unknown]


> char [] used to be automatically converted to char* when passing them to
> functions which expect char *.  I think still ?
> 
> Charlie

Charles wrote:
> char [] used to be automatically converted to char* when passing them to
> functions which expect char *.  I think still ?
<snip>

Therein lies the problem.  It's too easy to pass a non-null-terminated string to a C function.

I've just been reminded of this....

----------
These two strings walk into a bar and sit down. The bartender says, "So what'll it be?"

The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu"

"Please excuse my friend," the second string says, "He isn't null-terminated."
----------

But it predates D by about nine years :-(

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Unknown W. Brackets wrote:

>> char [] used to be automatically converted to char* when passing them to
>> functions which expect char *.  I think still ?

> The idea is, if you have a function:
> 
> extern (C) void f(char* text);

The usual example here being the venerable printf,
which gets passed D string literals (that are char[])
which Walter likes so much that it goes in object.d,
and other such C functions from the C standard library

And to make these easier to use, char[] can be converted
automatically to char* and they are declared as "char*"
instead of as ubyte* or byte* which would be the *proper*
declaration unless they really accept UTF-8 code units...

Otherwise, calling C functions would be quite a hassle ?
(which could arguably be a good thing, promoting writef)

> And you pass it a string, like so:
> 
> f(char_array);

If you really *want* to do this, you should probably
use char_array.ptr which is a neat way to access it ?

Makes it clear that you want to get at the raw data,
and will worry about any zero-termination yourself.

 > You may be doing this in error; it may be that you wanted to use:
> 
> f(toStringz(char_array));

Which would probably be the most safe approach, too...
(explicitly doing a ~ "\0", like that std routine does)

Or you could use char_array.length and char_array.ptr,
like the "%.*s" approach to printf does (implicitly) ?

--anders