On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
> On 9/18/2023 11:31 AM, David Brown wrote:
>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>
>>>> * Variables can often be declared "const".  This leads to clearer code
>>>> that is easier to reason about - things don't change, and you only have
>>>> to look at one line to see the value that the variable has.  For
>>>> non-const variables, you have to look throughout their lifetimes - this
>>>> is maximally bad if they are defined at the top of the function.
>>>
>>> I would add that declaring variables const gives the optimization pass
>>> additional information and may result in more efficient register
>>> allocation and code generation.
>>>
>>>      const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>
>>> also enhances readability.
>>
>> I agree that adding "const" improves readability, because it tells the
>> human reader that the thing never changes.
>>
>> But it doesn't help the compiler, since the compiler can read the rest
>> of the function and see that it does not change.  (So could a human
>> reader, but I care about saving the human reader the effort of having
>> to do that - I don't care about saving the compiler effort!)
>>
>>
>
> const as in:
>
> void
> ct_foo(
>   ct_foobar* const self
> ){
>    // self cannot be changed... So be it!
> }
>
> Kosher? ;^)

What about:

void
ct_foo(
ct_foobar const* const self
){
// self cannot be changed... So be it!
// the ct_foobar that self points to is const...
}

:^)

Bart <bc@freeuk.com> writes:
> On 18/09/2023 19:10, Kaz Kylheku wrote:
>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>
>>>> * Variables can often be declared "const". This leads to clearer code
>>>> that is easier to reason about - things don't change, and you only have
>>>> to look at one line to see the value that the variable has. For
>>>> non-const variables, you have to look throughout their lifetimes - this
>>>> is maximally bad if they are defined at the top of the function.
>>>
>>> I would add that declaring variables const gives the optimization pass
>>> additional information
>> Declaring variables const provides no additional optimizing info
>> over
>> just not assigning to the variable and not taking its address.
>>
>
> If you take a program like this:
>
> typedef struct {int d,m,y;} date;
>
> void fred(date d) {}
> void bill(const date d) {}
>
> int main(void) {
> date dd;
>
> fred(dd);
> bill(dd);
>
> On a modern ABI where the struct is passed internally by reference (if
> not, make it bigger), a compiler may be obliged to copy the struct to
> a temporary location when calling fred(), but doesn't need to do so
> when calling bill(), if it trusts that 'const' qualifier.
[...]

Interesting point, but I doubt that any compilers do this.

The compiler can assume the parameter object is not modified
only if the *definition* is visible, as it is in your example.
A standalone declaration with "const" on a parameter gives no
information about whether the parameter is const in the definition.
And a compiler could inline the call to bill(), particularly if
there's only one call. Once it's inlined, the compiler can see
whether d is actually modified. (Multiple calls and/or external
visibility make inlining more difficult.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:

> So, basically, 'const' can never be trusted?

No.

> If you have this:
>
> extern void F(void);
> const int abc=100;
>
> int main(void) {
>
> F();
> abc;
>
> Then this point, a compiler can never assume that 'abc' still has the value
> '100' at this point?

The object has a const-qualified type. It can not be altered except in
a way that results in undefined behaviour meaning that a compiler is
allowed to assume that it has not changed. (Of course, it also means
that a compiler can ignore the const if that makes sense for that
particular implementation.)

--
Ben.

On 2023-09-18, Bart <bc@freeuk.com> wrote:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> wrote:
>>> On 18/09/2023 19:10, Kaz Kylheku wrote:
>>>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const". This leads to clearer code
>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>> to look at one line to see the value that the variable has. For
>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information
>>>>
>>>> Declaring variables const provides no additional optimizing info over
>>>> just not assigning to the variable and not taking its address.
>>>>
>>>
>>> If you take a program like this:
>>>
>>> typedef struct {int d,m,y;} date;
>>>
>>> void fred(date d) {}
>>> void bill(const date d) {}
>>
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would say
> that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of {}
> could be anything, not literally empty bodies.
>
>> Since this is a definition, the compiler can inline the function, and
>> make it disappear, since it does nothing.
>>
>>> int main(void) {
>>> date dd;
>>>
>>> fred(dd);
>>> bill(dd);
>>>
>>> On a modern ABI where the struct is passed internally by reference (if
>>> not, make it bigger), a compiler may be obliged to copy the struct to a
>>> temporary location when calling fred(), but doesn't need to do so when
>>> calling bill(), if it trusts that 'const' qualifier.
>>
>> Suppose that bill is an external function, which is declared like
>> this:
>>
>> void bill(const date d);
>>
>> that const means nothing and can (really, should) be ignored.
>>
>> The function definition can look like:
>>
>> void bill(date d) { /*...*/ }
>>
>> or like:
>>
>> void bill(const date d) { /*...*/ }
>>
>> both of these are correct, and their ABI must be exactly the same.
>>
>>> Although this is nothing really to do with optimisation, just common sense.
>>
>> Common sense is no substitute for 1) documentation and 2) empirically
>> knowing how things are made by people who follow (1).
>
> So what would you do if generating code for:
>
> bill(dd);
>
> when the body of bill() is not visible; would you make a copy of the
> struct of not?

If I had make sure that it's compatible with another compiler or
platform ABI, then I would research into their rules.

If I could implement it from scratch, I would probably pass very small
structures as several register arguments, if registers are available
in light of other arguments. In other cases by address.

Since that address is never declared as a pointer argument, const
doesn't enter into the picture.

It has to look like pass-by-value, so the caller cannot modify the
object. The function definition is compiled such that if the structure
is modified, or its address is taken such that we cannot prove that it's
not modified elsewhere, then we generate code to make a copy. The stack
frame is extended by enough space to provide the storage for the copy,
etc.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>> On 9/18/2023 11:31 AM, David Brown wrote:
>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>
>>>>> * Variables can often be declared "const".  This leads to clearer code
>>>>> that is easier to reason about - things don't change, and you only have
>>>>> to look at one line to see the value that the variable has.  For
>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>> is maximally bad if they are defined at the top of the function.
>>>>
>>>> I would add that declaring variables const gives the optimization pass
>>>> additional information and may result in more efficient register
>>>> allocation and code generation.
>>>>
>>>>      const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>
>>>> also enhances readability.
>>>
>>> I agree that adding "const" improves readability, because it tells the
>>> human reader that the thing never changes.
>>>
>>> But it doesn't help the compiler, since the compiler can read the rest
>>> of the function and see that it does not change.  (So could a human
>>> reader, but I care about saving the human reader the effort of having to
>>> do that - I don't care about saving the compiler effort!)
>>>
>>>
>> const as in:
>> void
>> ct_foo(
>>   ct_foobar* const self
>> ){
>>    // self cannot be changed... So be it!
>> }
>> Kosher? ;^)

....cannot be changed without undefined behaviour.

> What about:
>
> void
> ct_foo(
> ct_foobar const* const self
> ){
> // self cannot be changed... So be it!
> // the ct_foobar that self points to is const...
> }

Technically, no. The ct_foobar that self points to can't be changed
using the self pointer directly, but the ct_foobar object itself might
be const or it might not be, and it might even be able to be changed by
the function in question:

void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
{ ...
change_this_thing_beyond_recognition(other_foobar);
...
}

and later...

ct_foobar my_obj;
...
ct_eg(&my_obj, &my_obj);

This is (in part) what restrict-qualified pointers are for.

--
Ben.

Bart <bc@freeuk.com> writes:
> On 18/09/2023 20:59, David Brown wrote:
[...]
>>   It is legal
>> for program to cast a pointer-to-const to a pointer-to-non-const,
>> and use that to change the value, ***as long as the original object was
>> not defined as "const"***.

Emphasis added.

> So, basically, 'const' can never be trusted?

No.

> If you have this:
>
> extern void F(void);
> const int abc=100;
>
> int main(void) {
>
> F();
> abc;
>
> Then this point, a compiler can never assume that 'abc' still has the
> value '100' at this point?

No, see above. The original object was defined as "const".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> wrote:
[...]
>>> If you take a program like this:
>>>
>>> typedef struct {int d,m,y;} date;
>>>
>>> void fred(date d) {}
>>> void bill(const date d) {}
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would
> say that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of
> {} could be anything, not literally empty bodies.
[...]

You posted valid code (with two empty function bodies), and it's
reasonable to assume that you were referring to that exact code.
If you want to indicate that the bodies might not be empty, I
suggest something like:
void fred(date d) {...}
void bill(const date d) {...}
or
void fred(date d) { /* ... */ }
void bill(const date d) { /* ... */ }

Of course if you had posted with ; rather than {} as you intended, that
would have been different -- but we can only see what you actually post,
not what you mean.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-09-18, Bart <bc@freeuk.com> wrote:
> On 18/09/2023 20:59, David Brown wrote:
>> The compiler can't trust the "const" qualifier.  (Well, it can in this
>> case where it can see the definition of "bill" - but I assume you meant
>> when the function was defined externally.)  It is legal for program to
>> cast a pointer-to-const to a pointer-to-non-const, and use that to
>> change the value, as long as the original object was not defined as
>> "const".
>
> So, basically, 'const' can never be trusted?

A const qualifier on a function parameter (the parameter itself,
not what it points to) means nothing as far as declaring anything
to a caller.

It's active in definitions. In a function definition, parameters are
local variables, and that's how you make the parameter const.

It can be repeated in the declaration, but means nothing.

ISO C says something like thaat for the purposes of determining whether
two function types are compatible, qualifiers on the parameters are
ignored.

These two pointers have exactly the same type:

void (*p1)(const int);
void (*p2)(int);

You shouldn't put const qualifiers on parameters in declarations; since
they are ignored, it can only lead to confusion on the part of someone
who doesn't know about this quirk or has forgotten about it.

> If you have this:
>
> extern void F(void);
> const int abc=100;
>
> int main(void) {
>
> F();
> abc;
>
> Then this point, a compiler can never assume that 'abc' still has the
> value '100' at this point?

It can; abc isn't a parameter involved in determining function
compatibility, so that isn't a situation in which const is ignored.

Here the const means that assigning a value to abc is a constraint
violation, and modifying abc in some underhanded way like

*(int *)(&abc) = 0;

is undefined behavior. The compiler can assue that abc holds 100 on the
principle of assuming that no undefined behavior took place.

On 9/18/2023 2:26 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>>> On 9/18/2023 11:31 AM, David Brown wrote:
>>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const".  This leads to clearer code
>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>> to look at one line to see the value that the variable has.  For
>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information and may result in more efficient register
>>>>> allocation and code generation.
>>>>>
>>>>>      const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>>
>>>>> also enhances readability.
>>>>
>>>> I agree that adding "const" improves readability, because it tells the
>>>> human reader that the thing never changes.
>>>>
>>>> But it doesn't help the compiler, since the compiler can read the rest
>>>> of the function and see that it does not change.  (So could a human
>>>> reader, but I care about saving the human reader the effort of having to
>>>> do that - I don't care about saving the compiler effort!)
>>>>
>>>>
>>> const as in:
>>> void
>>> ct_foo(
>>>   ct_foobar* const self
>>> ){
>>>    // self cannot be changed... So be it!
>>> }
>>> Kosher? ;^)
>
> ...cannot be changed without undefined behaviour.
>
>> What about:
>>
>> void
>> ct_foo(
>> ct_foobar const* const self
>> ){
>> // self cannot be changed... So be it!
>> // the ct_foobar that self points to is const...
>> }
>
> Technically, no.

When I read right to left wrt:

ct_foobar const* const self

I see,

self is a:

const pointer to a

const ct_foobar

Did I get it wrong?

The ct_foobar that self points to can't be changed
> using the self pointer directly, but the ct_foobar object itself might
> be const or it might not be, and it might even be able to be changed by
> the function in question:
>
> void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
> {
> ...
> change_this_thing_beyond_recognition(other_foobar);
> ...
> }
>
> and later...
>
> ct_foobar my_obj;
> ...
> ct_eg(&my_obj, &my_obj);
>
> This is (in part) what restrict-qualified pointers are for.
>

On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
> On 2023-09-18, Bart <bc@freeuk.com> wrote:
>> On 18/09/2023 20:59, David Brown wrote:
>>> The compiler can't trust the "const" qualifier.  (Well, it can in this
>>> case where it can see the definition of "bill" - but I assume you meant
>>> when the function was defined externally.)  It is legal for program to
>>> cast a pointer-to-const to a pointer-to-non-const, and use that to
>>> change the value, as long as the original object was not defined as
>>> "const".
>>
>> So, basically, 'const' can never be trusted?
>
> A const qualifier on a function parameter (the parameter itself,
> not what it points to) means nothing as far as declaring anything
> to a caller.[...]

A const is just a hint to the programmer, in a sense?

ct_foobar const* const self;

seems to get the "intent" across?

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
[...]
>> A const qualifier on a function parameter (the parameter itself,
>> not what it points to) means nothing as far as declaring anything
>> to a caller.[...]
>
> A const is just a hint to the programmer, in a sense?

Only when it's applied to a function parameter in a function declaration
that is not part of a function definition.

> ct_foobar const* const self;
>
> seems to get the "intent" across?

That means that `self` is a const pointer to const `ct_foobar`, where
`ct_foobar` is a type. Both occurrences of `const` impose constraints
on code that refers to self. If that's the "intent", then yes, it gets
it across.

Note that this is not a parameter declaration (if it were, the semicolon
would be a syntax error), so it's not directly relevant to the current
discussion.

If it were a parameter declaration, then the second `const` (which makes
`self` itself a const object) would impose no constraints on callers,
but if the function declaration were part of a function definition, it
would impose a constraint on code inside the function.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 9/18/2023 4:19 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
> [...]
>>> A const qualifier on a function parameter (the parameter itself,
>>> not what it points to) means nothing as far as declaring anything
>>> to a caller.[...]
>>
>> A const is just a hint to the programmer, in a sense?
>
> Only when it's applied to a function parameter in a function declaration
> that is not part of a function definition.
>
>> ct_foobar const* const self;
>>
>> seems to get the "intent" across?
>
> That means that `self` is a const pointer to const `ct_foobar`, where
> `ct_foobar` is a type. Both occurrences of `const` impose constraints
> on code that refers to self. If that's the "intent", then yes, it gets
> it across.
>
> Note that this is not a parameter declaration (if it were, the semicolon
> would be a syntax error), so it's not directly relevant to the current
> discussion.

void
ct_foo(
ct_foobar* const self
){
// self "cannot" be changed... So be it!
}

vs:

void
ct_foo(
ct_foobar const* const self
){
// self "cannot" be changed... So be it!
// the ct_foobar that self points to is const...
}

Any better?

>
> If it were a parameter declaration, then the second `const` (which makes
> `self` itself a const object) would impose no constraints on callers,
> but if the function declaration were part of a function definition, it
> would impose a constraint on code inside the function.
>

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 9/18/2023 2:26 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>>>> On 9/18/2023 11:31 AM, David Brown wrote:
>>>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>>
>>>>>>> * Variables can often be declared "const".  This leads to clearer code
>>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>>> to look at one line to see the value that the variable has.  For
>>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>>
>>>>>> I would add that declaring variables const gives the optimization pass
>>>>>> additional information and may result in more efficient register
>>>>>> allocation and code generation.
>>>>>>
>>>>>>      const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>>>
>>>>>> also enhances readability.
>>>>>
>>>>> I agree that adding "const" improves readability, because it tells the
>>>>> human reader that the thing never changes.
>>>>>
>>>>> But it doesn't help the compiler, since the compiler can read the rest
>>>>> of the function and see that it does not change.  (So could a human
>>>>> reader, but I care about saving the human reader the effort of having to
>>>>> do that - I don't care about saving the compiler effort!)
>>>>>
>>>>>
>>>> const as in:
>>>> void
>>>> ct_foo(
>>>>   ct_foobar* const self
>>>> ){
>>>>    // self cannot be changed... So be it!
>>>> }
>>>> Kosher? ;^)
>> ...cannot be changed without undefined behaviour.
>>
>>> What about:
>>>
>>> void
>>> ct_foo(
>>> ct_foobar const* const self
>>> ){
>>> // self cannot be changed... So be it!
>>> // the ct_foobar that self points to is const...
>>> }
>> Technically, no.
>
> When I read right to left wrt:
>
> ct_foobar const* const self
>
> I see,
>
> self is a:
>
> const pointer to a
>
> const ct_foobar
>
> Did I get it wrong?

No, that's a reasonable way to read the type, but that type does not
conflict with anything I said. We say "points to a const ct_foobar" but
that's a shorthand. The thing pointed to may not be const. What is
const in the pointer target type, so the lvalue expression

*self

has a const qualified type. The object pointed to can't be altered
using that lvalue expression even though the object may not itself have
a const-qualified type.

>> The ct_foobar that self points to can't be changed
>> using the self pointer directly, but the ct_foobar object itself might
>> be const or it might not be, and it might even be able to be changed by
>> the function in question:
>> void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
>> {
>> ...
>> change_this_thing_beyond_recognition(other_foobar);
>> ...
>> }
>> and later...
>> ct_foobar my_obj;
>> ...
>> ct_eg(&my_obj, &my_obj);
>> This is (in part) what restrict-qualified pointers are for.

--
Ben.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 4:19 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
>> [...]
>>>> A const qualifier on a function parameter (the parameter itself,
>>>> not what it points to) means nothing as far as declaring anything
>>>> to a caller.[...]
>>>
>>> A const is just a hint to the programmer, in a sense?
>> Only when it's applied to a function parameter in a function
>> declaration
>> that is not part of a function definition.
>>
>>> ct_foobar const* const self;
>>>
>>> seems to get the "intent" across?
>> That means that `self` is a const pointer to const `ct_foobar`,
>> where `ct_foobar` is a type. Both occurrences of `const` impose
>> constraints on code that refers to self. If that's the "intent",
>> then yes, it gets it across.
>>
>> Note that this is not a parameter declaration (if it were, the
>> semicolon would be a syntax error), so it's not directly relevant to
>> the current discussion.
>
> void
> ct_foo(
> ct_foobar* const self
> ){
> // self "cannot" be changed... So be it!
> }

Attempting to modify self directly, for example `self = NULL;`, is a
constraint violation. Attempting to modify self indirectly, for example
`*(ct_foobar*)self = NULL;` has undefined behavior.

> vs:
>
> void
> ct_foo(
> ct_foobar const* const self
> ){
> // self "cannot" be changed... So be it!
> // the ct_foobar that self points to is const...
> }
>
> Any better?
[...]

And in both cases, the fact that the parameter `self` is const does not
affect callers.

Better for what purpose?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Monday, 18 September 2023 at 16:10:23 UTC+1, David Brown wrote:
> On 18/09/2023 15:02, Malcolm McLean wrote:
>
> > And it is far better to not use it at all than to have "semi-const" or
> > "logically const" concepts, where const is used but doesn't actually mean
> > what it conventionally means.
> Why is using "const" (telling the user "I won't change your data") when
> you mean "logically const" worse than using non-const (telling the user
> "Beware - I'm going to change your data") when you are /not/ going to
> change it? C won't let you say exactly what you mean either way.
>
Firstly, const obviously means "this won't change", but there's no "mutated"
keyword to mean "this will change" or this will change". Non-const items
are simply not declared const. You can assume that they may change if
and only if the project has a policy of "const correctness". And even then,
where const means "this won't change", non-const only means "this changes
on some execution path". Which may be excluded by the other parameters.
It doesn't mean that the object will change.
So it's not symmetrical.
If you have a policy of exclusing const then all the problems simply disappear.
You have to document which functions change objects passed by pointer,
if and only if they are transparent pointers and it's any business of callers.
But it's the rare function where the pointer is transparent, but any documentation
worthy of the name wouldn't say what state the object is left in after the function
returns.

On 9/18/2023 4:44 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 9/18/2023 4:19 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
>>> [...]
>>>>> A const qualifier on a function parameter (the parameter itself,
>>>>> not what it points to) means nothing as far as declaring anything
>>>>> to a caller.[...]
>>>>
>>>> A const is just a hint to the programmer, in a sense?
>>> Only when it's applied to a function parameter in a function
>>> declaration
>>> that is not part of a function definition.
>>>
>>>> ct_foobar const* const self;
>>>>
>>>> seems to get the "intent" across?
>>> That means that `self` is a const pointer to const `ct_foobar`,
>>> where `ct_foobar` is a type. Both occurrences of `const` impose
>>> constraints on code that refers to self. If that's the "intent",
>>> then yes, it gets it across.
>>>
>>> Note that this is not a parameter declaration (if it were, the
>>> semicolon would be a syntax error), so it's not directly relevant to
>>> the current discussion.
>>
>> void
>> ct_foo(
>> ct_foobar* const self
>> ){
>> // self "cannot" be changed... So be it!
>> }
>
> Attempting to modify self directly, for example `self = NULL;`, is a
> constraint violation. Attempting to modify self indirectly, for example
> `*(ct_foobar*)self = NULL;` has undefined behavior.
>
>> vs:
>>
>> void
>> ct_foo(
>> ct_foobar const* const self
>> ){
>> // self "cannot" be changed... So be it!
>> // the ct_foobar that self points to is const...
>> }
>>
>> Any better?
> [...]
>
> And in both cases, the fact that the parameter `self` is const does not
> affect callers.
>
> Better for what purpose?
>

Better to try to convey to a reader that this intent is meant, or else
be there nasal demons... ?

On 18/09/2023 20:36, Bart wrote:
....
>   typedef struct {int d,m,y;} date;
>
>   void fred(date d) {}
>   void bill(const date d) {}

In a declaration that's not a definition:

void bill(const date d);

qualifiers such as "const" that are applied directly to parameters are
simply ignored. In the declaration which is part of a definition of the
function, such qualifiers matter only inside the function - they have no
effect on compatibility between the function's definition and it's other
declarations.

The only reason to declare such a parameter "const" is if it's not
supposed to be changed. In that regard, it's just like any other
variable which is local to the function. It's a good general rule that
you should declare any variable "const" if you know that it should never
be changed from the value it's initialized with. If that's the case, the
qualifier ensures that most code which puts the variable at risk of
being changed will make it mandatory for the compiler to issue a
diagnostic. When you see that diagnostic, you know that either you were
wrong about that variable never changing, or the code that triggered the
diagnostic needs to be corrected.

You don't need the "const" to enable any applicable optimizations - if
your code does not, in fact, change the variable, the compiler can
easily detect that fact and apply any optimizations enabled by that fact.

On 19/09/2023 01:47, comp.lang.c wrote:

(Malcolm, you've mixed up your Google Groups settings somewhere, and
given yourself the name "comp.lang.c". )

> On Monday, 18 September 2023 at 16:10:23 UTC+1, David Brown wrote:
>> On 18/09/2023 15:02, Malcolm McLean wrote:
>>
>>> And it is far better to not use it at all than to have "semi-const" or
>>> "logically const" concepts, where const is used but doesn't actually mean
>>> what it conventionally means.
>> Why is using "const" (telling the user "I won't change your data") when
>> you mean "logically const" worse than using non-const (telling the user
>> "Beware - I'm going to change your data") when you are /not/ going to
>> change it? C won't let you say exactly what you mean either way.
>>
> Firstly, const obviously means "this won't change", but there's no "mutated"
> keyword to mean "this will change" or this will change".

That's not what "const" means in C. But we can fully agree that there
is no "mutated" keyword or other nuanced "sort-of constant" marker in C.
(Perhaps one day there will be attributes added for this kind of thing.)

> Non-const items
> are simply not declared const. You can assume that they may change if
> and only if the project has a policy of "const correctness".

No, you must /always/ assume that they might change - unless there is
documentation guaranteeing that they don't.

Even with "const", it is possible for things to change, because you can
always cast it away in the implementation of the function. But it is a
strong indication to the user that you do not intend to change anything,
and you have to go out of your way (such as via a cast) to change things
that are marked "const".

> And even then,
> where const means "this won't change", non-const only means "this changes
> on some execution path". Which may be excluded by the other parameters.

As we all know, non-const means "may change", not "/will/ change".

And "const" means "this won't change unless I really want it to".

> It doesn't mean that the object will change.
> So it's not symmetrical.

It is more symmetric than you think. It is not as clear-cut as you
think. And if you have something that does not change in the
user-visible aspects (assuming the function user sticks to the defined
API), but may change in its internal aspects, there is no fixed rule
that says whether the pointer should be marked "const" or left
non-const. I would say it must be handled on a case-by-case basis -
whatever makes things clearer to the user and reduce their risk of
getting things wrong. (And of course the nuances must be documented,
since C can't express them.)

> If you have a policy of exclusing const then all the problems simply disappear.

Give up and run away? C's "const" keyword is not perfect in all
use-cases, so you think it is better to miss out entirely? That's a
very poor attitude. No tool is ever perfect in all circumstances -
that's no excuse for not doing the best you can with what you've got.

> You have to document which functions change objects passed by pointer,
> if and only if they are transparent pointers and it's any business of callers.

Documentation should supplement the code, not replace it. When things
can be written in the language, write it in the language - not in comments.

> But it's the rare function where the pointer is transparent, but any documentation
> worthy of the name wouldn't say what state the object is left in after the function
> returns.

I'm not sure what you are trying to say here - I'm not sure that /you/
are sure. After all, if a function takes a pointer to an object, the
documentation should be very clear about what state the object will be
in after the call.

On 18/09/2023 22:57, Bart wrote:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> wrote:
>>> On 18/09/2023 19:10, Kaz Kylheku wrote:
>>>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const".  This leads to clearer
>>>>>> code
>>>>>> that is easier to reason about - things don't change, and you only
>>>>>> have
>>>>>> to look at one line to see the value that the variable has.  For
>>>>>> non-const variables, you have to look throughout their lifetimes -
>>>>>> this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information
>>>>
>>>> Declaring variables const provides no additional optimizing info over
>>>> just not assigning to the variable and not taking its address.
>>>>
>>>
>>> If you take a program like this:
>>>
>>>     typedef struct {int d,m,y;} date;
>>>
>>>     void fred(date d) {}
>>>     void bill(const date d) {}
>>
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would say
> that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of {}
> could be anything, not literally empty bodies.
>
>> Since this is a definition, the compiler can inline the function, and
>> make it disappear, since it does nothing.
>>
>>>     int main(void) {
>>>         date dd;
>>>
>>>         fred(dd);
>>>         bill(dd);
>>>
>>> On a modern ABI where the struct is passed internally by reference (if
>>> not, make it bigger), a compiler may be obliged to copy the struct to a
>>> temporary location when calling fred(), but doesn't need to do so when
>>> calling bill(), if it trusts that 'const' qualifier.
>>
>> Suppose that bill is an external function, which is declared like
>> this:
>>
>>    void bill(const date d);
>>
>> that const means nothing and can (really, should) be ignored.
>>
>> The function definition can look like:
>>
>>    void bill(date d) { /*...*/ }
>>
>> or like:
>>
>>    void bill(const date d) { /*...*/ }
>>
>> both of these are correct, and their ABI must be exactly the same.
>>
>>> Although this is nothing really to do with optimisation,  just common
>>> sense.
>>
>> Common sense is no substitute for 1) documentation and 2) empirically
>> knowing how things are made by people who follow (1).
>
> So what would you do if generating code for:
>
>    bill(dd);
>
> when the body of bill() is not visible; would you make a copy of the
> struct of not? Bear in a mind that while this struct is only 12 bytes,
> another might be 0.5MB in size, and copying it on each of millions of
> calls would be a major overhead.
>

By "you", do you mean the compiler? Yes, the compiler needs to make a
copy if the original "dd" is needed later. And if it does not have
access to the definition of "bill" (it's in a separately compiled unit),
it needs to follow the ABI - typically for large structures, that means
copying it onto the stack. (For some targets, it may mean passing a
hidden pointer to a copy that does not have to be on the stack - that's
up to the target ABI.)

If the compiler has access to the definition of "bill" and is handling
the compilation of the two parts together, it's a different story. Then
it can merge code, inline code, use information about whether "bill"
actually changes "dd" or not, use any calling convention it wants, and
so on. Whole-program optimisation (or link-time-optimisation - there
are many names) gives the compiler a lot of freedom. But regardless, it
must always give the same end results as though "dd" were copied.

On 18/09/2023 23:01, Bart wrote:
> On 18/09/2023 20:59, David Brown wrote:
>> On 18/09/2023 20:36, Bart wrote:
>>> On 18/09/2023 19:10, Kaz Kylheku wrote:
>>>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const".  This leads to clearer
>>>>>> code
>>>>>> that is easier to reason about - things don't change, and you only
>>>>>> have
>>>>>> to look at one line to see the value that the variable has.  For
>>>>>> non-const variables, you have to look throughout their lifetimes -
>>>>>> this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information
>>>>
>>>> Declaring variables const provides no additional optimizing info over
>>>> just not assigning to the variable and not taking its address.
>>>>
>>>
>>> If you take a program like this:
>>>
>>>    typedef struct {int d,m,y;} date;
>>>
>>>    void fred(date d) {}
>>>    void bill(const date d) {}
>>>
>>>    int main(void) {
>>>        date dd;
>>>
>>>        fred(dd);
>>>        bill(dd);
>>>
>>> On a modern ABI where the struct is passed internally by reference
>>> (if not, make it bigger), a compiler may be obliged to copy the
>>> struct to a temporary location when calling fred(), but doesn't need
>>> to do so when calling bill(), if it trusts that 'const' qualifier.
>>
>> The compiler can't trust the "const" qualifier.  (Well, it can in this
>> case where it can see the definition of "bill" - but I assume you
>> meant when the function was defined externally.)  It is legal for
>> program to cast a pointer-to-const to a pointer-to-non-const, and use
>> that to change the value, as long as the original object was not
>> defined as "const".
>
> So, basically, 'const' can never be trusted?

Not fully, no.

int foo(const int * p) {
int * q = (int *) p;
*q++;
return *q;
}

You have to go out of your way to remove the "const" qualifier, so
"const" is good at stopping accidents. And good programmers are not
going to break "const" without very good reason (and hopefully very good
documentation), but it certainly can be done.

The "const" qualifier in C is about as good as can be made for something
that was added to the language. To give a language a proper concept of
read-only access that can't be broken, I believe you really need to have
it as a fundamental from the start. (It is the norm for functional
programming languages, for examples.) "const" in C is far from perfect
in all cases, but useful in many situations nonetheless.

>
> If you have this:
>
>     extern void F(void);
>     const int abc=100;
>
>     int main(void) {
>
>         F();
>         abc;
>
> Then this point, a compiler can never assume that 'abc' still has the
> value '100' at this point?
>

Ah, that's a little different. If an object is /defined/ with "const",
then changing its value is undefined behaviour. And that means the
compiler /can/ assume it does not change.

This is true even if you have code :

int * p = (int *) &abc;
*p = 123;

The compiler can still assume "abc" is 100 after that code. Maybe the
program will crash on the line "*p = 123;", due to memory protection
trapping. Maybe it will run and crash later - its undefined behaviour,
so there are no guarantees.

On 19/09/2023 05:13, James Kuyper wrote:
> On 18/09/2023 20:36, Bart wrote:
> ...
>>   typedef struct {int d,m,y;} date;
>>
>>   void fred(date d) {}
>>   void bill(const date d) {}
>
> In a declaration that's not a definition:
>
> void bill(const date d);
>
> qualifiers such as "const" that are applied directly to parameters are
> simply ignored. In the declaration which is part of a definition of the
> function, such qualifiers matter only inside the function - they have no
> effect on compatibility between the function's definition and it's other
> declarations.
>
> The only reason to declare such a parameter "const" is if it's not
> supposed to be changed.

Structs passed 'by-value' on a modern ABI can very possibly be passed
by-reference. It depends on the struct details and ABI.

This makes it quite different from other kinds of objects which really
are passed by value. (An array object is another which is implicitly
passed by reference, but that detail is exposed in the language and
people will aware of it.)

> In that regard, it's just like any other
> variable which is local to the function. It's a good general rule that
> you should declare any variable "const" if you know that it should never
> be changed from the value it's initialized with. If that's the case, the
> qualifier ensures that most code which puts the variable at risk of
> being changed will make it mandatory for the compiler to issue a
> diagnostic. When you see that diagnostic, you know that either you were
> wrong about that variable never changing, or the code that triggered the
> diagnostic needs to be corrected.
>
> You don't need the "const" to enable any applicable optimizations - if
> your code does not, in fact, change the variable, the compiler can
> easily detect that fact and apply any optimizations enabled by that fact.

With independent compilation, or using external libraries, in general
the bodies of any functions that are called will not be visible, only
the declarations.

So that sort of analysis cannot be applied.

Apparently, to guaranteed pass-by-value semantics even though 'const'
has been applied, it is necessary to create a copy of such structs and
pass that instead.

But look at this example function of a library (Raylib) which uses
by-value structs extensively:

RLAPI Vector2 GetWorldToScreen(Vector3 position, Camera camera);

extern Vector3 arg1;
extern Camera arg2;

int main(void) {
GetWorldToScreen(arg1, arg2);
}

(Full specs are given below.)

The Vector3 type is 12 bytes, and Camera is 44 bytes. 56 bytes that need
copying on every call. This API has 100s of such functions, and structs
are always passed by value.

Wouldn't it be better if that copy could be avoided? That is, without
rewriting the library to use explicit references, and having to use &
for each passed struct. (I think that would also rule out being able to
use compound literals.)

Avoiding the copy means less generated code, and faster execution,
although the overheads for this library are not critical.

----------------------------------
#define RLAPI

typedef struct Vector2 {
float x; // Vector x component
float y; // Vector y component
} Vector2;

typedef struct Vector3 {
float x; // Vector x component
float y; // Vector y component
float z; // Vector z component
} Vector3;

typedef struct Camera3D {
Vector3 position; // Camera position
Vector3 target; // Camera target it looks-at
Vector3 up; // Camera up vector (rotation over its axis)
float fovy; // Camera field-of-view aperture in Y
(degrees) in perspective, used as near plane width in orthographic
int projection; // Camera projection: CAMERA_PERSPECTIVE or
CAMERA_ORTHOGRAPHIC
} Camera3D;

typedef Camera3D Camera; // Camera type fallback, defaults to Camera3D

RLAPI Vector2 GetWorldToScreen(Vector3 position, Camera camera);

extern Vector3 arg1;
extern Camera arg2;

int main(void) {
GetWorldToScreen(arg1, arg2);
}

On 18/09/2023 19:15, Kaz Kylheku wrote:
> On 2023-09-18, David Brown <david.brown@hesbynett.no> wrote:

>>
>> I prefer not to declare any variable until I have a proper
>> initialisation for it.
>
> C90 syntax supports this by allowing nested compound statements to
> introduce declarations.
>
> {
> int yes = 1;
> setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof yes);
> }
>
> This has advantages. We control not only the start of the identifier's
> scope, but also the end.
>
That's all true, but is the OP using C90? I've assumed he is using more
modern C, and the layout defining locals at the start of the function is
an active choice.

I think it is reasonable to assume that people are using at least C99,
if not C11, unless they specifically say they are hobbled to C90.

On 19/09/2023 08:41, David Brown wrote:
> On 18/09/2023 23:01, Bart wrote:

>> If you have this:
>>
>>      extern void F(void);
>>      const int abc=100;
>>
>>      int main(void) {
>>
>>          F();
>>          abc;
>>
>> Then this point, a compiler can never assume that 'abc' still has the
>> value '100' at this point?
>>
>
> Ah, that's a little different.  If an object is /defined/ with "const",
> then changing its value is undefined behaviour.  And that means the
> compiler /can/ assume it does not change.
>
> This is true even if you have code :
>
>     int * p = (int *) &abc;
>     *p = 123;
>
> The compiler can still assume "abc" is 100 after that code.  Maybe the
> program will crash on the line "*p = 123;", due to memory protection
> trapping.  Maybe it will run and crash later - its undefined behaviour,
> so there are no guarantees.

Making 'abc' static complicates things because some compilers will put
it into read-only memory. A test program where F was in a second module
that defined 'abc' without 'const', was able to modify 'abc' using
bcc/tcc, but it crashed on gcc.

A better example would have 'abc' as a const local which is somehow
accessible to an external function.

(I've played around with 'let' in my language, which works for simple
variables. You can't assign to them again, but also you can't apply &,
and they can't be passed to a function as a by-reference argument.

I didn't like it because it doesn't work for more elaborate types (where
applying & may be essential), and such variables have to be declared at
the first point of use. Currently 'let' variable are mainly used
internally for implicitly-declared for-loop indices.)

David Brown <david.brown@hesbynett.no> writes:
> On 19/09/2023 01:47, comp.lang.c wrote:
> (Malcolm, you've mixed up your Google Groups settings somewhere, and
> given yourself the name "comp.lang.c". )
[...]

It's likely something going wrong with Google Groups itself. I've seen
a handful or articles in other newsgroups with headers like

From: "newsgroup.name" <email@address>

(which caused some spam to bypass my filters). I made a test post on GG
that didn't exhibit the issue, so it's probably sporadic.

I'm sure Google's devotion to a smooth integration between Google Groups
and Usenet will lead to a quick solution -- in the fullness of time.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
>On 19/09/2023 01:47, comp.lang.c wrote:
>
>(Malcolm, you've mixed up your Google Groups settings somewhere, and
>given yourself the name "comp.lang.c". )

I've seen posts in other groups that imply this is a new "feature" of
the google groups interface.