On 19/09/2023 10:57, Bart wrote:
> 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.

Yes, but that is invisible to C.

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

No. C is defined in terms of an abstract machine (plus a few specific
implementation-defined behaviours), not by how a particular
implementation might choose to pass objects around. Logically, you have
pass by value - /not/ pass by reference. (Even when you have pointers,
you are passing the pointer by value.) So the implementation has to
give the same effects regardless of how it actually implements the
pass-by-value for structs.

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

Yes.

>
> So that sort of analysis cannot be applied.

Yes.

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

Yes.

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

If that's the way they have designed the API, that's how it works.

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

You can certainly argue that alternatives would be better. Maybe the
calculations and run-time of the functions make the overhead here
insignificant - I don't know the library.

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

Perhaps there are historic reasons - maybe "Camera" used to be quite
small. Maybe the developers feel passing the structs by value is
clearer and it is easier to see what the code is doing, and to avoid
errors, and this is worth the extra overhead. Maybe the developers work
mainly with C++, where you would be likely to use a const reference in
such cases (thus passing a pointer), and translated it directly to C.
You'd have to ask the library developers.

On 19/09/2023 12:54, Malcolm McLean wrote:
> On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote:
>> 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 think I'm going to have to bite the bullet and install a newsreader. A shame
> because Google Groups is in many way the best interface. But it's getting
> unusable.

I don't believe I have previously heard someone suggest that Google
Groups has the best interface! I do appreciate it has /some/ advantages
for some uses (such as searching).

>>
>> No, you must /always/ assume that they might change - unless there is
>> documentation guaranteeing that they don't.
>>
> It's usually obvious which parameters are input and which are output,
> and the only documentation you need is the function name. Things aren't
> formally documented in many programming environments.

Informal documentation - comments in the code - is often fine.

> >
>> 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.)
>>
> And this is a deeply undesireable approach for a programming language
> keyword.

It is not ideal, certainly - but not nearly the problem you make it out
to be.

>>
>>> 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.
>>
> Just because something is invented doesn't mean that you have to use it.

Agreed.

But just because something is imperfect in some cases, does not mean you
should never use it. "const" is extremely helpful - it is helpful to
the people writing the function (by catching mistakes), and helpful to
the people using the function (by making the use of parameters clearer).
The compiler is not able to assume pointer-to-const parameters are
never cast to non-const pointers, but the user of the function might be
able to do so.

> You shouldn't use const on opaque pointers.

You should avoid /anything/ opaque when programming. Every use of "void
*" or "const void *" should be questioned. It /might/ be the best
choice for the task in hand, but often it is laziness. Regardless, if
you know you will not change anything via a pointer parameter, mark it
"const".

> And there's little benefit in
> using const on transparent pointers unless it isn't obvious which pointers
> are modified and which are not.

At the risk of repeating myself ad nauseum, /yes/ you want to mark
pointers as "const" if you are not going to change anything via them.
If you want to know why, re-read my previous posts, or google for it.

Obviously you write your own code the way you want, but I recommend you
join the current century, and maybe learn a bit of modern software
development. The programming world has improved.

On 19/09/2023 11:12, Bart wrote:
> 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.

Did you mean "making 'abc' statically allocated", or "giving 'abc'
program lifetime" here, as distinct from making it a local stack
variable? I'll assume yes, since that makes most sense to me. (The
term "static" is notoriously over-used in C.)

Yes, compilers can put such defined-as-const data into read-only memory.

I don't see how it complicates anything, however.

(Theoretically, that could be done with local non-static consts too. In
practice, it can be done if the initialiser of the const is constant at
compile-time, depending on details of what is done with its address. If
the initialiser varies when the function is run, you'd need a target
that lets you control write access to stack data - weird, but feasible,
and perhaps useful for highly secure systems.)

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

Test programs do not define C - the standards documents defined C.

The standards say that if an object is defined as "const", then any
attempt to modify it is undefined behaviour. An implementation may
allow it, or crash the program, or launch nasal daemons, according to
the day of the week. This applies equally to local const data and
file-scope const data.

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

On 2023-09-19, David Brown <david.brown@hesbynett.no> wrote:
> On 19/09/2023 10:57, Bart wrote:
>> Structs passed 'by-value' on a modern ABI can very possibly be passed
>> by-reference. It depends on the struct details and ABI.
>
> Yes, but that is invisible to C.

Nope! Even passing on the stack is by reference, because there is
a stack pointer which is a reference. Lalala, plugging my ears.

