«

Hello again,

It's not clear enough for me when to use const and when not use const.

As I understand const should be used everywhere i have a variable which
should be put in read-only data (.rodata (is this segment standard for
read-only data (i mean title of it 'rodata'))?) segment. So by putting it
in .rodata segment i ensure the data can never be altered?

Should const be used everywhere it should be used, what improvments does
it make? If i precisely declare variables const where needed does the
compiler do it's job better?

For example,
int function(const char *data, int section) {
...
}

What's the difference if i had simply 'char *data' and not 'const char
*data'?

Anything about 'const' welcomed.


P.Krumins

Peteris Krumins <> wrote in
news:Xns93A8289E3231whitesuneapollolv@130.133.1.4:

> It's not clear enough for me when to use const and when not use const.
>
> As I understand const should be used everywhere i have a variable which
> should be put in read-only data (.rodata (is this segment standard for
> read-only data (i mean title of it 'rodata'))?) segment. So by putting
> it in .rodata segment i ensure the data can never be altered?

No, C won't guarantee this, your compiler might, or it might not. Don't
depend on this. Const is only there to help you catch writes to const
vars. at compile time. Don't expect more from it.

--
- Mark ->
--

"Peteris Krumins" <> wrote in message
>
> It's not clear enough for me when to use const and when not use const.
>
> Should const be used everywhere it should be used, what improvments
> does it make? If i precisely declare variables const where needed does the
> compiler do it's job better?
>
Don't worry about helping the compiler, unless you know enough not to have
to ask about const.
const tells you the programmer that data is read-only. Once you make a
high-level object const, everything that references it has to treat it as
const also.
>
> For example,
> int function(const char *data, int section) {
> ...
> }
>
> What's the difference if i had simply 'char *data' and not 'const char
> *data'?
>
function() is not allowed to modify the contents of the string "data" if it
is declared const. This can be useful in documenting the function - eg
copy(const char *s1, char *s2) tells you which way the copy goes.
Also, you can pass a const char * to function() without the compiler
complaining. function("My name is Fred", 1) would be OK, since the string
literal won't be modified.

Generally, if you have a low-level routine that takes a pointer and doesn't
modify the contents, then declare it as const. However be more careful about
declarign high-level objects as const, especially if control over the source
isn't too tight, as the compiler will complain if const is not used
consistently throughout.

In 'comp.lang.c', Peteris Krumins <> wrote:

> It's not clear enough for me when to use const and when not use const.

The trick is that, in C, the semantic of 'const' is not 'constant', but
'read-only'. May this revelation shade a new light on your thoughts.

> As I understand const should be used everywhere i have a variable which
> should be put in read-only data (.rodata (is this segment standard for
> read-only data (i mean title of it 'rodata'))?) segment. So by putting it
> in .rodata segment i ensure the data can never be altered?

These considerations are highly implementation dependent. It's however true
that on some implementations, the read-only stuffs (mainly the code and the
initialized constant arrays and strings) can, be laid out in read-only
segments that can physically be a parte of a PROM (or equivallent, flash or
whatever) on an embedded system or a read-only data segment on a hosted
system. More details on your linker documentation. It's not a C issue.

> Should const be used everywhere it should be used, what improvments does
> it make? If i precisely declare variables const where needed does the
> compiler do it's job better?

'const' is certainely useful as a design checker. For example, you know that
strings literals are not guaranteed to be modifiable. (On the embedded
systems I work on, strings are laid out on the flash. Trust me, don't attempt
to write to a flash!)

If you write a function accepting string literals, it is highly recommended
that the parameter receiving the address of such a string is a pointer to
const char.

void print (char const *s)
{
char const *p = s;

while (*p)
{
putchar (*p);
p++;
}
}

It prevents you to write ugly things like:

*p = 0;
or

*p = getchar ();

(The temperature is high in Paris at the moment, and I know that some brain
cells can melt...)

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

In 'comp.lang.c', Shill <> wrote:

>> May this revelation shade a new light on your thoughts.
> ^^^^^
> Interesting lapsus linguae.

Oops!

> Shade is the absence of light (ombre). I don't think you meant to
> take away what you'd just given (namely, a new light).
>
> The correct locution would be "to shed a new light".

Thanks!

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

In <Xns93A8289E3231whitesuneapollolv@130.133.1.4> Peteris Krumins <> writes:

> It's not clear enough for me when to use const and when not use const.

When writing a complete application, never.
When writing a library that may be used by other people, in every function
parameter declaration where it makes sense.

These guidelines will minimise the headaches caused by const.

>it make? If i precisely declare variables const where needed does the
>compiler do it's job better?
>
> For example,
> int function(const char *data, int section) {
> ...
> }
>
> What's the difference if i had simply 'char *data' and not 'const char
>*data'?

Here's a simple program showing the difference:

fangorn:~/tmp 147> cat test.c
#include <string.h>

void mmemcpy(void *dest, void *src, size_t size)
{
memcpy(dest, src, size);
}

int main()
{
const float f = 1.75;
float g;

memcpy(&g, &f, sizeof f);
mmemcpy(&g, &f, sizeof f);
return 0;
}
fangorn:~/tmp 148> gcc test.c
test.c: In function `main':
test.c:14: warning: passing arg 2 of `mmemcpy' discards qualifiers from pointer target type

Note that memcpy declares its second parameter as having the type const
void *. This way, the function can be called with arguments that are
pointers to both const and non-const objects. By omitting const from
the definition of mmemcpy, I restrict it to taking only pointers to
non-const objects as arguments (for no redeeming benefits).

Of course, if you never use const in your program, this is a non issue.
Hence the guidelines at the beginning of my post.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: