embedded questions!!!

If you don't really know what hit you, please consider reading the following to avoid something like this happening again.

Actually neither - the Heusinger von Waldegg mechanism is used instead.

--

Tauno Voipio
tauno voipio (at) iki fi

You're right!!

I just hope the OP can use this heavily researched work on his exam.

str1[0] = '\0';

Rufus

Bzzt - WRONG. str1 contains a pointer to a non-modifiable string (which may well reside in ROM). str1 itself contains no letter O. Thus the only way is:

str1 = "JHNSN";

Things would be different if the original declaration was:

char str1[] = "JHONSON";

which would have initialized a character array to a C string.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

Or Not... this type of thing can be very compiler dependent!

Paul

No. The behaviour is spelled out in the C standard.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

On a host system with a modern compiler you are 100% correct.

On an 8-bit embedded systems... I have seen compilers that will store the string in ROM. All the while claiming to be ANSI Compliant!

The problem is to do this properly on an embedded system the compiler has to actually copy the data from ROM to the string.

Regards

Paul

I would say those compilers are just broken.

And that is *exactly* what it should do, but why is that a problem ? It is not any different then declaring and initializing an int, for example :

int a = 5; int b[] = { 1, 2, 3 }; char msg[] = "Hello";

--
:wq
^X^Cy^K^X^C^C^C^C

The fastest way is to do it is in assembler not C.

Ian

A yeah, very helpful - tail wagging the dog methinks.

You really don't have a clue about managing scarce resources do you?

Ian

I don't see how I could be helpful at all in this case. I believe that having a compiler that by default stores

char msg[] = "Hello";

into read only memory really *is* broken, and there is nothing I can do about that by writing in a newsgroup, is there ?

I forgot to mention that this is not a job for the compiler, but for the C startup code, ofcourse.

I may not know all about it, but while spending my last few years coding C and assembly on tiny embedded platforms, I might have learned

*something* about scarse resources, I hope. Apart from that, I do not understand what broken compilers and not having a clue about scarce resources have to do with each other ?

Since I am not a C expert by any means, I would like to invite you to continue this discussion on comp.lang.c; I assume there are people there who can shed some light on this issue.

Ico

--
:wq
^X^Cy^K^X^C^C^C^C

If that is true, you should look for a compiler alternative :-).

Regards, Kurt

--
Kurt Harders
PiN -Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.pin-gmbh.com

On 12/01/2006 the venerable Chuck F. etched in runes:

well reside in ROM).

Bzzzzt - WRONG.

A pointer to non-modifiable string would be declared as

const char *str1 = "JHONSON";

The two declarations:

char str1* = "JHONSON";

and

char str2[] = "JHONSON";

both allocate space for a modifiable string. The difference being that the first one also creates a pointer to that string.

--
John B

may well reside in ROM).

first one also creates a

Isn't str2 also a pointer?

BTW, I will admit a recurring problem with understanding the nuances of C pointers.

I think you have missed the entire point. Something declared as:

char *s = "string";

declares a non-writeable "string" which may be in rom. However

char s[] = "string";

declares a 7 byte char array, which must be writable, and is initialized to contain "string\0". Here, in most cases, the value of s is passed as a pointer to the first char of "string".

As a result, a function

T foo(char *stg) {...}

called by

foo(s);

will receive the same _value_ in the parameter stg for either original declaration. However in one case *stg is writable, in the other it is not.

gcc allows the 'char *s = "string"' to imply const char. This is helpful in tracking down bugs if you use const correctly elsewhere.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

There are good arguments that that's what it _should_ be like, but it isn't.

Completely wrong, for two reasons.

1) A typo: the first one has to read

char *str1 = "JHONSON"

2) Incorrect ideas about C. The string allocated by this (fixed) declaration is *not* modifiable. Any program trying to write to str1[i] would be broken.

Some C platforms will indeed keep string literals in modifiable storage. But the language definition explicitly allows them to be in read-only storage, and that means all programs assuming otherwise are broken. They cause undefined behaviour.

This is all for hysterical raisins. From an abstract point of view, the type of string literals _should_ obviously be "array of const char", which would mean

char *str1 = "JHONSON"

would trigger a warning about mixing const and non-const. But it isn't. That's because there was no "const" in the original language, and by the time it was added in a reliable way, it was way past too late to change that.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

... snip ...

you mean "char *str1 = ..."

Not so. I just wrote an explanation of the difference in this thread. The char * declaration _MAY_ create a modifiable string, but need not. This allows multiple such declarations to point to the same actual string, if the compiler so chooses.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at:

[...]

No.

Repeat after me: "Arrays are not pointers. Pointers are not arrays." Despite what you may have been told.

A pointer is an object that references some other object.

An array is a group of contiguously allocated objects of the same type.

(This is the important bit) The unadorned name of an array devolves into a pointer to the first element of that array. Sort of like a compile-time constant.

One point of confusion is the mechanism of array indexing. The syntax "a[i]" has *exactly* the same meaning as "(*a + i)" whether a is a pointer or array. So given the declarations above, str1[0] == 'J' == str2[0].

Another is the syntax for passing an array as a parameter to a function. Thus "Fn(str1);" looks to be much the same as "Fn(str2);" but the actual semantics are a bit different. Inside the function itself, of course, the parameter is the same in either case.

Peter van der Linden's "Expert C Programming: Deep C Secrets" has one or two excellent chapters on the differences between arrays and pointers (as well as sections on understanding and contruction C declarations, and other topics introductory books are to timid to tackle). Somewhat dated (it was written about a dozen years ago), but very readable and recommended. You don't read it because you're an expert already, you read it to become expert...

Regards, -=Dave

--
Change is inevitable, progress is not.