On 9/18/2023 4:37 PM, Ben Bacarisse wrote:
> "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

The const is here as a hint to the compiler and an important part of the
contract for the programmer to strive to uphold. Please do not modify
self, or the const ct_foobar it points to. Fair enough? The programmer
can say, screw that, I am going to cast away the const and do some
things... Well, then missiles get launched at some rather interesting
targets. ;^o

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

Yup.

>
>

On 9/19/2023 2:57 AM, Keith Thompson wrote:
> 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.

>

in the fullness of time... lol

Google says we will get back to you after we are finished counting to
infinity on a step-by-step basis...

;^o

On 9/19/2023 7:54 AM, David Brown wrote:
> On 19/09/2023 12:54, Malcolm McLean wrote:
>> On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote:
>>> 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 think I'm going to have to bite the bullet and install a newsreader.
>> A shame
>> because Google Groups is in many way the best interface. But it's getting
>> unusable.
>
> I don't believe I have previously heard someone suggest that Google
> Groups has the best interface!  I do appreciate it has /some/ advantages
> for some uses (such as searching).
[...]

Searching is pretty good wrt google groups, however its interface is
another story... ;^o

On 19/09/2023 16:10, David Brown wrote:
> On 19/09/2023 11:12, Bart wrote:

>> Making 'abc' static complicates things because some compilers will put
>> it into read-only memory.
>
>
> Did you mean "making 'abc' statically allocated", or "giving 'abc'
> program lifetime" here, as distinct from making it a local stack
> variable?  I'll assume yes, since that makes most sense to me.  (The
> term "static" is notoriously over-used in C.)
>
> Yes, compilers can put such defined-as-const data into read-only memory.
>
> I don't see how it complicates anything, however.
>
>
> (Theoretically, that could be done with local non-static consts too.  In
> practice, it can be done if the initialiser of the const is constant at
> compile-time, depending on details of what is done with its address.  If
> the initialiser varies when the function is run, you'd need a target
> that lets you control write access to stack data - weird, but feasible,
> and perhaps useful for highly secure systems.)
>
>
>> 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.
>
> Test programs do not define C - the standards documents defined C.
>
> The standards say that if an object is defined as "const", then any
> attempt to modify it is undefined behaviour.

Why doesn't this apply to my const struct argument?

You might say that the implementing module could look like this:

void fred(const date);
....
void fred(date d) {... modify elements of d ...}

But a module calling fred() as an external function will see only the
declaration using 'const'.

Is that not enough to persuade a compile that fred will never modify the
struct without causing UB? (I couldn't get gcc to report the
inconsistent use of 'const' above.)

If not, then what is the point of 'const' in the declaration? Because if
it's not good enough for a compiler, it won't be for a human either.

For that matter, what's the point of even this:

extern int puts(const char*);

since the actual definition might have no 'const' at all.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote:
>> 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 think I'm going to have to bite the bullet and install a
> newsreader. A shame because Google Groups is in many way the best
> interface. But it's getting unusable.

Your most recent article showed your correct name in the header. It's
possible that the problem has been corrected. (I presume you haven't
changed your configuration in the last few days.)

Using a newsreader rather than posting through Google Groups is probably
a good idea for other reasons. For one thing, a lot of people filter
out all posts from Google Groups (with or without a whitelist for
specific posters).

If you decide to use an NNTP server and newsreader, eternal-september.org
is pretty good and is the only surviving free NNTP server I know of
(aioe.org appears to be dead). I recommend Gnus if **and only if**
you're comfortable with Emacs; otherwise, Thunderbird seems to be
popular.

[...]

--
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/19/2023 9:55 AM, Kaz Kylheku wrote:
> On 2023-09-19, David Brown <david.brown@hesbynett.no> wrote:
>> On 19/09/2023 10:57, Bart wrote:
>>> Structs passed 'by-value' on a modern ABI can very possibly be passed
>>> by-reference. It depends on the struct details and ABI.
>>
>> Yes, but that is invisible to C.
>
> Nope! Even passing on the stack is by reference, because there is
> a stack pointer which is a reference. Lalala, plugging my ears.

Using a node contained on the stack of a thread that wants to wait via
futex. Well, the node, residing on the stack or per-thread memory, can
be linked into a wait queue. ;^)

Bart <bc@freeuk.com> writes:
> On 19/09/2023 16:10, David Brown wrote:
[...]
>> Test programs do not define C - the standards documents defined C.
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?
>
> You might say that the implementing module could look like this:
>
> void fred(const date);
> ....
> void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.

