ac>> Hi there.  Why does emx/gcc disallow the modification of string 
 ac>> constants?  

 > Presumably so that they can be stored in the same area of memory as the 
 > program code, and be protected.

That sounds reasonable.  Such protection is quite new to me though.

 > I don't know.  The ANSI Rationale is available from here if you want to 
 > see if they said anything about that.

Hmm. I don't think the Rationale came with ANSI_C.ZIP, so in that case I
don't have it.  File name?

 ac>> Or more to the point - why does ANSI/ISO C disallow this?  Tnx.

 > From memory, they made it implementation-defined whether you could or 
 > not.

'Undefined behaviour' from memory.  In Appendix C, 'Differences: ANSI C
Compared to Traditional C' (pg. 616) of 'A Book on C' (Third Edition) by
Kelley/Pohl it says 'String constants are not modifiable.  (Not all
compilers enforce this.)'


 ac>> 1.0, the following code executes without error.  CLint 1.41 also 
 ac>> passed the following code with flying colors.

 > I would imagine it would be hard for lint to detect something like 
 > that.

Yeah, I was thinking that but thought I'd mention it anyway.  Detecting it
at compile time would certainly be very difficult (given the permutations
of such code).  Detecting it at run-time would be a lot easier, but by that
time you might as well stick your head in a bucket.


I originally found out about the existance of this rule by accident, when I
was calling one of the functions YOU'D WRITTEN. :-)  eg.

    int hasDomain, hasZone, hasNet, hasNode, hasPoint;
    int zone, net, node, point;
    char szdomain[100];

    prseaddr("3:633/267.1{at}fidonet", szdomain, &hasDomain,
&zone, &hasZone,        &net, &hasNet, &node,
&hasNode, &point, &hasPoint);

will fail under gcc/emx because the code in prseaddr() actually tries to
modify "3:633/267.1{at}fidonet", which is a string literal.

 ac>> The following code is a simple work-around for the rule:

 ac>>     char *str = strdup("Hello world");

 > Bearing in mind that strdup() is not ISO C.

Right on cue Paul, I was expecting you to say that. 

 > A better method would be char str[] = "Hello world";

Yeah, I found that out after I re-read the ANSI C spec.  Before then I
always thought 'char *str = ...' and 'char str[] = ...' were identical! 
Back to the drawing board...  Tnx.

--- Msgedsq/2 3.20