const type qualifier and external linkage (term.?)

[Ben Petering]

Hi group,

this is a 'best practice' type question (I want discussion of the issue
- whys and why nots - similar to "casting the return value of malloc()",
to cite an analogous case).

Let's say I have a function written in assembler/(some non-C language)
which takes one pointer-to-const-char arg, the declaration being:

extern unsigned int str_len(const char *s);

Is the 'const' type qualifier 1) advisable and 2) legal? The C compiler
has no way of enforcing what a non-C function does with the pointer, and
as I understand it, the type qualifier is a guarantee of sorts - the
compiler guarantees said l-value will not be modified using the passed
pointer.

If I'm not mistaken, this makes the presence of the qualifier
inadvisable. Correct?

Response appreciated. Apologies for possible OT or incorrect terminology.

-ben
--
Posted via a free Usenet account from http://www.teranews.com

[Chris Torek]

In article <47***********************@free.teranews.com>
Ben Petering <bj*@dfmagicp.orgwrote:

>this is a 'best practice' type question (I want discussion of the issue
- whys and why nots - similar to "casting the return value of malloc()",
to cite an analogous case).

Let's say I have a function written in assembler/(some non-C language)
which takes one pointer-to-const-char arg, the declaration being:

extern unsigned int str_len(const char *s);

Is the 'const' type qualifier 1) advisable and 2) legal?

It is definitely "legal" (a poorly-specified term, but no matter how
*you* are using it, I think it comes out the same ... of course it is
possible that none of the interpretations I am guessing at are the one
you intended). As for "advisable", that depends.

>The C compiler has no way of enforcing what a non-C function does with
the pointer,

Indeed -- but it has no way of enforcing what a C function does either:

void icky(const int *p) {
*(int *)p = 42;
}

is valid C code, with no diagnostic required. I would call this
"inadvisable" though. :-)

>and as I understand it, the type qualifier is a guarantee of sorts - the
compiler guarantees said l-value will not be modified using the passed
pointer.

No, there is no such guarantee (see icky() above). It does tend
to promise a human reader that the function will not modify *s,
though. The main thing that it (this const) does, in a C compiler,
is make calls that pass const-qualified pointers semantically
correct, so that no diagnostic is required.

I think this is far clearer when shown by example. Suppose we are
writing some C code and are working on some intermediate or top level
function:

void something(const char *str) {
unsigned int val;

... do some work ...
val = str_len(str); /* note this line */
... do more work ...
}

For whatever reason (good or bad) our function, something() in this
case, takes a "const char *" value. It then calls the assembly
str_len(), passing the pointer value "str" on. If you change the
declaration for str_len() to take plain (non-const-qualified)
"char *", the call at the "noted" line now violates a constraint,
and a diagnostic is required.

If something() is an intermediate-level function, and we want to
call it as follows, then having something() take "const char *" is
"good" because one of the following calls provides a pointer to
"const char":

const char const_buf[] = "hello";
char modifiable_buf[] = "world";
...
something(const_buf);
something(modifiable_buf);

It is OK to "add" a const qualifier (but only a "top level" one;
see the comp.lang.c FAQ for details; C gets this wrong while C++
gets it right) in a call, but it is not OK to remove one. This is
(presumably) why something() takes a "const char *", and if
something() needs to call str_len(), and str_len() will not modify
the chars involved, including the qualifier in the declaration for
str_len() is probably a good idea.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Thad Smith]

Chris Torek wrote:

In article <47***********************@free.teranews.com>
Ben Petering <bj*@dfmagicp.orgwrote:

>The C compiler has no way of enforcing what a non-C function does with
the pointer,

Indeed -- but it has no way of enforcing what a C function does either:

void icky(const int *p) {
*(int *)p = 42;
}

is valid C code, with no diagnostic required. I would call this
"inadvisable" though. :-)

Even
int x = (int*)p;
would result in undefined behavior if p pointed to an object declared
const. I am aware of one implementation in which the results of
int x = (int*)p; and
int x = *p;
can be different for parameter const int *p.

--
Thad

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sun, 30 Dec 2007 10:39:26 -0700, Thad Smith wrote:

Even
int x = (int*)p;

I'll assume you meant *(int*)p.

would result in undefined behavior if p pointed to an object declared
const. I am aware of one implementation in which the results of
int x = (int*)p; and
int x = *p;
can be different for parameter const int *p.

Accessing read-only memory using non-const pointers is certainly allowed
in C and in fact quite often done, since string literals have type (non-
const) char[]. It's also valid for objects defined explicitly as const;
there's simply no prohibition against doing so. The behaviour is
undefined if you try to write to read-only data (whether string literal
or const). Could you give some details about your implementation?

[Thad Smith]

Harald van Dijk wrote:

On Sun, 30 Dec 2007 10:39:26 -0700, Thad Smith wrote:

>Even
int x = (int*)p;

I'll assume you meant *(int*)p.

Yes. Thanks for catching this.

>would result in undefined behavior if p pointed to an object declared
const. I am aware of one implementation in which the results of
int x = (int*)p; and
int x = *p;
can be different for parameter const int *p.

Accessing read-only memory using non-const pointers is certainly allowed
in C and in fact quite often done, since string literals have type (non-
const) char[]. It's also valid for objects defined explicitly as const;
there's simply no prohibition against doing so.

Oops, I misread the Standard. 6.7.3 p5 switched from discussing const
modifier to volatile modifier and left me with the wrong impression.

The behaviour is
undefined if you try to write to read-only data (whether string literal
or const). Could you give some details about your implementation?

A different addressing mechanism is used for read-mostly (flash) memory and
read-write memory (RAM). const variables are placed in flash memory.
Dereferencing a non-const pointer uses only RAM access while dereferencing
a const-qualified pointer does run-time testing to access either RAM or
flash. There is no language mechanism to write const variables. I believe
there is a compile-time option to place string literals in read-mostly memory.

--
Thad