And "const" on a parameter declaration in a function declaration that's
not part of a definition is semantically meaningless.

> Is that not enough to persuade a compile that fred will never modify
> the struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)

A compiler may *always* assume that a function will not modify an object
that's passed as a parameter, because that's part of the semantics of
C's pass-by-value. The compiler must do whatever is necessary to ensure
correct behavior, typically by making a copy of the argument object.
(Note that the argument isn't necessarily an lvalue, so there might not
be an object to modify.)

> If not, then what is the point of 'const' in the declaration? Because
> if it's not good enough for a compiler, it won't be for a human
> either.

There is very little point in having "const" on a parameter in a
function declaration that's not part of a definition. It's ignored.

See N1570 6.7.6.3p15, which says that when determining compatibility of
function types "each parameter declared with qualified type is taken as
having the unqualified version of its declared type".

Similarly, but due to a different rule, this declaration, even if it's
part of a definition:
void foo(char array[42]);
is equivalent to:
void foo(char *array);
and the 42 is ignored.

(No doubt you think this is a flaw in the language. I don't necessarily
disagree, but I'm not interested in getting into that. I'm describing
the language as it's actually specified.)

> For that matter, what's the point of even this:
>
> extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.

That's very different. That const applies, not to the parameter object,
but to what it points to.

If the "const" were not there:
extern int puts(char*);
then this:
const char *s = "hello";
puts(s);
would be a constraint violation.

--
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-19, Bart <bc@freeuk.com> wrote:
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?

It does; if a function definition's argument is a const struct,
then that may not be modified. Assigning to it is a constraint
violation, and underhanded modification is UB.

The const can be removed without changing the function's type,
updating its declaration or recompiling any callers.

It's entirely a private matter, encapsulated in the function.

> You might say that the implementing module could look like this:
>
> void fred(const date);
> ....
> void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.
>
> Is that not enough to persuade a compile that fred will never modify the
> struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)

This is enough to convince to indicate that the function doesn't modify
the caller's structure without causing UB:

void fred(date);

The ISO C standard makes it clear that qualifiers on the function
parameters in a declaration are ignored; they persuade of nothing.

> If not, then what is the point of 'const' in the declaration? Because if

The point of const in a declaration is to allow verbatim copy and paste of
the declaration from the definition: to obtain a valid declaration from
a valid definition by dropping the { ... } body, replacing it with
a semicolon. That's it.

I would say, it's a poor coding style if written by hand.

It could help with generated code, e.g. by macros.

#define PARAMS (const int x, char *p)

void foo PARAMS; // decl

void foo PARAMS // def
{ }

A text processing tool which scans .c files to generate .h files is
easier to write if it doesn't have to parse parameter lists in
order to remove qualifiers on parameters.

One such tool is the "makeheaders" program written in 1993 by the
SQLite author, and included in the Fossil version control system.
It is hosted here: https://fossil-scm.org/home/file?name=tools/makeheaders.c

I have this:

$ cat qual.c
int x(const int y)
{ return y
}

I run this:

$ ./makeheaders qual.c

Now qual.h has this:

$ cat qual.h
/* This file was automatically generated. Do not edit! */
#undef INTERFACE
int x(const int y);

As you can see, it just copied the declaration verbatim, const and all.

That guy obviously has an opinion: header files in C are a silly convention
and in many cases duplicate material from base source files. Many languages
work fine without header files. Why not automate it.

>baes it's not good enough for a compiler, it won't be for a human either.
>
> For that matter, what's the point of even this:
>
> extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.

No, that const is not on the parameter itself; it's part of the type the
parameter points to. That const isn't optional in the definition.
int f(const char *) is not compatible with int f(char *).

--
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 19/09/2023 23:22, Bart wrote:
> On 19/09/2023 16:10, David Brown wrote:
>> On 19/09/2023 11:12, Bart wrote:
>
>>> Making 'abc' static complicates things because some compilers will
>>> put it into read-only memory.
>>
>>
>> Did you mean "making 'abc' statically allocated", or "giving 'abc'
>> program lifetime" here, as distinct from making it a local stack
>> variable?  I'll assume yes, since that makes most sense to me.  (The
>> term "static" is notoriously over-used in C.)
>>
>> Yes, compilers can put such defined-as-const data into read-only memory.
>>
>> I don't see how it complicates anything, however.
>>
>>
>> (Theoretically, that could be done with local non-static consts too.
>> In practice, it can be done if the initialiser of the const is
>> constant at compile-time, depending on details of what is done with
>> its address.  If the initialiser varies when the function is run,
>> you'd need a target that lets you control write access to stack data -
>> weird, but feasible, and perhaps useful for highly secure systems.)
>>
>>
>>> 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.
>>
>> Test programs do not define C - the standards documents defined C.
>>
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?

