Re: Crazy stuff

From: Jack Klein (jackklein_at_spamcop.net)
Date: 11/09/04 

Date: Mon, 08 Nov 2004 20:48:06 -0600

On 8 Nov 2004 06:57:17 GMT, gordonb.nxqee@burditt.org (Gordon Burditt)
wrote in comp.lang.c:

> >> strtok()s first argument is a char *, and is overwritten to produce the
> >> token (yes, this is a terrible way of doing things, as an ex-Java man you
> >> probably expect something like the Java string tokeniser).
> >
> >So far, so good.
> >
> >> char *str = "My string"; creates a constant string in read-only memory.
> >
> >The line above is completely wrong. "My string" is a string literal,
> >and the C standard states that it has the type array of char.
> >Specifically NOT array of const char. So it is not a constant string.
> >Furthermore, C does not define any such thing as "read-only memory".
>
> C *DOES* define certain memory areas, such as string literals, which
> cannot be written on without invoking undefined behavior. This
> is something the implementation is free to put in "read-only memory".
> (Or it might not, on implementations with no memory protection.)

C does not define "memory areas" at all. Modifying a string literal,
or modifying any object defined with the const qualifier, is undefined
behavior. There is not even a requirement that such an operation
fails, merely that the behavior is undefined if the attempt is made.

> >> char str[] = "My string"; creates a string in read-write memory.
> >
> >The line above creates an array of chars that may be modified,
> >provided that its bounds are not exceeded. C does not define any such
> >thing as "read-write memory".
>
> C *DOES* define certain memory areas, such as non-const variables,
> that can be written on without invoking undefined behavior.
> It is reasonable to conclude that the implementation must put
> this in memory that can be read and written, hence "read-write memory".

C still does not define "memory areas" at all. It defines objects
that may be freely modified by a program. Almost all of them, in
fact, other than those defined const and string literals. Nowhere
does the standard mention that these must be stored in a special
"memory area". It also doesn't specify whether any particular
modifiable object is in SRAM, DRAM, or virtual memory that might be
swapped out to a page file at any particular time.

> C does not define a (human) name, address, social security number,
> or quantity of currency, but it is still possible to talk about
> programs that handle data described like this.

It is indeed quite possible for a C program to use data objects as
representations of "real world" concepts.

But it is indeed quite impossible to force a C implementation to
provide "read-only memory" just because you define a string literal.

> Gordon L. Burditt

The poster to whom I replied wrote a sentence that contained two very
specific factual errors, directly in contradiction to the C language
standard:

> char *str = "My string"; creates a constant string in read-only memory.

The two errors are:

1. The type of "My string" in the snippet is 'array of char', most
specifically not 'array of constant char'. See 6.4.5 P5.

2. The standard states that an implementation may (note MAY) place
certain const objects and string literals in "a read-only region of
storage" (footnote 112). Note that footnotes are not normative, and
the term "read-only" is not specifically defined in the standard.
Most certainly, there is no requirement or guarantee that "My string"
in the snippet above will be placed in any sort of specially qualified
memory.

If you think either of my corrections is inaccurate, kindly quote
chapter and verse from the standard to contradict them. 

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Relevant Pages

  • Re: releasing memory
    ... > the memory management for you. ... Thanks for the tip about calculating array sizes, ... willing to spend their time helping out struggling beginner programmers. ... look at the libraries that standard C++ has to offer. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Problem with va_ macros and arrays of arrays
    ... > the arrays passed to a ... > specific char, somewhat similar to what the standard function ... that with an array of struct, or possibly a pointer to a dynamic array ... > As I'm still a beginner in C without a copy of the standard I ...
    (comp.lang.c)
  • Re: char * ptr = "hello" and char carray[] = "hello"
    ... Is it a fair statement that char *ptr will take ... which means that the initialiser for the array ... standard that would confirm the equivalence to the above "shorthand". ... situation when the literal is used as an array initializer. ...
    (comp.lang.c)
  • Re: Passing Pointers
    ... And now you know why you didn't want to allocate that 100 char array above: ... Note the memory you're deleting was allocated within Input. ... so name now points to a dynamically allocated array of chars. ... >void Output ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Passing Pointers
    ... And now you know why you didn't want to allocate that 100 char array above: ... Note the memory you're deleting was allocated within Input. ... so name now points to a dynamically allocated array of chars. ... >void Output ...
    (comp.lang.cpp)
Loading