2

CASE 1: char s[][6]={"Hello","world"}; in this case, a static array is allocated in read-only memory and from there the elements are copied to the array. and in case 2.

CASE 2: char* s= "hello world"; will place it in read-only memory.

so my question is why 

char s[][6]={"Hello","world"};
s[1]="lucky"; //is illegal

because if elements are being copied from read-only memory then why this statement s[1]="lucky"; can't be copied from read-only memory to array because an array is also allocated for this string literal and from there, elements are copied to s[1]. I have read many answers, and all are telling what's the difference but no one tells why? please explain as I am a beginner.

Michael Dorgan
  • 12,453
  • 3
  • 31
  • 61
Ashish Dogra
  • 593
  • 4
  • 13

2 Answers2

11
s[1]="lucky"; //is illegal

because array names are not a modifiable lvalue. As a result they can't appear on the left of the assignment.

Initialization is not assignment. It is during that initialization, when string literals don't decay into pointers, and rather the value of the literal is copied into memory which allow us to modify the content of it. (The first one you showed is an example of this).

From standard: 6.7.9.p14

An array of character type may be initialized by a character string literal or UTF-8 string literal, optionally enclosed in braces. Successive bytes of the string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array.

If you need to copy strings then you will have to use strcpy,memcpy etc.

user2736738
  • 30,591
  • 5
  • 42
  • 56
  • @AshishDogra the C syntax can be misleading. `char message[] = "Hallo World!"` is used to initialise the variable as a part of its definition. However `char message[20]; message = "Hallo World!"` is illegal. – Weather Vane Jan 23 '18 at 18:19
  • Rather than saying that intialization is a special case, I much prefer to say that *initialization is not assignment*, which indeed is consistent with what the standard has to say about it. – John Bollinger Jan 23 '18 at 18:27
  • @Nitin.: 2d array is an array of array...now think if I am wrong in what I said...`s[0]` is an array. – user2736738 Jan 23 '18 at 18:39
  • So yes, @coderredoc. It would be more correct to say the left-hand side of an assignment expression is among those few contexts where expressions of array type do not decay to pointers, and that expressions of array type furthermore are not modifiable lvalues. ([C2011 6.3.2.1/1-2](http://port70.net/~nsz/c/c11/n1570.html#6.3.2.1)) Thus `s[1]` appearing on the LHS of an assignment expression is *not* a modifiable lvalue. It's not about whether the expression is a bare identifier. – John Bollinger Jan 23 '18 at 18:51
  • @JohnBollinger.: Regarding this - nice point but even if it decayed it would not be an `lvalue` so we can't keep it in left hand of `=`. Confirm. (6.3.2.1p3) – user2736738 Jan 23 '18 at 18:54
  • @coderredoc, the fact that it does not decay and that it is not an lvalue are not really separable. They are two related facets of the way C handles arrays. They also go together with the fact that an object of array type appearing on the LHS of an assignment violates a constraint in the definition of assignment. – John Bollinger Jan 23 '18 at 18:58
  • @JohnBollinger.: Yep that's true - it is really so nice how standard is supporting each part - Do you mind if I add your initial comment? (With proper reference) – user2736738 Jan 23 '18 at 18:59
  • @JohnBollinger.: Is it alright? to put it with proper reference that you did comment it? Is it ok? – user2736738 Jan 23 '18 at 19:11
  • @JohnBollinger.: I have added it in my answer. If there is any issue regarding that please comment - I will rollback. Thanks for the interesting discussion. – user2736738 Jan 23 '18 at 19:17
  • @JohnBollinger.: Also I guess my content is much more closer to the standard explanation. Hope it gives DVer a reason to retract the DV. – user2736738 Jan 23 '18 at 19:25
  • 1
    @coderredoc, sorry to be slow to respond. I have no objection to you incorporating text from these comments into your answer. – John Bollinger Jan 23 '18 at 20:28
  • "left-hand side of an assignment expression is among those few contexts where expressions of array type do not decay to pointers," is incorrect. That IS a decay context. See C11 6.3.2.1/3. You mention 6.3.2.1/1-2 but those paragraphs do not apply to this situation. – M.M Aug 10 '19 at 02:47
  • @M.M. Hey long time...Hope you are doing well. Thanks for the reply. Yes I have mentioned that but I guess I can remove the whole footer paragraph which is lacking the context in this case. What do you say? Feel free to suggest. – user2736738 Aug 10 '19 at 04:17
  • @user2736738 removing that whole paragraph seems fine to me since it's wrong – M.M Aug 10 '19 at 05:15
  • @M.M.: Sounds good. Done. Thanks for your time. – user2736738 Aug 10 '19 at 15:02
-4

The simple answer is that 'C' doesn't provide that much luxury to programmers. Assignment operator in C only copies specific types from from right hand side to left hand side, e.g. int, char, struct etc. so thus you can use = operator for char but not for char* or char[][6] etc.

Other programming languages e.g. C++ can provide such luxury because you can overload the =-operator. There are some programming languages which support such operations by default e.g. JavaScript. I hope it clarifies your doubt.

Nitin
  • 145
  • 9
  • 1
    No, this is just wrong. C allows objects of structure types, union types, and enum types to appear on the left-hand side of an assignment operator. None of these are built-in types. It's actually quite specific: C explicitly and specifically forbids objects of array types from appearing on the left-hand side of an assignment. – John Bollinger Jan 23 '18 at 18:30
  • @JohnBllinger: Thanks for your comment, I modified my answer. – Nitin Jan 23 '18 at 18:34
  • 3
    No, you're still missing the point. It is not that only specific types are allowed to be used with the assignment operator. It is that objects of array types -- exclusively those, among all the type families supported by C -- cannot under any circumstances appear on the LHS of an assignment. Additionally, characterizing it in terms of "luxury" or absence thereof is unwelcome, especially when set up as a contrast with other languages. Let's not engage in language wars, please. – John Bollinger Jan 23 '18 at 18:45
  • @JohnBillinger: I welcome your comments :-) – Nitin Jan 23 '18 at 18:56