Think about how function calls actually happen. Consider this possible
code :

// Part of "fred.c", separately compiled
void fred(date x)
{ ... do something with x ...
}

// Part of "foo.c", separately compiled

extern void fred(const date y);

void foo(void) {
const date dd = { 1, 2, 3 };

fred(dd);

... do something more with dd ...
}

You can think of parameter passing and function calling as being roughly
like this transform :

void foo(void) {
const date dd = { 1, 2, 3 };

// Call to fred(dd), with void fred(const date y)
{
// Assign the parameters, done within "foo"
const date y = dd;

// The function itself, defined void fred(date x)
date x = y;
{
// The body of fred()

... do something with x ...
}

}

... do something more with dd ...
}

The actual creation of the "virtual local variables", if I may call them
that, is done within the context of the caller - but they are used
within the called function. Compilers would not have to make two sets
of virtual local variables - only one set must be made. But the C
standards describe the conversions as being "the arguments are
implicitly converted, as if by assignment".

Note that here I have, just for fun, declared "fred" with a non-const
parameter and defined it with a const parameter. This is fine in C -
the qualifiers are ignored when considering the compatibility of
function signatures and when setting the parameters.

So inside "fred", the function can change the parameter "x". It can do
that even though the declaration that "foo" saw was for a "const"
parameter. As parameter passing is done semantically as though by
assignment, that's fine - it's using its own local copy, independent of
the original "dd" in the calling function. This is the case even if the
parameter is passed on the stack rather than in registers. But it means
that "foo" has to make a copy of "dd" to pass to the function - it can't
pass a pointer to the original "dd" and hope the called function does
not change it.

To be clear - I'd be happier if parameter qualifiers /were/ required to
match in all declarations and definitions of a function. I'd be happier
if modifying a "const" parameter in function was undefined behaviour,
even if you used "loopholes" via pointer casts. That would allow some
additional optimisations, such as avoiding extra copies in some
situations, and would be more consistent IMHO.

>
> You might say that the implementing module could look like this:
>
>    void fred(const date);
>    ....
>    void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.
>

Yes.

> Is that not enough to persuade a compile that fred will never modify the
> struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)

No, sorry.

>
> If not, then what is the point of 'const' in the declaration? Because if
> it's not good enough for a compiler, it won't be for a human either.

There is no point in having "const" (or "volatile") qualifiers on
parameters. (You can usefully - often very usefully - have qualifiers
on pointed-to types. "int * const p" is pointless for a parameter in a
declaration, but "const int * p" is entirely different.)

You can, if you like, put a "const" qualifier on a parameter in a
function definition - it will stop you accidentally changing it in the
function body.

>
> For that matter, what's the point of even this:
>
>     extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.
>

Pointed-to types are a different matter entirely. "const char *" and
"char *" have very different semantics, and are not compatible parameter
types.

David Brown:

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

It is an active choice, which allows me to use C90, not the
other way round.

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

On 23/09/2023 16:01, Anton Shepelev wrote:
> David Brown:
>
>> 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.
>
> It is an active choice, which allows me to use C90, not the
> other way round.
>

I made a post with multiple reasons why I personally think it is a bad
choice - if you have the opportunity, I think it would be interesting to
hear why you think differently. You could add to that list your reasons
why you think being able to write C90 code is a good thing. (I'm not
saying you are wrong, merely that your preferences are different, and I
am curious as to why.)

David Brown to Anton Shepelev:

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

First of all, I like the philosophy of this approach, which
brings Wirth's equation:

Algorithms + Data Structures = Programs

down the very bottom, where I separate variables (data) and
operations upon them (algorithms). Some specific reasons
are:

1. The ability to maintain at the start of function body
a TOC-like three-column table with variable name, its
type, and a descriptive comment. Below you mention
your mathematical training, and that is the language
of physics, which reminds of me of the classic papers
by Thelle & Small on loudspeaker modelling, which
begin their analysis by listing all the symbols used
togher with their types (physical units) and
annotations.

2. Upon encountering a new variable, the reader can
glance at the top of function to find its type and
desctiption, whereas intermixed style is requires
scanning the entire text, unless, of course, you count
IDE helper tools, which I do not. Code should read
smooth off a printed page.

