Hello, all.

This is my function for setting the length of a dynamic
array:

void* a_setlen( void * a, unsigned len )
{ unsigned newcap;
struct meta_t *m ;

m = META ( a );
m = setlen( m, len );
if( m != NULL ) a = DATA( m );
else a = NULL ;
return a;
}

To allow for a potential reallocation, it returns an updated
pointer to the array. Although it is small, and therefore
easily understandable at a glance as is, I am taught and
told that it smells bad, because of the reuse an input
variable to store the new value to be returned. Is it the
undubitable consensus that one shall redefine this function
as:

void* a_setlen( const void * const a, const unsigned len )
{ unsigned newcap;
struct meta_t *m ;
void *res ;

m = META ( a );
m = setlen( m, len );
if( m != NULL ) res = DATA( m );
else res = NULL ;
return res;
}

especially considering that it is a `public' function,
available to the programmer using the library? I personally
find pervasive const-correctenss a source of noise and
clutter, what do you think?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

I wrote:

> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }

Please, disregard the unused variable `newcap'.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Hello, all.
>
> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
>
> To allow for a potential reallocation, it returns an updated
> pointer to the array. Although it is small, and therefore
> easily understandable at a glance as is, I am taught and
> told that it smells bad, because of the reuse an input
> variable to store the new value to be returned. Is it the
> undubitable consensus that one shall redefine this function
> as:
>
> void* a_setlen( const void * const a, const unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
> void *res ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) res = DATA( m );
> else res = NULL ;
> return res;
> }
>
> especially considering that it is a `public' function,
> available to the programmer using the library? I personally
> find pervasive const-correctenss a source of noise and
> clutter, what do you think?

I have never bothered with const on parameters since it has no effect on
the caller, but I am puzzled by the const void *a. If this function
does what I think it does, the target of the pointer is altered. Mind
you, the macros are masking what's happening, but the function name
suggests are change to the target albeit through an opaque pointer.

--
Ben.

Anton Shepelev <anton.txt@gmail.moc> writes:

> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
>
> To allow for a potential reallocation, it returns an updated
> pointer to the array. Although it is small, and therefore
> easily understandable at a glance as is, I am taught and
> told that it smells bad, because of the reuse an input
> variable to store the new value to be returned. [...]

Is there some reason not to write a shorter and simpler function,
such as the function below (please ignore differences in layout
style)

void*
a_setlen( void *a, unsigned n ){
struct meta_t *const m = setlen( META( a ), n );

return m ? DATA( m ) : NULL;
}

Having the function parameters be const I would say is just
personal preference. With a function this short it doesn't
make much difference one way or the other.

The choice between 'void *a' and 'const void *a' has more
substance. If the memory pointed to by 'a' might be written by
this function (eg, in the call to setlen()) then 'const' should
certainly not be used. If the memory pointed to by 'a' will
definitly _not_ be written by this function, then my inclination
is to say 'const' should be used if (and maybe only if) it is
important to express that property. To say that another way, if
it's important for a caller to know that *a will not be modified
then 'const void *a' is appropriate, but if *a not being modified
is just a happenstance of how the code is written then my vote
would be to leave the const off.

I'm sure other people have some other opinions as to what is most
appropriate here. I am expressing a personal view and also some
of the reasoning behind it. I feel strongly that the best choice
in such cases is not just "always yes" or "always no".

On 2023-09-17, Anton Shepelev <anton.txt@gmail.moc> wrote:
> void* a_setlen( const void * const a, const unsigned len )
^^^^^ ^^^^^

These consts are not part of the interface. They make no difference to
the function type. The declaration of this function could be:

void* a_setlen( const void *a, unsigned len );

If this function potentially invalidates the original "a" object,
such that the caller should capture the returned pointer and
stop using the pointer "a", then "const void *" makes no sense.

--
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.

Ben Bacarisse to Anton Shepelev:

> > void* a_setlen( void * a, unsigned len )
> > { unsigned newcap;
> > struct meta_t *m ;
> >
> > m = META ( a );
> > m = setlen( m, len );
> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
> > return a;
> > }
>
> I have never bothered with const on parameters since it
> has no effect on the caller,

Yes, it prevents the function body from modifying a
parameter, `a' in my case.

