Re: PROBLEM
- From: Eric Sosman <Eric.Sosman@xxxxxxx>
- Date: Tue, 18 Jul 2006 11:39:54 -0400
Charlie Gordon wrote On 07/18/06 05:15,:
"Keith Thompson" <kst-u@xxxxxxx> wrote in message
news:lnirlv66f7.fsf@xxxxxxxxxxxxxxxxxx
"superman" <incredible_vijay@xxxxxxxxx> writes:
Why does this code:
char *p = "hello, world!";
p[0] = 'H';
crash?
comp.std.c is for discussion of the ISO C standard(s). Questions
about C programming belong in comp.lang.c
If at all possible, you should post a complete, self-contained program
that exhibits your problem. Code fragments can be difficult to debug
if, for example, they depend on declarations you haven't shown us.
(That's not an issue in this particular case, but you can never be
sure of that.)
The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've just asked
question 1.32.
On the contrary, the issue raised by the OP is very much on topic here: why are
string literals not const?
The obvious answer is "it would break too many programs"
Then why extend the language at all?
Why does it matter that old programs must conform to a new C standard?
The opinion of the Committee was that "Existing code
is important, existing implementations are not." (Rationale,
Section 0.)
The opinion is imprecise, of course: "important" is not
well-defined, and there is no explicit rule to resolve the
conflict when two "important" considerations collide. Keep
in mind, though, that the Committee was explicitly chartered
to codify "existing practice" to the extent it could, and not
to invent a new language. The result is "warts and all" C.
There are practical considerations, too. Imagine yourself
in 1991, say, as the Grand Poohbah of Software Development at
Megacorp. Your company has written ten million lines of C
source (that's not a huge amount), all using the pre-Standard
Frobozz Magic C compiler, and you are pondering whether to
move the code base to the newfangled ANSI/ISO C90 Standard.
If the move involves multiple programmer-years of busy-work
just to get the code to compile (not enhancing it or improving
it in any way, just getting past the compile errors), how eager
will you be to make the transition? Will you go to the CEO
and propose spending half a year's development budget on zero
net improvement to the product? Where will your next job be?
By the way, this is by no means a theoretical concern.
I was involved in exactly this debate in about 1996 or 1997,
at a PPOE whose paltry three million lines of code used pre-
Standard C. It was by then all being compiled with Standard-
conforming compilers (modulo bugs) on multiple platforms, but
still used K&R function argument lists, no prototypes, and
assorted other hold-overs. The proposal was to introduce
prototypes and convert function definitions to ANSI style, as
a sort of prophylactic measure to prepare for our first 64-bit
port. The proposal was DEFEATED on exactly the grounds I
outlined above: Large expenditure of programmer time for no
demonstrable improvement to the product. And this was with a
Standard that was by then six or seven years old and did *not*
mandate extra busy-work to redo practically every function
taking a string argument!
It is one thing for a Standard to be adopted by ANSI or
ISO or FIFA or whatever. That's done once, more or less, by
organizational procedures and eventually by organizational
fiat. But the real world may perfectly well acknowledge the
existence of a Standard while paying it little more than lip
service -- observe the lethargic uptake of C99, for example,
or look around for purveyors of NAPLPS implementations. A
Standard that's adopted but not accepted is a paper tiger, and
one imagines the Committee desired to produce something more
than origami.
--
Eric.Sosman@xxxxxxx
.
- Follow-Ups:
- Re: PROBLEM
- From: Douglas A. Gwyn
- Re: PROBLEM
- References:
- Re: PROBLEM
- From: Charlie Gordon
- Re: PROBLEM
- Prev by Date: Re: PROBLEM
- Next by Date: Re: PROBLEM
- Previous by thread: Re: PROBLEM
- Next by thread: Re: PROBLEM
- Index(es):
Relevant Pages
|
