Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Question About const Keyword

Reply
Thread Tools

Re: Question About const Keyword

 
 
James Kuyper
Guest
Posts: n/a
 
      04-17-2012
On 04/17/2012 03:58 PM, David T. Ashley wrote:
> Consider the following function.
>
> void or_me_please_thank_you(unsigned *target, const unsigned *source)
> {
> *target |= *source;
> }
>
> I was reluctant to declare the second parameter "const" because
> someone might call the function with the same pointer for both
> parameters.
>
> But then I thought, if someone does this, the array will be unchanged,
> because a | a == a, so it would be const then too.
>
> Does "const" mean that the memory location won't be changed, or that
> it won't be written? (These are two different conditions.)


It doesn't really promise anything, as I'll explain below, but what you
should avoid is writing through such a pointer. Avoiding changing the
value it is not sufficient.

It's easier if I digress for a moment. Defining an object with a 'const'
qualifier that applies to the object itself (and not, for instance, to
something it points at) allows an implementation to store that object in
read-only memory; attempts to write to such an object have undefined
behavior. That means that the C standard allows arbitrarily bad things
to happen if your code makes such an attempt.

For all other purposes, 'const' serves only to mark things that you
don't intend to change, so that diagnostic messages are mandatory if you
write code that attempts to change it. This only protects against
mistakes; you can easily evade the diagnostics by casting away the 'const'.

In order for 'const' to achieve it's full usefulness, you should always
consider the possibility that a pointer to a const object type might
point at an object stored in read-only memory, and write your code
accordingly. This means that your code should never attempt to write
through such a pointer. It's the writing that triggers the undefined
behavior if the object pointed at happens to be allocated in read-only
memory; writing a new value that's no different from the old one won't
avoid that problem.

However, in this case, all of the writing occurs through 'target'. If
someone attempts to pass const unsigned* pointers as both arguments of
your function, the first one will trigger a diagnostic, even though the
second one won't, and that's sufficient to achieve the purpose of
'const'. It doesn't matter whether they point at the same object or
different ones - it's not something your program needs to worry about.

Tricky extra detail: for data types where the same value can have
multiple representations (which is most data types other than unsigned
integer types), there's no guarantee that the expression "a = a" leaves
'a' unchanged. The value of 'a' will be unchanged, it might contain a
different representation of the same value.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      04-18-2012
James Kuyper <(E-Mail Removed)> writes:
[...]
> It's easier if I digress for a moment. Defining an object with a 'const'
> qualifier that applies to the object itself (and not, for instance, to
> something it points at) allows an implementation to store that object in
> read-only memory; attempts to write to such an object have undefined
> behavior. That means that the C standard allows arbitrarily bad things
> to happen if your code makes such an attempt.

[...]

Right. And, to be clear, attempts to write such an object have
undefined behavior whether the implementation chooses to store it
in read-only memory or not. (Optimizing compilers commonly cause
such code to misbehave.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      04-18-2012
On 04/17/2012 09:34 PM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:
> [...]
>> It's easier if I digress for a moment. Defining an object with a 'const'
>> qualifier that applies to the object itself (and not, for instance, to
>> something it points at) allows an implementation to store that object in
>> read-only memory; attempts to write to such an object have undefined
>> behavior. That means that the C standard allows arbitrarily bad things
>> to happen if your code makes such an attempt.

> [...]
>
> Right. And, to be clear, attempts to write such an object have
> undefined behavior whether the implementation chooses to store it
> in read-only memory or not. (Optimizing compilers commonly cause
> such code to misbehave.)


Right. I should have said "undefined behavior" first, and then given
"read only memory" as an example of what that allows, second.
--
James Kuyper
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
is const necessary in eg int compar(const void *, const void *) lovecreatesbeauty@gmail.c0m C Programming 26 11-10-2008 09:47 PM
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
Casting int'** to 'const int * const * const' dosn't work, why? Jonas.Holmsten@gmail.com C Programming 11 07-01-2007 06:16 PM
Smart Pointer release() const : it can set the pointer to null with the keyword "const"? coala C++ 1 09-06-2006 03:00 PM
Smart Pointer release() const : it can set the pointer to null with the keyword "const"? coala C++ 3 09-06-2006 02:58 PM



Advertisments