3. Interleaved initialisation makes the code visually
ragged and uneven -- to my taste. The declarations
"data" it works with are scatterd all over the place.

4. When maintaining a unified section with declarations
becomes uncomfortable -- it is a natural signal the
function should be split or otherwise simplified.

5. I use `goto' rather intensively to linearise or
flatten unnecessarily nested code. (Deep nesting can
be natural, in which case decreasing it with `goto' is
wrong.)

Bart here has inventively come up with a set of 13 reasons,
in two posts:

http://al.howardknight.net/?ID=155215407800
http://al.howardknight.net/?ID=155215418300

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

Indeed, but then the complier should be able to check this
for you, at least with regard to start-of-scope.

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

Once you know it is `const', yes.

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

If `const' were extended to allow a bare declaration and
then, somewhere below, excactly one assignment, I should be
using it more.

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

Yes, the heavy refactoring of a function is often a two-step
process for me: a. move the code, and then b. move the
declation it depends on. But I prefer to optimise for
reading rather than for writing.

> "Leftovers", such as your "newcap" variable in your
> initial post, are much rarer.

Probably. In the case of `newcap', I thought GCC's -Wall
included the warning about unused variables (and I use
-WError), but it does not.

> * Making new local variables becomes "cheaper" in terms of
> writing the code, and for people reading and
> understanding the code.

Controverisal for me: cheaper in the sense you give, but
dearer me as reader.

> 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 agree that in general, using variables permanently to
store the value they are first assigned makes for more
readable and less error-prone code. I myself often do it at
work, albeit in a language without a concept `const'. As
the function grows longer, the advantages of combined in-
place declaration and initialisation become more apparent,
and start to outweigh the advantages of the alternative
approach (as I see them).

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

You do indeed get this feeling in symbolic math. An
equation is not a process, but a statement of fact, although
it may describe a process, as in differential calculus:

dv = a dt
dx = v dt

That said, I distinguish statments of fact (inlcuding
invariants) from statements of action -- executable pieces
of code that change the state of the system.

> Obviously in an imperative language like C, you are going
> to update variables in loops,

Yes -- loops and various accumulators.

> but it is, to me, often better to use new const variables
> than to re-use an existing variable.

Same for me, sans `const'. I reuse the input variable for
return as an experiment in various interpretations of
minimalism. Formally, the function returns a new array, but
from the user perspective and accroding to its name, it
modifies the array, whereas the need to return a potentially
changed pointer is a technicality.

> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
>
> However, your layout for "if" statements is, IMHO,
> appalling. (Everything here is very much IMHO.)

And I think it precise, concise, and clean. It nicely
emphasizes the structural parts of the `if' operator. If
the exprssions are longer, I use these alternatives:

if( short_condition() ) long_long_long_long_expression ();
else very_long_long_long_long_expression();

if( long_long_long_long_long_long_condition() )
super_long_long_long_long_long_long_long_long_expression() ; else
ultra_long_long_long_long_long_long_long_long_long_expression();

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

For reasons of safety? To have the same thing expressed
twice -- via indentation and via (redundant) braces?

> I would also expect far better use of white space (though
> I realise that is much more personal style) :

Do you mean vertical spacing?

> void * setlen(void * a, unsigned int len)
> {
> meta_t * m1 = META(a);
> meta_t * m2 = setlen(m1, len);
> if (m2) {
> return DATA(m); /* Ant: did you mean m2 ? */
> } else {
> return NULL;
> }
> }

Several lines with but a curly brace on them -- seems ugly
to me. The placement of curly braces gives me the
impression of something prickly. It also works someone
better for non-curly languates, such as Pascal, but then I
tend to put `begin' on a separate line, too.

I understand the style, however, where /both/ opening and
closing braces are put out of the way, that is:

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

This is consistent, and with transparent intent. I see no
reason in an empty (except for the solitary brace) line
between the function declaraion and definition, although
there must be a line before the declaraiton, to separate the
function the previous one.

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

Somebody here or elsewhere expressed a preference for
un-#typedef'd structs because they did (or do, pardon my
English?) not conceal the nature of the type. But you are
probably right, for programming deals with complexity by
slicing it into layers of abstraction, in order on each
level to work with the simplest and smallest necessary
interface with the layer below, so that `struct' may be
safely hidden as a detail from a lower layer.

Ben Bacarisse to Anton Shepelev:

> > Ben Bacarisse:
> >
> > > If this function does what I think it does,
> >
> > Did you read or watch Princess Bride?
>
> Eh?

