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

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

ANSIRATL.ZIP for an HTML version (anyone want to convert this into
plain text so that I can FREQ it back off you?).  ANSIRAT.ZIP for
a postscript version.

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.

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

I don't trust books, ever since PJ Plauger in his "Standard C Library"
said that size_t was always the unsigned version of ptrdiff_t.  And
he was the head of the bloody committee!

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

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

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

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

Hmmmm, I could copy it into a local variable or something, but
I'd say your usage is pretty rare.

BFN.  Paul.
@EOT:

---