> but I am puzzled by the const void *a. If this function
> does what I think it does,

Did you read or watch Princess Bride?

> the target of the pointer is altered.

Well, `a' points to the start of array data, whereas what I
(perhaps incorrectly) call its metadata is located at a
negative offset, is indeed changed by the function, but is
not literally pointed to by `a'. The array data may be
reallocated as well, but the value of `*a' (with propor
cast) will still be the first element of the array. Or
should I say it will be changed because `a' will be
pointing, in general, to an object of a different size and
at a different address, albeit with the same initial
contents?

> Mind you, the macros are masking what's happening, but the
> function name suggests are change to the target albeit
> through an opaque pointer.

The META macro retrievies the pointer to the metadata object
(and the entire allocated memory object) by subtracting an
offset from the pointer to array data.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Kaz Kylheku:

> The declaration of this function could be:
>
> void* a_setlen( const void *a, unsigned len );
>
> If this function potentially invalidates the original "a"
> object, such that the caller should capture the returned
> pointer and stop using the pointer "a", then "const void
> *" makes no sense.

Yes, after calling: b = a_setlen( a, 55 ); `a' is no longer
guaranteed to be point to a valid array, and `b' must be used
thenceforward. This is exactly my case.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Tim Rentsch to Anton Shepelev:

[an unused variable removed from quoted code:]
> > void* a_setlen( void * a, unsigned len )
> > { struct meta_t *m ;
> >
> > m = META ( a );
> > m = setlen( m, len );
> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
> > return a;
> > }
>
> Is there some reason not to write a shorter and simpler
> function, such as the function below (please ignore
> differences in layout style)
>
> void*
> a_setlen( void *a, unsigned n ){
> struct meta_t *const m = setlen( META( a ), n );
>
> return m ? DATA( m ) : NULL;
> }

My personal reasons are the following:

1. I prefer not to mix variable declaration and
initialisation, but first to declare my data and then
to work with it.

2. I consider nested calls a bit less readable than
sequential, alghough I do not alwasy avoid them.

3. Sequential calls let me insert ad-hoc debugging code
at the right points, e.g. between the invocations of
META() and setlen() above.

