«

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.

James Kuyper <> 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) kst- <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"

On 04/17/2012 09:34 PM, Keith Thompson wrote:
> James Kuyper <> 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