I couldn't help a refence to Princess Bride -- a fairy tale
by William Goldman, which has a similar phrase line both in
the book and movie:

https://www.youtube.com/watch?v=dTRKCXC0JFg
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

David Brown:

> I made a post with multiple reasons why I personally think
> it is a bad choice -- if you have the opportunity, I think
> it would be interesting to hear why you think differently.
> You could add to that list your reasons why you think
> being able to write C90 code is a good thing. (I'm not
> saying you are wrong, merely that your preferences are
> different, and I am curious as to why.)

Yes, I remembered it. Answered five or so minutes ago, but
(I fear) not to your satisfaction...

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

On 23/09/2023 17:05, Anton Shepelev wrote:

>> 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"
>
> You do indeed get this feeling in symbolic math. An
> equation is not a process, but a statement of fact, although
> it may describe a process, as in differential calculus:
>
> dv = a dt
> dx = v dt
>
> That said, I distinguish statments of fact (inlcuding
> invariants) from statements of action -- executable pieces
> of code that change the state of the system.

This is just an unfortunate consequence of using "=" for assignment.

Elsewhere I use "=" in two main ways, neither of them assignment:

* To define new names for things, with identities known either at
compile-time or before executions starts (eg. define an alias for
a type)

* To test for equality, which is generally done at runtime

But I've also long understood that language syntax is not mathematical
notation.

For assignments that happen after execution starts, I use ":=".

(Using interpreted code run from source, using functions such as eval()
and exec() in a dynamic language, or now constexpr(), blurs the line
between compile-time and run-time. But in my implementations at least,
there is always a compilation step between a source code string, and
evaluating that string.)

On 9/23/23 12:05 PM, Anton Shepelev wrote:
> First of all, I like the philosophy of this approach, which brings
> Wirth's equation: Algorithms + Data Structures = Programs

One thing to point out, "Data Structures" doesn't mean "All Variables in
the program", since "Algorithms", by their nature, tend to create
temporary "internal" state which is part of the algorithm, and not Data
Structures.

When your function implements an "Algorithm", the "Data Structures" it
is working on are the function arguments (or possibly globals) and the
local variables are just the temporary state used to implement the
algorithm.

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

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

I have reflected on these comments and also some of the responses
you have given to other posters. Here are some high-level
reactions (without specifics).

One: all of your preferences basically boil down to "this is
what I'm used to".

Two: you really need to learn new ways of thinking. You won't
see (I predict) the advantages of alternative approaches until
after you have assimilated them. If you don't make an effort to
try and embrace other approaches you'll be caught in a vicious
cycle.

Three: Why should you give any weight to my suggestions? Think
about this: I have been where you are. All of the things you're
saying are things I might have said earlier in my programming
experience. Fortunately I got some guidance from some very smart
people and was able to learn new ways of thinking about programs.

As an exercise try writing a_setlen() like this (and I mean
really try it, put the code in and get it to compile). Don't
complain about how awful it looks, I know it's different from
what you're used to.

void *
ATEM( struct meta_t *m ){
return m ? DATA( m ) : NULL;
}

void*
a_setlen( void *a, unsigned n ){
return ATEM( setlen( META( a ), n ) );
}

Needless to say 'ATEM' is 'META' spelled backwards. If you
think of a more suitable name feel free to use it, otherwise
exactly like this (with my usual caveat to ignore differences
in layout style).

Tim Rentsch:

> One: all of your preferences basically boil down to "this
> is what I'm used to".

Well, I did not say that exactly. Nor did pick my style
from somebody else, but rather arrived at it thought
practice.

> Two: you really need to learn new ways of thinking. You
> won't see (I predict) the advantages of alternative
> approaches until after you have assimilated them.

Allright, I can /try/ alternative approaches in practice,
but /assimilating/ them in course of this trial seems very
hard!

> If you don't make an effort to try and embrace other
> approaches you'll be caught in a vicious cycle.

circle.

> Three: Why should you give any weight to my suggestions?
> Think about this: I have been where you are. All of the
> things you're saying are things I might have said earlier
> in my programming experience. Fortunately I got some
> guidance from some very smart people and was able to learn
> new ways of thinking about programs.

That is a good reason.

> As an exercise try writing a_setlen() like this (and I
> mean really try it, put the code in and get it to
> compile). Don't complain about how awful it looks, I know
> it's different from what you're used to.
>
> void *
> ATEM( struct meta_t *m ){
> return m ? DATA( m ) : NULL;
> }
>
> void*
> a_setlen( void *a, unsigned n ){
> return ATEM( setlen( META( a ), n ) );
> }

