«

Ico wrote:
>
> 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 ?

The trouble is that the standard doesn't take the requirements of small
embedded systems into account. Most compilers (for microcontrollers)
will create the string as an initialised variable in RAM. To force it
into another space, different compilers come up with different
constructs. Some use 'const' as a marker that the string is to be in
ROM. Others add extra keywords like 'code'. Others still put all
initialised strings into ROM unless you tell them not to. And it's a
bugger when porting code.

I think we are simply below the radar of the exalted creatures who dwell
in bliss on the standards committees.

Paul Burke

Paul Burke <> writes:
> Ico wrote:
>> 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 ?
>
> The trouble is that the standard doesn't take the requirements of
> small embedded systems into account.

I don't see anything in your article that supports that statement.

> Most compilers (for
> microcontrollers) will create the string as an initialised variable in
> RAM.

Which is exactly what I'd expect.

> To force it into another space, different compilers come up with
> different constructs. Some use 'const' as a marker that the string is
> to be in ROM.

And that's perfectly appropriate. If it's declared 'const', any
attempt to modify it would invoke undefined behavior, so putting it in
ROM can't create problems for correct code.

> Others add extra keywords like 'code'.

That would break any programs that attempt to use 'code' as an
identifier (unless, for example, the keyword is recognized only after
a system-specific header is included), but otherwise it seems
innocuous enough. It makes sense if you want an explicit directive to
put a variable in a special memory segment (ROM or whatever), as
opposed to "const" which is merely a promise by the programmer not to
modify the variable.

> Others still put
> all initialised strings into ROM unless you tell them not to. And it's
> a bugger when porting code.

And that sounds like a serious problem. If I can't do the following:

char msg[] = "Hello";
msg[0] = 'h';

then I'm not using a conforming C compiler. There's nothing
inherently wrong with implementing a C-like language that doesn't
allow you to do this, of course, but it's not really C.

And unles I'm missing something, there's just no need for a compiler
to behave that way. If I want msg to be in ROM, I can just declare it
as const (or use whatever extension the compiler provides to force it
into ROM). You can do everything you need to do within the confines
of standard C.

> I think we are simply below the radar of the exalted creatures who
> dwell in bliss on the standards committees.

I don't think so; it seems more like certain compiler implementers are
ignoring the standard.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Paul Burke wrote:
>
> Ico wrote:
> >
> > 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 ?
>
> The trouble is that the standard doesn't take the requirements of small
> embedded systems into account. Most compilers (for microcontrollers)
> will create the string as an initialised variable in RAM. To force it
> into another space, different compilers come up with different
> constructs. Some use 'const' as a marker that the string is to be in
> ROM. Others add extra keywords like 'code'. Others still put all
> initialised strings into ROM unless you tell them not to. And it's a
> bugger when porting code.

It depends on what you mean by initialized strings. I would call the
example an initialized char array. The char array must go into RAM.

Contrast the above code with
char *msg = "Hello"; (or better: const char *msg= "Hello"
or
#define msg "Hello"
which may safely allocate the string literal in ROM.
--
Thad