4. I consider the ternary operator a redundant special
case of the `if' statement that increases expression
nesting to the (granted, often but slight) detriment
of readability.

I have snipped your comments about `const', but not without
having perused them.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 18/09/2023 09:55, Anton Shepelev wrote:
> Ben Bacarisse to Anton Shepelev:
>
>>> void* a_setlen( void * a, unsigned len )
>>> { unsigned newcap;
>>> struct meta_t *m ;
>>>
>>> m = META ( a );
>>> m = setlen( m, len );
>>> if( m != NULL ) a = DATA( m );
>>> else a = NULL ;
>>> return a;
>>> }
>>
>> I have never bothered with const on parameters since it
>> has no effect on the caller,
>
> Yes, it prevents the function body from modifying a
> parameter, `a' in my case.

That's an implementation matter, rather than part of the interface of
the function. Inside the function definition, the parameters are like
local variables - the implementation can do what it wants with them, and
they don't affect the caller at all.

The way I look at it, is that since it is not relevant to the caller, it
should not be in the function declaration - it adds nothing, but could
potentially be misread ("int * const p" could be misread, thinking it
meant "int const * p"). And I always want all my declarations to match
- my extern function declarations in headers are identical to the
declaration at the start of the function definition.

Usually I don't want my functions to modify the parameters (there are
exceptions, typically for very small functions). But I find "const"
does not help enough to make it worth using here.

>
>> but I am puzzled by the const void *a. If this function
>> does what I think it does,
>
> Did you read or watch Princess Bride?
>
>> the target of the pointer is altered.
>
> Well, `a' points to the start of array data, whereas what I
> (perhaps incorrectly) call its metadata is located at a
> negative offset, is indeed changed by the function, but is
> not literally pointed to by `a'. The array data may be
> reallocated as well, but the value of `*a' (with propor
> cast) will still be the first element of the array. Or
> should I say it will be changed because `a' will be
> pointing, in general, to an object of a different size and
> at a different address, albeit with the same initial
> contents?

This is a typical conflict between "bitwise const" and "logical const" -
you have something whose value, as seen by code using the object, does
not change, although the implementation details and the bits held in the
object /do/ change. You see it also with objects that cache the results
of calculations, or self-optimising lists that move recently accessed
data to the front of the list.

C does not really have a good way to handle this. (C++ has "mutable"
class members, which helps here.) You can have a const pointer to your
dynamic array, where the array object is a struct with a non-const
pointer to the metadata, and a non-const pointer to the data. Then you
can change the metadata even though the parameter is a const pointer.

You can also take a const pointer as a way to indicate to the caller
that you are making no logical changes to the object. Then simply cast
it to a non-const pointer before doing the changes. This is allowed in
C if you can be sure that the function will never be called with an
object that was originally defined as "const". Whether you consider
this as giving the caller useful information while hiding the
implementation details, or as lying to the caller, is up to you.

>
>> Mind you, the macros are masking what's happening, but the
>> function name suggests are change to the target albeit
>> through an opaque pointer.
>
> The META macro retrievies the pointer to the metadata object
> (and the entire allocated memory object) by subtracting an
> offset from the pointer to array data.
>

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Ben Bacarisse to Anton Shepelev:
>
>> > void* a_setlen( void * a, unsigned len )
>> > { unsigned newcap;
>> > struct meta_t *m ;
>> >
>> > m = META ( a );
>> > m = setlen( m, len );
>> > if( m != NULL ) a = DATA( m );
>> > else a = NULL ;
>> > return a;
>> > }
>>
>> I have never bothered with const on parameters since it
>> has no effect on the caller,
>
> Yes, it prevents the function body from modifying a
> parameter, `a' in my case.
>
>> but I am puzzled by the const void *a. If this function
>> does what I think it does,
>
> Did you read or watch Princess Bride?

Eh?

>> the target of the pointer is altered.
>
> Well, `a' points to the start of array data, whereas what I
> (perhaps incorrectly) call its metadata is located at a
> negative offset, is indeed changed by the function, but is
> not literally pointed to by `a'. The array data may be
> reallocated as well, but the value of `*a' (with propor
> cast) will still be the first element of the array. Or
> should I say it will be changed because `a' will be
> pointing, in general, to an object of a different size and
> at a different address, albeit with the same initial
> contents?

The other way to look at it is to ask if it makes sense for a
user-written function, which is passed a pointer to a const void *a, to
call setlen. Alternatively, when reviewing code, I would assume that
such a function will have made no changes to any data associated with
the array object:

int user_calculation(const void *);
...
int result = user_calculation(array);
// Here, I would assume here that any data about 'array' obtained
// before this call is still valid, including the length.
...

--
Ben.

Anton Shepelev <anton.txt@gmail.moc> writes:

> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
>
> To allow for a potential reallocation, it returns an updated
> pointer to the array. [is the following declaration better?]
>
> void* a_setlen( const void *a, unsigned len )
> { [...]
> }
>
> especially considering that it is a `public' function,
> available to the programmer using the library?

(I removed the const-ness of the two function parameters as
that is not germane to my comments here.)

After reading your other responses I have something else to
add.

The added 'const' qualifier (ie, on the type of what a points to)
is bad. Besides being a hole in the type system, which may not
be a big deal, this declaration accepts 'const void *' arguments
without complaint. Presumably if someone has gone to the trouble
of declaring a variable (pointing to an extensible array) to be

const Foo *pfoo = ...; /* or perhaps a function parameter */

then they are expecting the array won't change out from under
them, including changing its length or adding new elements. So
we would like (or we think they would like) a call like

pfoo = a_setlen( pfoo );

to squawk, because pfoo is being used "wrongly", by virtue of its
having been declared 'const Foo *'. If this "wrongness" is what
they want, that should be asked for explicitly:

pfoo = a_setlen( (void*) pfoo );

So here I would advise against declaring the parameter a to be of
type 'const void *', and recommend 'void *a' be used in this
function definition.

On 18/09/2023 10:53, Anton Shepelev wrote:
> Tim Rentsch to Anton Shepelev:
>
> [an unused variable removed from quoted code:]
>>> void* a_setlen( void * a, unsigned len )
>>> { struct meta_t *m ;
>>>
>>> m = META ( a );
>>> m = setlen( m, len );
>>> if( m != NULL ) a = DATA( m );
>>> else a = NULL ;
>>> return a;
>>> }
>>
>> Is there some reason not to write a shorter and simpler
>> function, such as the function below (please ignore
>> differences in layout style)
>>
>> void*
>> a_setlen( void *a, unsigned n ){
>> struct meta_t *const m = setlen( META( a ), n );
>>
>> return m ? DATA( m ) : NULL;
>> }
>
> My personal reasons are the following:
>
> 1. I prefer not to mix variable declaration and
> initialisation, but first to declare my data and then
> to work with it.

Why? I've seen people give good reasons for this habit, and bad reasons
for it, so I'm curious as to /your/ reasons!

I prefer not to declare any variable until I have a proper
initialisation for it. This gives me several advantages :

* As soon as the variable exists, it is valid - there is never a point
at which code can refer to it without it having a proper value.

* 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.

* Code is easier to write and maintain, and can more easily be re-used,
copied or re-arranged as you only have the one line (definition and
initialisation) to handle, rather than two separate lines in different
parts of the function. "Leftovers", such as your "newcap" variable in
your initial post, are much rarer.

* Making new local variables becomes "cheaper" in terms of writing the
code, and for people reading and understanding the code. This makes it
natural to write a lot of code in "static single assignment form" - you
write your code as a series of expressions, the results of which are
assigned to const variables and are therefore unchanged within their
lifetimes. This ties in very well with your points 2 and 3 below.

I am mathematically trained, and learned a lot of programming principles
using functional programming (though I am decades out of practice at
it). I have never been entirely comfortable with the idea of changing a
variable - "x = x + 1" reads as mathematical nonsense. Obviously in an
imperative language like C, you are going to update variables in loops,
but it is, to me, often better to use new const variables than to re-use
an existing variable. There's a reason why many modern programming
languages make data effectively "const" by default.

>
> 2. I consider nested calls a bit less readable than
> sequential, alghough I do not alwasy avoid them.

Agreed - with the same caveat.

>
> 3. Sequential calls let me insert ad-hoc debugging code
> at the right points, e.g. between the invocations of
> META() and setlen() above.

Agreed, and for similar reasons (and also with the same caveat).
Creating variables for each such line is even better for debugging,
especially when you temporarily add "volatile" to the declaration. Then
you can easily view the value, regardless of the optimisation, and it
also makes it simple to enforce that the order of the expression
statements in the source code and object code match (while still keeping
useful optimisation), which helps for single-stepping during debugging.

>
> 4. I consider the ternary operator a redundant special
> case of the `if' statement that increases expression
> nesting to the (granted, often but slight) detriment
> of readability.
>

I am not a big user of the ternary operator, but sometimes it makes code
clearer.

However, your layout for "if" statements is, IMHO, appalling.
(Everything here is very much IMHO.) Anyone who sent in code like that
for a code review here would be sent back again - I would not even
bother telling them why, as I would expect every C programmer (in my
field at least) to have braces in any conditional with an "else". I
would also expect far better use of white space (though I realise that
is much more personal style) :

void * setlen(void * a, unsigned int len)
{ meta_t * m1 = META(a);
meta_t * m2 = setlen(m1, len);
if (m2) {
return DATA(m);
} else {
return NULL;
}
}

I (almost) always typedef my structs - there's no benefit in my code to
writing out "struct" on each use. A struct type is a type, and writing
"struct" (or "union", or "enum") when using such types is a distraction
from the useful code.