Coincidentally, I had already rewritten my code to something
similar in an attempt to generalise a repated parrten:

static void* oper_wrap( struct meta_t* m )
/* An operation wrapper, introduced as an attempt to generalise the */
/* repetitive logic of convering the metadata pointer to the array pointer */
/* and handling the error, a full-fledged lambda emulation via function */
/* pointer having been deemed an overhead: */
{ void *a;
if( m != NULL ) a = DATA( m );
else a = NULL ;
return a;
}

static void * setlen( struct meta_t *m, unsigned len )
/* Set the length of array [m] to [len]: */
{ unsigned newcap;
float factor;

if( len <= m->capacity ) goto Skip; /* no shrinking */

if( len > 1000000 ) factor = 1.19;
else if( len > 10000 ) factor = 1.41;
else factor = 2.00;
newcap = len * factor;
m = setcap( m, newcap );
if( m == NULL ) goto End;
Skip: m->length = len;
End : return m;
}

void* a_setlen( void * a, unsigned len )
{ return oper_wrap( setlen( META(a), len ) ); }

> Needless to say 'ATEM' is 'META' spelled backwards. If
> you think of a more suitable name feel free to use it,
> otherwise exactly like this (with my usual caveat to
> ignore differences in layout style).

Rewriting it your way from the above will be trivial, I will do
it.

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

Anton Shepelev <anton.txt@gmail.moc> writes:
>David Brown to Anton Shepelev:
>
>> > 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!
>
>First of all, I like the philosophy of this approach, which
>brings Wirth's equation:
>
> Algorithms + Data Structures = Programs
>
>down the very bottom, where I separate variables (data) and
>operations upon them (algorithms). Some specific reasons
>are:
>
> 1. The ability to maintain at the start of function body
> a TOC-like three-column table with variable name, its
> type, and a descriptive comment.

Some of the older C coding guidelines were matched by functionality
in vi, such as using '[[' to move to the start of the function
(to examine that 'TOC-like' list) and '``' to return to former
line.

Function definition syntax like:

const char *
get_string(const char *, size_t)
{ }

Allowed searches using '/^get_string' to find a named function definition.

Scott Lurndal to Anton Shepelev:

> > The ability to maintain at the start of function body a
> > TOC-like three-column table with variable name, its
> > type, and a descriptive comment.
>
> Some of the older C coding guidelines were matched by
> functionality in vi, such as using '[[' to move to the
> start of the function (to examine that 'TOC-like' list)
> and '``' to return to former line.

They still there, according do the Vim manual:

The "]" and "[" commands stop at the '{' or '}' in the
first column. This is useful to find the start or end of
a function in a C program. Note that the first character
of the command determines the search direction and the
second character the type of brace found.

`` To the position before the latest jump, or where the
last "m'" or "m`" command was given.

> Function definition syntax like:
>
> const char *
> get_string(const char *, size_t)
> {
> }
>
> Allowed searches using '/^get_string' to find a named
> function definition.

