On this line, you are assigning const char* (everything between "'s) to a char* (elements of a).
So when you try to modify something at a you are trying to modify a const char* indirectly. Because this constant data ("asd", "QWE", etc.) is stored in a special read-only section in memory you are getting a segmentation fault.
Because this constant data ("asd", "QWE", etc.) is stored in a special read-only section in memory you are getting a segmentation fault.
Just a clarification: String literals may be stored in read-only memory. Borland compilers in particular have historically allowed modification of string literals due to not storing the string in read-only memory. The reason the standard allows them to be read-only is twofold:
Compiler writers have the option of placing string literals in a more convenient part of the object file for constant data.
For space saving purposes, string literals with the same contents may point to the same underlying array object.
The provision for allowing read-only string literals is indirect though. The standard says that attempts to modify a shared string literal are undefined, which implies #2 and to a lesser extent #1 since it's a logical precursor to #2.
However, the standard uses tricky wording. It's unspecified whether the array pointed to by a string literal is unique, and an attempt to modify the array invokes undefined behavior, but it's not entirely clear if the undefined behavior is conditional upon the array being shared (though that's my preferred interpretation).
In strictly portable code, it's best practice to assume the most restrictive storage of string literals and treat them as both shared and read-only.
So what do you do then if you want to use a string literal, then guarantee that you'll be able to edit it later?
If you view string literals as memory that you don't own, you can roll this up into the guideline of making an owned copy to guarantee control. So yes, you'd allocate your own array of the correct size and copy the contents of the string literal into that array.
Or since this is C++, make a std::string object. :)
So the issue only affects C-style char arrays? You won't run into that issue with an std::string object?
This particular issue only affects string literals when you want to modify them. The std::string implementation may use a copy on write implementation where the underlying array is shared until you try to write to the string (then a copy is made), but that's all hidden under the hood.
Write a C program that should create a 10 element array of random integers (0 to 9). The program should total all of the numbers in the odd positions of the array and compare them with the total of the numbers in the even positions of the array and indicate ...
I have a 2d matrix with dimension (3, n) called A, I want to calculate the normalization and cross product of two arrays (b,z) (see the code please) for each column (for the first column, then the second one and so on).
the function that I created to find the ...