translate-c: C code that uses string literals as non-const char *

[ehaas]

In C string literals have the type char[N] (not const, but modifying the contents is undefined behavior). C code that uses this isn't compatible with Zig's []const u8 string literals:

int main(void) {
   char *foo = "foo";
   return 0;
}

pub export fn main() c_int {
    var foo: [*c]u8 = "foo";
    return 0;
}

./test.zig:3:23: error: expected type '[*c]u8', found '*const [3:0]u8'
    var foo: [*c]u8 = "foo";
                      ^
./test.zig:3:23: note: cast discards const qualifier
    var foo: [*c]u8 = "foo";

This can occur in variable declarations, function calls, and struct and array initializers - did I miss any?

I noticed in getExprQualType we turn char * into const char * but I'm not sure why or what the implications of removing that are. Another solution would be to detect situations where a string literal is used as a char * and insert intToPtr / ptrToInt to cast away the constness.

[nektro]

(not const, but modifying the contents is undefined behavior)

then what exactly non-const about them?

[ehaas]

They're effectively const; It's just that it's a quirk of the C standard that string literals have the type char *, so the technically correct Zig type corresponding to a C string literal would be [N:0]i8 or [N:0]u8 depending on platform char signedness. The other issue is that Zig string literals are const, so the following valid C code can't be translated (since a string literal can't coerce to [*c]u8):

#include <stdlib.h>
char foo(char *s) {
    return s[0];
}
int main(void) {
    if (foo("bar") != 'b') abort();
}

[nektro]

are they able to coerce to a [*c]const u8

[ehaas]

Yes, but we can't change the signature of foo since it could theoretically change the string (if it is called with an non-const array or heap-allocated string)