Good idea. Now I have to search for the first occurence of
`get_string('. Another possible trick it to put a space
between the function name and the opeining parethesis in the
definition, but not in invocations.

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

On 23/09/2023 18:05, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>
>>> 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!
>
> First of all, I like the philosophy of this approach, which
> brings Wirth's equation:
>
> Algorithms + Data Structures = Programs
>
> down the very bottom, where I separate variables (data) and
> operations upon them (algorithms).

Wirth's languages tended to have strong separation of data and code.
But remember, the focus of his languages were on two things - being good
for teaching and learning, and being simple to implement (when
optimisation is not important). C does not fit into either category.
Nor do other major languages used for "real" programming. (Of course
there are "real" programs written in Pascal - but for the most part,
you'll see Wirth's languages in academic institutions, not in the
software industry).

Also remember that Wirth wrote that (and languages like Pascal) some
40-50 years ago. We've learned a lot since then, and developed better
coding techniques over time. Wirth's most modern language, Oberon, is
object oriented - data and code are much more integrated and mixed in
such code.

> Some specific reasons
> are:
>
> 1. The ability to maintain at the start of function body
> a TOC-like three-column table with variable name, its
> type, and a descriptive comment. Below you mention
> your mathematical training, and that is the language
> of physics, which reminds of me of the classic papers
> by Thelle & Small on loudspeaker modelling, which
> begin their analysis by listing all the symbols used
> togher with their types (physical units) and
> annotations.

I can see that putting the variables at the start of the function lets
you make a list like that. I cannot, however, see any advantage of
having such a list. Local variables are temporary - they are just there
to hold intermediary results and give convenient names to things so that
it's easier to see what is going on. A list of variables does not aid
understanding of a function - rather, it detracts from it because you
are splitting the information (how the variable is declared, and how it
is used) into two separate parts.

>
> 2. Upon encountering a new variable, the reader can
> glance at the top of function to find its type and
> desctiption, whereas intermixed style is requires
> scanning the entire text, unless, of course, you count
> IDE helper tools, which I do not. Code should read
> smooth off a printed page.

No, you are completely wrong here.

With your style, the reader encountering a new variable has to deal with
two wildly separate parts of the text - the definition at the start of
the function, and the use of the variable in the code. It is particular
bad for large functions or when you have a small screen or window (this
can be the case when you are debugging, for example), and you have to
scroll around.

With my style, everything is there clearly in one spot. No scanning or
searching is needed - it's all there on the same line or two.

>
> 3. Interleaved initialisation makes the code visually
> ragged and uneven -- to my taste. The declarations
> "data" it works with are scatterd all over the place

I write code, I don't draw pictures. The aim is to make things clear to
human programmers reading the code, not to match the aesthetic tastes of
art critics in a gallery. The visual appearance of code matters if -
and only if - it affects the readability.
..
>
> 4. When maintaining a unified section with declarations
> becomes uncomfortable -- it is a natural signal the
> function should be split or otherwise simplified.

That is always the case for functions, no matter the style used.

The reality, however, is often different. Many functions start off
small, but grow bigger than desirable as the code evolves. Your style
gets more and more tedious, uncomfortable, and error-prone, to a much
greater extent than defining local variables as an when they are needed.

This is exasperated by C90 styles from the days of weaker compilers and
no "inline" functions, when people wrote longer functions and hideous
function-like macros because splitting up functions made code slower.

>
> 5. I use `goto' rather intensively to linearise or
> flatten unnecessarily nested code. (Deep nesting can
> be natural, in which case decreasing it with `goto' is
> wrong.)

Extensive use of "goto" is a strong indicator of poorly structured code,
functions that are far too long, or a programmer doing
"micro-optimisations" that are better left to the compiler. (There are
some types of code for which "goto" makes things clearer, but I think
they are rare.)

And I would say that defining variables at the top of the function is
the worst choice you could have if you use "goto" often. It is better
to consider labelled parts of the function as "sub-functions", each with
their own local variables defined and initialised within their local areas.

>
> Bart here has inventively come up with a set of 13 reasons,
> in two posts:
>
> http://al.howardknight.net/?ID=155215407800
> http://al.howardknight.net/?ID=155215418300
>

I've heard plenty of reasons before, including at least some of Bart's,
but I was interested in /your/ reasons. (Thank you for giving them.)

>> 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.
>
> Indeed, but then the complier should be able to check this
> for you, at least with regard to start-of-scope.

Usually the compiler can, yes. (And if you for some reason have to work
with poorer quality compilers, you can use additional linters or other
compilers for such static checks.) But while it's easy for a compiler
to jump around the code, I'd rather human programmers did not have to do
so. That's the focus here - the /human/ knows that the variable is
always valid. They don't have to wonder if it has been set yet, no
matter where they look in the code.

>
>> * 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.
>
> Once you know it is `const', yes.
>
>> 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.
>
> If `const' were extended to allow a bare declaration and
> then, somewhere below, excactly one assignment, I should be
> using it more.

From what you've written so far, I don't see any significant features
of your style that could not be accomplished equally well by comments.
Why not write (formatted however you prefer) :

// int sum_sq - holds the sum of the squares

at the top of the function, and then

const int sum_sq = x * x + y * y;

in the code?

Or even use doxygen format (with "\var")? You only need to document the
important local variables that help the reader understand the code, not
the little ones whose use is obvious.

>
>> * 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.
>
> Yes, the heavy refactoring of a function is often a two-step
> process for me: a. move the code, and then b. move the
> declation it depends on. But I prefer to optimise for
> reading rather than for writing.
>

So do I - that's why I avoid your style of coding. I realise writing
style is often very personal - but remember that /reading/ is much less
personal. /You/ may find it easier to read ancient Greek than English,
but most programmers do not. Similarly, "optimising for reading" must
concern itself with /other/ programmers. Imagine someone who learned C
a mere 20 years ago and reads everything on screens, rather than someone
who sees C and fanfold paper printouts as a step up from FORTRAN and
punched cards.