Writing to readonly data gives SIGBUS error; should be CT error instead

[mratsim]

While wrapping a C library and trying to understand why it could write to ptr char but segfaulted when I asked it to write to (var) cstring, I came upon the following issue:

var x: cstring = "0123456789"
x[1] = 'A' # SIGBUS: Illegal storage access. (Attempt to read from nil?)

echo x

import typetraits
echo x.type.name

Note that this is a SIGBUS (accessing unaddressable memory) not a SIGSEGV (accessing unauthorized memory).

[mratsim]

Tagging @yglukhov, in C we can reproduce it with:

int main(int argc, char **argv)
{
    char* s = "0123456789";
    s[0] = 'c';
    return 0;
}

which points to constant memory in the executable

and it can be fixed by using

int main(int argc, char **argv)
{
    char s[10] = "0123456789";
    s[0] = 'c';
    return 0;
}

[Bulat-Ziganshin]

It may be related to #8370 - Nim doesn't distinguish char * and const char *, so it can try to write into constant C strings. The "solution", indeed, is to make all Nim literal strings mutable, i.e. "123" Nim string constant should be declared as char str[] = "123" rather than erroneous char* str = "123" (for the later, modern C++ compilers complain that you assign const char * to char*).

[mratsim]

I think we can just distinguish between const/let literals and var cases for cstring. This would avoid unnecessary runtime allocation.

[Bulat-Ziganshin]

I don't have an idea whether and to which extent it's possible. I explained here that while we have let/const on higher level, we can't include such fields into structures, so the protection may be leaky. But it's just a wild assumption from general theoretical viewpoint :)

At least, compiler writers will need to check how their final solution plays with deeper object hierarchies.

[Araq]

I don't think there is anything to fix here, cstring literals are read-only.

[ghost]

@Araq Give a better error message than SIGBUS?

[Araq]

SIBGUS vs SIGSEGV is just a OSX thing and custom signal handlers for nicer error messages cause more problems than they solve. cstring is for C interop, sharp edges.

[timotheecour]

I don't think there is anything to fix here, cstring literals are read-only.

there should be a CT error, it should be illegal to write to rodata

I was going to file an issue but I searched and found this. Here's another example, same root cause:

const a = "abc"
var x = a.cstring
x[0]='t' # SIGBUS: Illegal storage access.

This is related also to nim-lang/RFCs#126 (comment):

D distinguishes between enum a = expr;: enum creates a compile-time only construct; it has no address; pretty close to nim's const a = expr
static const a = new Foo(): this computes at CT as well but puts in the static data segment, and has an address you can access at runtime. in nim, that'd be the analog, for example, of let a = "foo".cstring, which puts "foo" in the data segment as readonly memory

and solving this issue properly would enable default values for object properties with safe semantics even for ptr-like types, among other things.

There should be a storage class to represent rodata, and prevent write access at CT. How exactly to do that needs to be determined but this problem is solvable (and other languages, eg D, handle this aspect well).

I have a concrete proposal in mind but no RFC yet, that would work not only for this problem but also for escape analysis (for first class openarrays)

note

a simpler fix might be possible by using C arrays (char[]) instead of c string litterals in cgen, but this might have performance implications; EDIT: this would prevent returning a cstring from a proc, as it'd allocate on stack, so it's not a viable alternative in most cases

related

• [WIP] [RFC] Nim should have immutable type qualifier (let is more like C++'s const); it would enable a new string class design, etc · Issue #8370 · nim-lang/Nim
• Support default values for object properties · Issue #126 · nim-lang/RFCs
• Write tracking for Nim
• D enum vs static const

[Araq]

there should be a CT error, it should be illegal to write to rodata

There is no bug here. Let's keep this closed please. If some RFC gets accepted that improves the situation, that's fine, but with the current spec it is not a bug the compiler needs to detect.

[timotheecour]

this could be fixed by timotheecour#524