On Saturday, 18 September 2021 at 21:16:13 UTC, frame wrote:

Error: cannot implicitly convert expression strchr(e, cast(int)c) of type const(char)* to char*

But I guess it's because it tries to assign to a char* therefore inout() doesn't work.

On 9/18/21 5:20 PM, frame wrote:

Error: cannot implicitly convert expression strchr(e, cast(int)c) of type const(char)* to char*

Well, the variable you are assigning it to should be a const char * if the source variable is a const char *.

Possibly, the C code didn't mark it as const char *, because I'm pretty sure C has strchr being:

char * strchr(const char *, int)

Because, you know, const doesn't matter in C ;)

If that doesn't work, then you may need to start allocating. But I'd try that first.

-Steve

On 9/18/21 5:16 PM, frame wrote:

So here is why you need a cast:

First, the code is doing math on 2 pointers, which returns a ptrdiff_t, a.k.a. long in 64-bits.

Second, you are using mod 40, which is great, because D will recognize that the range of values must be within 40!

However, since it's signed, that's -40 to 40. Which doesn't fit in a char (which is unsigned).

D does not allow an implicit narrowing conversion. Since -40 to -1 won't fit into a char (dubious anyway for char to be an integer IMO), you need a cast.

So my recommendation is shoehorn it into ulong to take away the sign before the mod, or cast to char at the end. Is there any chance that w is less than e? if so, do NOT use the first option.

// option 1
output[p++] = (ulong(w - e) + 3) % 40;
// option 2
output[p++] = cast(char)(((w - e) + 3) % 40);

Remember also, char is C's only way to say "byte". So this may just be data, and not unicode data. You may want to consider using ubyte in your translation instead of char. But wait until your code is compiling and working as it did in C.

-Steve

On Sunday, 19 September 2021 at 02:18:20 UTC, Steven Schveighoffer wrote:

// option 1
output[p++] = (ulong(w - e) + 3) % 40;
// option 2
output[p++] = cast(char)(((w - e) + 3) % 40);

Thanks again, good to know how D sees things.
That data is indeed meant to be raw bytes.

Option 2 seems to be always the most reliable one and that kind of casts are the only one I did in first place ;-)