I'd use better names for "m1" and "m2" if I knew what the code was doing
:-) And I would not consider using macros for the "META" and "DATA" -
inline functions are a far better choice here.

Occasionally I find it helpful to have a "return variable" - typically
if there is some kind of epilogue or clean-up after the return value is
calculated. Normally, however, when I have the value to return, I
prefer to return it.

Feel free to value or ignore these opinions.

On 18/09/2023 15:02, Malcolm McLean wrote:
> On Monday, 18 September 2023 at 12:40:38 UTC+1, David Brown wrote:
>>
>> Usually I don't want my functions to modify the parameters (there are
>> exceptions, typically for very small functions). But I find "const"
>> does not help enough to make it worth using here.
>>
> Modifying a parameter is a micro-optimisation, which is almost always a
> bad idea.

I agree that micro-optimisations are usually not worth the effort, and
can be actively bad if they make the code less clear. But I would not
consider modifying a parameter to be a micro-optimisation - I expect the
compiler to generate identical code if I modify the parameter or if I
make a copy and modify that. Any such optimisations are the compiler's
job, not the programmers'.

> Just occasionally code is so critical that you have to do it, though
> modern compilers will usually do this sort of optimisation for you.

It's very rare that you have to write performance-critical code and have
such a poor quality compiler that it won't sort this kind of
optimisation for you.

> The other problem is that the natural name of the parameter and the natural
> name of the variable which initially takes the value of that parameter are
> often the same thing. So you have to think carefully about your naming.

Always think about your naming.

>
>>
>> This is a typical conflict between "bitwise const" and "logical const" -
>> you have something whose value, as seen by code using the object, does
>> not change, although the implementation details and the bits held in the
>> object /do/ change. You see it also with objects that cache the results
>> of calculations, or self-optimising lists that move recently accessed
>> data to the front of the list.
>>
>> C does not really have a good way to handle this. (C++ has "mutable"
>> class members, which helps here.) You can have a const pointer to your
>> dynamic array, where the array object is a struct with a non-const
>> pointer to the metadata, and a non-const pointer to the data. Then you
>> can change the metadata even though the parameter is a const pointer.
>>
>> You can also take a const pointer as a way to indicate to the caller
>> that you are making no logical changes to the object. Then simply cast
>> it to a non-const pointer before doing the changes. This is allowed in
>> C if you can be sure that the function will never be called with an
>> object that was originally defined as "const". Whether you consider
>> this as giving the caller useful information while hiding the
>> implementation details, or as lying to the caller, is up to you.
>>
> Say we've got a function called
>
> addemployee(PAYROLL *p, EMPLOYEE *employee);
> Now someone says "We can only have one chief secretary. So let's modify
> addemployee to delete the old chief secretary from the list if another one
> is added." Clearly this is a catastrophic approach to program design. A
> function called addemployee() mustn't delete any employees.
>
> But this doesn't differ in principle from a function called compareseniority()
> that compares two ekmployeees for seniority. Clearly, the act of comparing them
> shouldn't cause any change. If you need to break ties by giving two employees
> with equal salary and service length a flag to say "I'm notionally more senior than
> her for the purposes of the sort", then it should be called something else.

I don't get your point at all. Functions should do what they say they
do, and functions that shouldn't change their parameters should not
change them. That's all obvious, and not related to what I was writing
about.

And I don't follow your idea of a "tie-breaking flag" - that seems a
really strange concept. If you have some way to order the two items
(employees, in this case), you don't need a flag. If there is no way to
order them, it doesn't matter.

The kind of "logical const, bitwise non-const" change you might see in
real code is when you have an unsorted list, and a function that finds
items on the list. If the code is such that it's likely that you will
need the same item again soon, you might want to keep the list in a
"last recently used" order - when you find an item, you pull it out to
the front of the list. The list is logically unchanged - it's still the
same set of data - but the metadata has changed. Clearly when you are
doing this kind of thing, you need to be strict about how you access the
data - C++'s separation of public and private data and methods provides
better control than C can enforce. (I am not giving any guidance as to
whether it is best to use "const" or not with such data structures in C,
as I think it will depend on many factors.)

