December 20, 2015 Re: Problems with string literals and etc.c.odbc.sql functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Saturday, 19 December 2015 at 17:30:02 UTC, Kagamin wrote:
> On Saturday, 19 December 2015 at 13:20:03 UTC, Marc Schütz wrote:
>> As this is going to be passed to a C function
>
> No, ODBC API is designed with multilingual capability in mind, it doesn't rely on null terminated strings heavily: all string arguments support length specification.
Nice, then SQL_NTS means "null terminated string" and should be replaced by `mystring.length`...
|
December 20, 2015 Re: Problems with string literals and etc.c.odbc.sql functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to anonymous | On Saturday, 19 December 2015 at 14:16:36 UTC, anonymous wrote:
> On 19.12.2015 14:20, Marc Schütz wrote:
>> As this is going to be passed to a C function, it would need to be
>> zero-terminated. `.dup` doesn't do this, he'd have to use
>> `std.string.toStringz` instead. However, that function returns a
>> `immutable(char)*`, which would have to be cast again :-(
>
> Ouch, I totally missed that. Looks like we don't have a nice way to do this then?
I guess so. Theoretically, we could change `toStringz()` to return `char*`; if its result is unique (we would have to change the implementation to always make a copy), it should then be implicitly convertible to `immutable(char)*`. But that would break code, because it could have been used like `auto s = "xyz".toStringz;`, where `s` would then have a different type. So, there'd need to be an additional function, `toMutableStringz`.
|
Copyright © 1999-2021 by the D Language Foundation