>
> A function that violates expectations around const, like the tie-breaking flag
> setting compare, isn't really any different from a function which violates
> expectations in other ways, like the addemployee() function which also
> deletes employees. So const isn't really adding much. It picks up a
> subset of ways in which the function contract could be violated, but
> that is all.
> 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.

On 2023-09-18, Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Kaz Kylheku:
>
>> The declaration of this function could be:
>>
>> void* a_setlen( const void *a, unsigned len );
>>
>> If this function potentially invalidates the original "a"
>> object, such that the caller should capture the returned
>> pointer and stop using the pointer "a", then "const void
>> *" makes no sense.
>
> Yes, after calling: b = a_setlen( a, 55 ); `a' is no longer
> guaranteed to be point to a valid array, and `b' must be used
> thenceforward. This is exactly my case.

Destroying an object is mutation, so the const is a lie.

Note that the free function in ISO C is declared void free(void *),
and not void free(const void *). Same with the old pointer argument
of realloc.

You have to cast away the qualifier to use these functions on
a const pointer.

--
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.

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.

On 2023-09-18, David Brown <david.brown@hesbynett.no> wrote:
> On 18/09/2023 10:53, Anton Shepelev wrote:
>> Tim Rentsch to Anton Shepelev:
>>
>> [an unused variable removed from quoted code:]
>>>> void* a_setlen( void * a, unsigned len )
>>>> { struct meta_t *m ;
>>>>
>>>> m = META ( a );
>>>> m = setlen( m, len );
>>>> if( m != NULL ) a = DATA( m );
>>>> else a = NULL ;
>>>> return a;
>>>> }
>>>
>>> Is there some reason not to write a shorter and simpler
>>> function, such as the function below (please ignore
>>> differences in layout style)
>>>
>>> void*
>>> a_setlen( void *a, unsigned n ){
>>> struct meta_t *const m = setlen( META( a ), n );
>>>
>>> return m ? DATA( m ) : NULL;
>>> }
>>
>> My personal reasons are the following:
>>
>> 1. I prefer not to mix variable declaration and
>> initialisation, but first to declare my data and then
>> to work with it.
>
> Why? I've seen people give good reasons for this habit, and bad reasons
> for it, so I'm curious as to /your/ reasons!
>
>
> 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.

We can copy and paste this in the same function (if for whatever
reason we don't coalesce the two). The point is that there is no
redeclaration of yes:

{
int yes = 1;
setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof yes);
}

We can use goto around the block, without the problem of jumping
around the initializer into a scope where the identifier is visible:

// bad, and error in C++:

if (condition)
goto label;

int x = 42

label: ;

// Okay: entire scope is bypassed, thanks to closing brace:

if (condition)
goto label;

{
int x = 42;
}

label: ;

The declaration-as-statement is a poorly considered misfeature that
panders to programmers whose primary goal is reducing the number of
braces.

Some people really like reducing the braces though, for some reason;
they are not necessarily "bad" programmers.

There is an implementation of Common Lisp called CLISP whose history
goes back to the 1980s. Its core run time is written in C.

Most of the C files are named with a .d suffix, and are preprocessed
to a .c suffix.

The preprocessor is a simple script called "varbrace" which converts
mixed declaration/statement syntax into C90 syntax with the braces
around the nested scopes.

Go figure.

--
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.

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.

--
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.

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!)

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.

This is to avoid changes made to 'd' inside the caller from affecting
the caller's data.

Although this is nothing really to do with optimisation, just common sense.

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.

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).

--
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.

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".

>
> This is to avoid changes made to 'd' inside the caller from affecting
> the caller's data.
>
> Although this is nothing really to do with optimisation,  just common
> sense.
>

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.

On 9/18/2023 1:57 PM, 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.
>
>
>

Dr. Optimization wrt the compiler can help us here?

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?

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?

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? ;^)