On 07/02/2024 13:01, David Brown wrote:
> On 07/02/2024 09:59, Malcolm McLean wrote:
>> On 07/02/2024 07:54, David Brown wrote:
>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>
>>>>> They reuse "temp" variables instead of making new ones.
>>>>
>>>> I like to limit the scope of my temporary variables. In C, this is
>>>> as easy
>>>> as sticking a pair of braces around a few statements.
>>>
>>> Generally, you want to have the minimum practical scope for your
>>> local variables.  It's rare that you need to add braces just to make
>>> a scope for a variable - usually you have enough braces in loops or
>>> conditionals - but it happens.
>>>
>> The two common patterns are to give each variable the minimum scope,
>> or to decare all variables at the start of the function and give them
>> all function scope.
>>
>> The case for minimum scope is the same as the case for scope itself.
>> The variable is accessible where it is used and not elsewhere, which
>> makes it less likely it will be used in error, and means there are
>> fewer names to understand.
>>
>
> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error.  It is very much
> easier for automatic tools (static warnings) to spot issues.
>
>> However there are also strong arguments for ducntion scope.
>
> Not in my experience and in my opinion.
>
>> A function is a natural unit.
>
> True, but irrelevant.
>
>> Adn all the varibales used in that unit are listed together and,
>> ideally, commented.
>
> In reality, not commented.  And if commented, then commented incorrectly.
>
> Rather than trying to write vague comments to say what something is how
> it is used, it is better to write the code so that it is clear.  Giving
> variables appropriate names is part of that.  For the most part, I'd say
> if you think a variable needs a comment, your code is not clear enough
> or has poor structure.
>
> It is /massively/ simpler and clearer to write :
>
>     for (int i = 0; i < 10; i++) { ... }
>
> than
>
>     int i;
>
>     /* ... big gap ... */
>
>     for (i = 0; i < 10; i++) { ... }
>
> It doesn't help if you have "int loop_index;" or add a comment to the
> variable definition.  Putting it at the loop itself is better.
>
>
>> So at a glance you can see what is in scope and what is being operated
>> on. And there are only three levels of scope. A varibale is global, or
>> it is file scope, or it is scoped to the function.
>
> Every block is a new scope.  Function scope in C is only for labels.
>
>>
>> I tend to prefer function scope for C. However I use a lot of C++
>> these days, and in C++ local scope is often better, and in some cases
>> even necessary. So I find that I'm tending to use local scope in C more.
>>

We could have 'malcolm-scope' ?!

(sorry :) )

>
> I hate having to work with code written in long-outdated "declare
> everything at the top of the function" style.  I realise style and
> experience are subjective, but I have not seen any code or any argument
> that has led me to doubt my preferences.
>
>
>

On 07/02/2024 12:04, bart wrote:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>>> However there are also strong arguments for function scope. A
>>> function is a
>>> natural unit. And all the variables used in that unit are listed
>>> together
>>> and, ideally, commented. So at a glance you can see what is in scope and
>>> what is being operated on. [typos fixed]
>>
>> You should not need an inventory of what's being operated on.  Any
>> function so complex that I can't tell immediately what declaration
>> corresponds to which name needs to be re-written.
>
> But if you keep functions small, eg. the whole body is visible at the
> same time, then there is less need for declarations to clutter up the
> code. They can go at the top, so that you can literally can just glance
> there.
>

With a small enough function, the benefits of minimum practical scope
(or "define on first use") are reduced, but not removed. The perceived
benefits of "declare everything at the start of the function" disappear
entirely.

>>> And there are only three levels of scope. A
>>> varibale is global, or it is file scope, or it is scoped to the
>>> function.
>
>> You are mixing up scope and lifetime.  C has no "global scope".  A name
>> may have external linkage (which is probably what you are referring to),
>> but that is not directly connected to its scope.
>
> Funny, I use the same definitions of scope:
>

For discussions of C, it's best to use the well-defined C terms for
scope and lifetime. Other languages may use different terms.

On 07/02/2024 13:01, David Brown wrote:
> On 07/02/2024 09:59, Malcolm McLean wrote:
>>
>> The case for minimum scope is the same as the case for scope itself.
>> The variable is accessible where it is used and not elsewhere, which
>> makes it less likely it will be used in error, and means there are
>> fewer names to understand.
>>
>
> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error.  It is very much
> easier for automatic tools (static warnings) to spot issues.
>
This is all true, but only in way. Whilst it's easier to see that there
are errors in one way, because you have to look at a smaller section of
code, it's harder in others, for example because that small section is
more cluttered. From experience with automatic tools, they give too many
false warnings for correct code, and then programmers often rewrite the
code less clearly to suppress the warning.
>> However there are also strong arguments for ducntion scope.
>
> Not in my experience and in my opinion.
>
That's not a legitimate response. The correct thing to say is "you have
given a argment there but I don't think it is strong one". Unless you
are claiming to be experieenced in arguing with people over scope, and I
donlt think that is what yiu mean to say,

>> A function is a natural unit.
>
> True, but irrelevant.
>
>> Adn all the varibales used in that unit are listed together and,
>> ideally, commented.
>
> In reality, not commented.  And if commented, then commented incorrectly.
>
Variable names mean something. The classic name for a variable is "x".
This usually means either "the value that is given" or "the horizontal
value on an axis". But it can of ciurse mean "a value which we shall
calculate that doesn;t have an abvous other name", or even maybe, "the
nunber of times the letter "x" appears in the data. It depnds on
context. However the imprtant thing is that x should always mean the
same thing within the same function. So if it's a real on the horizontal
axis of a graph, we don't also use "x" for an integer we need to
factorise, in the same function. And if it isn't clear, (x is such a
strong convention that it seldom needs a comment), we need to say how
"x" is being used and what it means in that function. Function and not
block is the unit for that.

>
> Rather than trying to write vague comments to say what something is how
> it is used, it is better to write the code so that it is clear.  Giving
> variables appropriate names is part of that.  For the most part, I'd say
> if you think a variable needs a comment, your code is not clear enough
> or has poor structure.
>
I prefer short variable names because it is the mathematical convention
and because it makes complex expressions easier to read. But of course
then they can't be as meaningful. So to use a short name and add a
comment is reasonable way to achieve both goals.
>
> It is /massively/ simpler and clearer to write :
>
>     for (int i = 0; i < 10; i++) { ... }
>
> than
>
>     int i;
>
>     /* ... big gap ... */
>
>     for (i = 0; i < 10; i++) { ... }
>
> It doesn't help if you have "int loop_index;" or add a comment to the
> variable definition.  Putting it at the loop itself is better.
>
This pattern is quite common in C.

for (i = 0; i < N; i++)
if (x[i] == 0)
break;
if (i == N) /* no zero found */

So you can't scope the counter to the loop.

i is always a loop index. Usually I just out one at the top so it is
hanging around and handy.
>
>
> I hate having to work with code written in long-outdated "declare
> everything at the top of the function" style.  I realise style and
> experience are subjective, but I have not seen any code or any argument
> that has led me to doubt my preferences.
>
I quite often work with code which was written a very long time ago and
is still useful. That's one of the big strengths of C. It is subjective
however. It's not about making life easier for the compiler. It's about
what is clearer. That depends on the way people read code and think
about it, and that won't necessarily be the same for every person.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 07/02/2024 13:44, Malcolm McLean wrote:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 07/02/2024 07:54, David Brown wrote:
>>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>>
>>>>>> They reuse "temp" variables instead of making new ones.
>>>>>
>>>>> I like to limit the scope of my temporary variables. In C, this is as
>>>>> easy
>>>>> as sticking a pair of braces around a few statements.
>>>> Generally, you want to have the minimum practical scope for your local
>>>> variables.  It's rare that you need to add braces just to make a scope
>>>> for a variable - usually you have enough braces in loops or
>>>> conditionals
>>>> - but it happens.
>>>>
>>> The two common patterns are to give each variable the minimum scope,
>>> or to
>>> decare all variables at the start of the function and give them all
>>> function scope.
>>
>> The term "function scope" has a specific meaning in C.  Only labels have
>> function scope.  I know you are not very interested in using exact
>> terms, but some people might like to know the details.
>>
> To explain this, if we have
>
> void function(void)
> {
>    int i;
>
>    for (i = 0; i < 10;; i++)
>       dosomething();
>    if ( condition)
>    {
>       int i;
>
>       for (i = 0; i < 11; i++)
>          dosomething();
>       if (i == 10)
>         /* always false */
>    }
> }
>
> The first i is not in scope when we test for i == 10 and the test will
> be false. So "fucntion scope" isn't the term.

"Function scope" is not the term, because - as has been explained to you
- "function scope" has a specific meaning in C, and this is not it.

Everyone can figure out what you are trying to say - you mean the
outermost block scope of the function. It's just block scope, as normal.

(By the way, you do know that Thunderbird has a pretty good spell
checker? I don't want to get hung up on this, and don't want to start a
new branch or argument, but avoiding the silly typos in your posts would
improve them.)

>
> However if we have this:
>
> void fucntion(void)
> {
>    label:
>    dosomething();
>    if (condition)
>    {
>       label:
>       dosomething();
>    }
>    got label:
> }
>
> Then it is a error. Both labels are in scope and that isn't allowed.

Yes, that's because labels have function scope in C.

>
>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I expect
> that at this point someone will jump in and say it must be "Malcolm
> scope". As you say, it's common enough to need a term for it.
>

We don't need a new term. We have the terms in the C standards. Block
scope is fine.

Note that there is another very big difference between "function scope"
and "block scope". Labels in function scope are in scope within the
function, even before they are declared. For identifiers in block
scope, their scope does not start until they are declared.

>
>>> The case for minimum scope is the same as the case for scope itself.
>>
>> Someone might well misinterpret the term "minimum scope" since it would
>> require adding lots of otherwise redundant braces.  I *think* you mean
>> declaring names at the point of first use.  The resulting scope is not
>> minimum because it often extends beyond the point of last use.
>>
>
> Yes, I don't mean literally the minimum scope that would be possible by
> artificially ending a block when a variable is used for the last time.
> No one would do that. I mean that the variable is either declared at
> point of first use or, if this isn't allowed because of the C version,
> at the top of the block in which it is used. But also that variables are
> not reused if in fact the value is discarded between statements or
> especially between blocks.
>
>> Other people, not familiar with" modern" C, might interpret the term to
>> mean declaring names at the top of the inner-most appropriate block.
>>
> Top of the block or point of first use?

In C90, you have to declare your variables before any statements within
the block. In C99, you can intermingle declarations and statements.
Thus even in C90, you can still have top of block declarations.

>>> The
>>> variable is accessible where it is used and not elsewhere, which
>>> makes it
>>> less likely it will be used in error, and means there are fewer names to
>>> understand.
>>
>> The case for declaration at first use is much stronger than this.  It
>> almost always allows for a meaningful initialisation at the same point,
>> so the initialisation does not need to be hunted down a checked.  For
>> me, this is a big win.  (Yes, some people then insist on a dummy
>> initialisation when the proper one isn't know, but that's a fudge that
>> is, to my mind, even worse.)
>>
> If you go for top of block and you don't have a value, you either
> intialise, usually to zero, or leave it wild. Neither is ideal.

Leaving it uninitialised is /much/ better, unless you are using weak
tools or don't know how to use them properly. (There can be
circumstances where code is too complex for compilers to be sure that a
variable is never used uninitialised, and you might find it appropriate
to give a dummy initialisation in that case. But such cases are rare.)

Even better, of course, is not to declare the variable at all until you
have something sensible to put in it. (And then consider making it
"const" if it does not change.)

> But it
> rarely makes a big difference. However if you go for policy two, all the
> variables are either given initial values at the top of the function or
> they are not given initial values at the top of the function,and so you
> can easily check, and ensure that all the initial values are consistent
> woth each other.
>

If you declare your variables when you have a value for them, then the
initial values are all clear and consistent, and have no artificial
values, and in many cases, they never change. Having your variables
unchanging makes code /much/ easier to understand and check for correctness.

>>
>> We could call it outer-most block scope rather than re-use a term with
>> an existing, but different, technical meaning.
>>
> The variable has scope within the function, within the whole of the
> function, and the motive is that the function is the natural unit of
> thought. So I think we need the word "function".

No, we don't. And no, the scope is /not/ the entire function.

>
>>> However I use a lot of C++ these
>>> days, and in C++ local scope is often better, and in some cases even
>>> necessary. So I find that I'm tending to use local scope in C more.
>>
>> Interesting.  Is it just that using C++ has given you what you would
>> think of as a bad habit in C, or has using C++ led you to see that your
>> old preference was not the best one?
>>
>
> Not sure. If I thought it was a terrible habit of course I wouldn't do
> it. I do think it makes the code look a little bit less clear. But it's
> slightly easier to write and hack, which is why I do it.

On 07/02/2024 11:04, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> Making some "temp" variables and re-using them was also common for some
>> people in idiomatic C90 code, where all your variables are declared at the
>> top of the function.
>
> The comma suggests (I think) that it is C90 that mandates that all one's
> variables are declared at the top of the function. But that's not the
> case (as I am sure you know).

Yes.

> The other reading -- that this is done in
> idiomatic C90 code -- is also something that I'd question, but not
> something that I'd want to argue.

"Idiomatic" is perhaps not the best word. (And "idiotic" is too
strong!) I mean written in a way that is quite common in C90 code.

>
> I comment just because there seems to be a myth that "old C" had to have
> all the declarations at the top of a function. That was true once, but
> so long ago as to be irrelevant. Even K&R C allowed declarations at the
> top of a compound statement.
>

It's good to make it clear.

On 07/02/2024 11:09, Michael S wrote:
> On Wed, 7 Feb 2024 08:56:15 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 07/02/2024 00:24, Lawrence D'Oliveiro wrote:
>>> On Tue, 6 Feb 2024 09:50:02 +0100, David Brown wrote:
>>>
>>>> And of course there are those two or three unfortunate people that
>>>> have to work with embedded Windows.
>>>
>>> I thought this has pretty much gone away, pushed aside by Linux.
>>
>> It was never common in the first place, and yes, it is almost
>> entirely non-existent now. I'm sure there are a few legacy products
>> still produced that use some kind of embedded Windows, but few more
>> than that
>> - which is what I was hinting at in my post.
>>
>
> Is there any digital oscilloscope that is not Windows under the hood?

Yes, most that I know of. (There are some older ones that are Windows,
and high-end ones almost never used Windows.)

> How about medical equipment?

A great deal.

> The first question is mostly rhetorical, the second is not.
>

It used to be more common to have embedded Windows. Embedded Linux, and
RTOS's with GUI's (using, for example, QT) have long ago taken over.

There are some hold-outs, of course - no company wants to re-do their
systems and software if they can avoid it, and if they made the bad bet
to use embedded Windows before, they may stick to it.

On 07/02/2024 13:21, David Brown wrote:
> On 07/02/2024 12:04, bart wrote:

>> Funny, I use the same definitions of scope:
>>
>
> For discussions of C, it's best to use the well-defined C terms for
> scope and lifetime.  Other languages may use different terms.

Many of the terms used in the C grammar remind me exactly of the 'twisty
little passages' variations from the original text Adventure game.

In my program, I choose to use identifiers that make more sense to me,
and that match my view of how the language works.

On 07/02/2024 14:42, Malcolm McLean wrote:
> On 07/02/2024 13:01, David Brown wrote:
>> On 07/02/2024 09:59, Malcolm McLean wrote:
>>>
>>> The case for minimum scope is the same as the case for scope itself.
>>> The variable is accessible where it is used and not elsewhere, which
>>> makes it less likely it will be used in error, and means there are
>>> fewer names to understand.
>>>
>>
>> It makes code simpler, clearer, easier to reuse, easier to see that it
>> is correct, and easier to see if there is an error.  It is very much
>> easier for automatic tools (static warnings) to spot issues.
>>
> This is all true, but only in way. Whilst it's easier to see that there
> are errors in one way, because you have to look at a smaller section  of
> code, it's harder in others, for example because that small section is
> more cluttered.

No, it is not - unless you write it very badly.

> From experience with automatic tools, they give too many
> false warnings for correct code, and then programmers often rewrite the
> code less clearly to suppress the warning.

You need to use good tools, and you need to know how to use them. It is
unfortunately the case that some people are poor programmers - they
write bad code, and they don't know how to get the best from their tools.

But is that an excuse for /you/ not to write the best code you can, in
the clearest and most maintainable manner, using the best practical
tools to help catch any errors?

>>> However there are also strong arguments for ducntion scope.
>>
>> Not in my experience and in my opinion.
>>
> That's not a legitimate response. The correct thing to say is "you have
> given a argment there but I don't think it is strong one".

My experience and opinion is that there are no strong arguments in
favour of "all declarations at the top of the function." That is what I
meant to say, and it is a legitimate response.

> Unless you
> are claiming to be experieenced in arguing with people over scope, and I
> donlt think that is what yiu mean to say,
>

/Please/ get a spell checker! Or type more carefully.

>>> A function is a natural unit.
>>
>> True, but irrelevant.
>>
>>> Adn all the varibales used in that unit are listed together and,
>>> ideally, commented.
>>
>> In reality, not commented.  And if commented, then commented incorrectly.
>>
> Variable names mean something. The classic name for a variable is "x".
> This usually means either "the value that is given" or "the horizontal
> value on an axis". But it can of ciurse mean "a value which we shall
> calculate that doesn;t have an abvous other name", or even maybe, "the
> nunber of times the letter "x" appears in the data. It depnds on
> context. However the imprtant thing is that x should always mean the
> same thing within the same function.

No.

The important thing is that the purpose of a variable should be clear
within its scope and use. It is completely artificial to suggest it
should be consistent within a function - you could equally well say it
should be consistent within a file, or within a block.

> >
>> Rather than trying to write vague comments to say what something is
>> how it is used, it is better to write the code so that it is clear.
>> Giving variables appropriate names is part of that.  For the most
>> part, I'd say if you think a variable needs a comment, your code is
>> not clear enough or has poor structure.
>>
> I prefer short variable names because it is the mathematical convention
> and because it makes complex expressions easier to read. But of course
> then they can't be as meaningful. So to use a short name and add a
> comment is reasonable way to achieve both goals.

Or, far better, use small scopes and then variables can have short names
without comments and be clear.

>>
>> It is /massively/ simpler and clearer to write :
>>
>>      for (int i = 0; i < 10; i++) { ... }
>>
>> than
>>
>>      int i;
>>
>>      /* ... big gap ... */
>>
>>      for (i = 0; i < 10; i++) { ... }
>>
>> It doesn't help if you have "int loop_index;" or add a comment to the
>> variable definition.  Putting it at the loop itself is better.
>>
> This pattern is quite common in C.
>
> for (i = 0; i < N; i++)
>   if (x[i] == 0)
>      break;
> if (i == N) /* no zero found */
>

If you need to do that, you need a bigger scope for "i". But it would
be insane to use worse code style for 95% of your loops for the 5% (or
less) that need this.

> So you can't scope the counter to the loop.
>
> i is always a loop index. Usually I just out one at the top so it is
> hanging around and handy.

Laziness is not good.

> >
>>
>> I hate having to work with code written in long-outdated "declare
>> everything at the top of the function" style.  I realise style and
>> experience are subjective, but I have not seen any code or any
>> argument that has led me to doubt my preferences.
>>
> I quite often work with code which was written a very long time ago and
> is still useful. That's one of the big strengths of C. It is subjective
> however. It's not about making life easier for the compiler. It's about
> what is clearer. That depends on the way people read code and think
> about it, and that won't necessarily be the same for every person.
>

David Brown <david.brown@hesbynett.no> writes:

> On 07/02/2024 11:04, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> Making some "temp" variables and re-using them was also common for some
>>> people in idiomatic C90 code, where all your variables are declared at the
>>> top of the function.
>> The comma suggests (I think) that it is C90 that mandates that all one's
>> variables are declared at the top of the function. But that's not the
>> case (as I am sure you know).
>
> Yes.
>
>> The other reading -- that this is done in
>> idiomatic C90 code -- is also something that I'd question, but not
>> something that I'd want to argue.
>
> "Idiomatic" is perhaps not the best word. (And "idiotic" is too strong!)
> I mean written in a way that is quite common in C90 code.

The most common meaning of "idiomatic", and the one I usually associate
with it in this context, is "containing expressions that are natural and
correct". That's not how I would describe eschewing declarations in
inner blocks.

--
Ben.

bart <bc@freeuk.com> writes:

> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>>> However there are also strong arguments for function scope. A function is a
>>> natural unit. And all the variables used in that unit are listed together
>>> and, ideally, commented. So at a glance you can see what is in scope and
>>> what is being operated on. [typos fixed]
>> You should not need an inventory of what's being operated on. Any
>> function so complex that I can't tell immediately what declaration
>> corresponds to which name needs to be re-written.
>
> But if you keep functions small, eg. the whole body is visible at the same
> time, then there is less need for declarations to clutter up the code. They
> can go at the top, so that you can literally can just glance there.

Declarations don't clutter up the code, just as the code does not
clutter up the declarations. That's just your own spin on the matter.
They are both important parts of a C program.

>>> And there are only three levels of scope. A
>>> varibale is global, or it is file scope, or it is scoped to the
>>> function.
>
>> You are mixing up scope and lifetime. C has no "global scope". A name
>> may have external linkage (which is probably what you are referring to),
>> but that is not directly connected to its scope.
>
> Funny, I use the same definitions of scope:

You can use any definition you like, provided you don't insit that other
use your own terms. I was just pointing out that the problems
associated with using the wrong terms in a public post.

I'll cut the text where you use the wrong terms, because there is
nothing to be gained from correcting your usage.

--
Ben.

On 07/02/2024 15:30, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/02/2024 11:04, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> Making some "temp" variables and re-using them was also common for some
>>>> people in idiomatic C90 code, where all your variables are declared at the
>>>> top of the function.
>>> The comma suggests (I think) that it is C90 that mandates that all one's
>>> variables are declared at the top of the function. But that's not the
>>> case (as I am sure you know).
>>
>> Yes.
>>
>>> The other reading -- that this is done in
>>> idiomatic C90 code -- is also something that I'd question, but not
>>> something that I'd want to argue.
>>
>> "Idiomatic" is perhaps not the best word. (And "idiotic" is too strong!)
>> I mean written in a way that is quite common in C90 code.
>
> The most common meaning of "idiomatic", and the one I usually associate
> with it in this context, is "containing expressions that are natural and
> correct". That's not how I would describe eschewing declarations in
> inner blocks.
>
No. It means writing the code in a way which is common in C and has
certain advantages, but is not so in other languages.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 07/02/2024 07:54, David Brown wrote:
>>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>>
>>>>>> They reuse "temp" variables instead of making new ones.
>>>>>
>>>>> I like to limit the scope of my temporary variables. In C, this is as
>>>>> easy
>>>>> as sticking a pair of braces around a few statements.
>>>> Generally, you want to have the minimum practical scope for your local
>>>> variables.  It's rare that you need to add braces just to make a scope
>>>> for a variable - usually you have enough braces in loops or conditionals
>>>> - but it happens.
>>>>
>>> The two common patterns are to give each variable the minimum scope, or to
>>> decare all variables at the start of the function and give them all
>>> function scope.
>> The term "function scope" has a specific meaning in C. Only labels have
>> function scope. I know you are not very interested in using exact
>> terms, but some people might like to know the details.
>>
> To explain this, if we have

What is the "this" that you are explaining?

> void function(void)
> {
> int i;
>
> for (i = 0; i < 10;; i++)
> dosomething();
> if ( condition)
> {
> int i;
>
> for (i = 0; i < 11; i++)
> dosomething();
> if (i == 10)
> /* always false */
> }
> }
>
> The first i is not in scope when we test for i == 10 and the test will be
> false. So "fucntion scope" isn't the term.

"function scope" is not the term because only labels have function
scope. This example does not explain anything about the term
"functions scope" -- even why it's the wrong term.

> However if we have this:
>
> void fucntion(void)
> {
> label:
> dosomething();
> if (condition)
> {
> label:
> dosomething();
> }
> got label:
(you mean "goto label;")
> }
>
> Then it is a error. Both labels are in scope and that isn't allowed.

The key thing about the scope of labels is that they can be used before
that are defined:

int *f(int *p)
{
if (!p) goto error:
...
error:
return p;
}

>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I expect
> that at this point someone will jump in and say it must be "Malcolm
> scope". As you say, it's common enough to need a term for it.

I see no reason not to call it "the outer-most block scope".

>>> The case for minimum scope is the same as the case for scope itself.
>> Someone might well misinterpret the term "minimum scope" since it would
>> require adding lots of otherwise redundant braces. I *think* you mean
>> declaring names at the point of first use. The resulting scope is not
>> minimum because it often extends beyond the point of last use.
>
> Yes, I don't mean literally the minimum scope that would be possible by
> artificially ending a block when a variable is used for the last time. No
> one would do that. I mean that the variable is either declared at point of
> first use or, if this isn't allowed because of the C version, at the top of
> the block in which it is used. But also that variables are not reused if in
> fact the value is discarded between statements or especially between
> blocks.
>
>> Other people, not familiar with" modern" C, might interpret the term to
>> mean declaring names at the top of the inner-most appropriate block.
>>
> Top of the block or point of first use?

I don't know what you are asking. I was trying to point out these two
possible meanings for "minimum scope".

>>> The
>>> variable is accessible where it is used and not elsewhere, which makes it
>>> less likely it will be used in error, and means there are fewer names to
>>> understand.
>> The case for declaration at first use is much stronger than this. It
>> almost always allows for a meaningful initialisation at the same point,
>> so the initialisation does not need to be hunted down a checked. For
>> me, this is a big win. (Yes, some people then insist on a dummy
>> initialisation when the proper one isn't know, but that's a fudge that
>> is, to my mind, even worse.)
>>
> If you go for top of block and you don't have a value, you either
> intialise, usually to zero, or leave it wild. Neither is ideal. But it
> rarely makes a big difference. However if you go for policy two, all the
> variables are either given initial values at the top of the function or
> they are not given initial values at the top of the function,and so you can
> easily check, and ensure that all the initial values are consistent woth
> each other.

What?

>> We could call it outer-most block scope rather than re-use a term with
>> an existing, but different, technical meaning.
>>
> The variable has scope within the function, within the whole of the
> function, and the motive is that the function is the natural unit of
> thought. So I think we need the word "function".

You need the word function. I don't.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
[...]
>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I
> expect that at this point someone will jump in and say it must be
> "Malcolm scope". As you say, it's common enough to need a term for it.

Please, no, not "Malcolm scope". That's the kind of thing that gets
suggested as a last resort, or as a joke, when you insist on using
existing terminology with your own idiosyncratic meaning.

"Outermost block scope" is a clear and correct description of what
you're talking about. Though what you're probably talking about is
outermost block scope before any statements. Or just "at the top of the
function definition".

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 07/02/2024 07:54, David Brown wrote:
>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>
>>>> They reuse "temp" variables instead of making new ones.
>>>
>>> I like to limit the scope of my temporary variables. In C, this is as
>>> easy
>>> as sticking a pair of braces around a few statements.
>>
>> Generally, you want to have the minimum practical scope for your local
>> variables.  It's rare that you need to add braces just to make a scope
>> for a variable - usually you have enough braces in loops or conditionals
>> - but it happens.
>>
>The two common patterns are to give each variable the minimum scope, or
>to decare all variables at the start of the function and give them all
>function scope.
>
>The case for minimum scope is the same as the case for scope itself. The
>variable is accessible where it is used and not elsewhere, which makes
>it less likely it will be used in error, and means there are fewer names
>to understand.

And it means the compiler can re-use the local storage (if any was
allocated) for subsequent minimal scope variables (or even same scope
if the compiler knows the original variable is never used again),
so long as the address of the variable isn't taken.

David Brown <david.brown@hesbynett.no> writes:
>On 07/02/2024 00:24, Lawrence D'Oliveiro wrote:
>> On Tue, 6 Feb 2024 09:50:02 +0100, David Brown wrote:
>>
>>> And of course there are those two or three unfortunate people that have
>>> to work with embedded Windows.
>>
>> I thought this has pretty much gone away, pushed aside by Linux.
>
>It was never common in the first place, and yes, it is almost entirely
>non-existent now. I'm sure there are a few legacy products still
>produced that use some kind of embedded Windows, but few more than that
>- which is what I was hinting at in my post.

Wind river is still popular, I believe, but the linux kernel + busybox is
probably the most common.

On 07/02/2024 15:36, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 07/02/2024 10:47, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>>> However there are also strong arguments for function scope. A function is a
>>>> natural unit. And all the variables used in that unit are listed together
>>>> and, ideally, commented. So at a glance you can see what is in scope and
>>>> what is being operated on. [typos fixed]
>>> You should not need an inventory of what's being operated on. Any
>>> function so complex that I can't tell immediately what declaration
>>> corresponds to which name needs to be re-written.
>>
>> But if you keep functions small, eg. the whole body is visible at the same
>> time, then there is less need for declarations to clutter up the code. They
>> can go at the top, so that you can literally can just glance there.
>
> Declarations don't clutter up the code, just as the code does not
> clutter up the declarations. That's just your own spin on the matter.
> They are both important parts of a C program.

That sounds like your opinion against mine. It's nothing to do with
spin, whatever that means.

I would argue however that it you take a clear, cleanly written
language-neutral algorithm, and then introduce type annotations /within/
that code rather than segragated, then it is no longer quite as clear or
as clean looking.

As a related example, suppose you had this function:

void F(int a, double* b) {...}

All the parameters are specified with their names and types at the top.
Now imagine if only the names were given, but the types specified only
at their first usage within the body:

void F(a, b) {...}

Now you no longer have an instant picture of the interface to the
function. The declarations could also be shadowed within the body, so
you can't tell whether a definition for 'a' refers to a parameter
without checking for definitions in an outer scope.

Imagine further than even the parameter names were specified within the
body ...

I /like/ having a summary of both parameters and locals at the top. I
/like/ code looking clean, and as aligned as possible (some decls will
push code to the right). I /like/ knowing that there is only one
instance of a variable /abc/, and it is the one at the top.

So it might be my opinion but also my preference.

>>>> And there are only three levels of scope. A
>>>> varibale is global, or it is file scope, or it is scoped to the
>>>> function.
>>
>>> You are mixing up scope and lifetime. C has no "global scope". A name
>>> may have external linkage (which is probably what you are referring to),
>>> but that is not directly connected to its scope.
>>
>> Funny, I use the same definitions of scope:
>
> You can use any definition you like, provided you don't insit that other
> use your own terms. I was just pointing out that the problems
> associated with using the wrong terms in a public post.
>
> I'll cut the text where you use the wrong terms, because there is
> nothing to be gained from correcting your usage.

That's a shame. I think there is something to be gained by not sticking
slavishly to what the C standard says (which very few people will study)
and using more colloquial terms or ones that more can relate to.

Apparently both 'typedef' and 'static' are forms of 'linkage'. But no
identifiers declared with those will ever be linked to anything!

bart <bc@freeuk.com> writes:
>On 07/02/2024 15:36, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 07/02/2024 10:47, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>>> However there are also strong arguments for function scope. A function is a
>>>>> natural unit. And all the variables used in that unit are listed together
>>>>> and, ideally, commented. So at a glance you can see what is in scope and
>>>>> what is being operated on. [typos fixed]
>>>> You should not need an inventory of what's being operated on. Any
>>>> function so complex that I can't tell immediately what declaration
>>>> corresponds to which name needs to be re-written.
>>>
>>> But if you keep functions small, eg. the whole body is visible at the same
>>> time, then there is less need for declarations to clutter up the code. They
>>> can go at the top, so that you can literally can just glance there.
>>
>> Declarations don't clutter up the code, just as the code does not
>> clutter up the declarations. That's just your own spin on the matter.
>> They are both important parts of a C program.
>
>
>That sounds like your opinion against mine. It's nothing to do with
>spin, whatever that means.
>
>I would argue however that it you take a clear, cleanly written
>language-neutral algorithm, and then introduce type annotations /within/
>that code rather than segragated, then it is no longer quite as clear or
>as clean looking.
>
>As a related example, suppose you had this function:
>
> void F(int a, double* b) {...}
>
>All the parameters are specified with their names and types at the top.
>Now imagine if only the names were given,

Now imagine if the moon was made from green cheese. It's just as
likely, and neither are C.

On 07/02/2024 18:26, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 07/02/2024 15:36, Ben Bacarisse wrote

>>> Declarations don't clutter up the code, just as the code does not
>>> clutter up the declarations. That's just your own spin on the matter.
>>> They are both important parts of a C program.
>>
>>
>> That sounds like your opinion against mine. It's nothing to do with
>> spin, whatever that means.
>>
>> I would argue however that it you take a clear, cleanly written
>> language-neutral algorithm, and then introduce type annotations /within/
>> that code rather than segragated, then it is no longer quite as clear or
>> as clean looking.
>>
>> As a related example, suppose you had this function:
>>
>> void F(int a, double* b) {...}
>>
>> All the parameters are specified with their names and types at the top.
>> Now imagine if only the names were given,
>
> Now imagine if the moon was made from green cheese. It's just as
> likely, and neither are C.

It's perfectly possible as an extension. Old C had something similar
that was halfway there.

But it was a hypothetical illustration to elicit a response to this
question: would it make harder to easier to understand what the function
is doing?

Because it is related to whether the locals used by a function are
declared all at the top, or buried within the code at random places.

BTW I've just done a quick survey of some codebases; functions tend to
have 3 local variables on average.

Is really worth spreading them out in nested block scopes?

Here is a histogram for tcc.c: the first column is how many locals, and
the second is how many functions with that number:

0 161
1 118
2 73
3 42
4 29
5 15
6 12
7 14
8 11
9 6
10 9
11 6
12 3
13 5
14 3
16 4
17 1
18 2
19 2
20 1
21 2
25 1
27 1
31 1
32 1
33 1
35 1

In one of my own programs, 92% of functions have 6 locals or fewer. (The
figures includes extra temporary locals created as part of the
transpilation to C.)

On 07/02/2024 15:24, bart wrote:
> On 07/02/2024 13:21, David Brown wrote:
>> On 07/02/2024 12:04, bart wrote:
>
>>> Funny, I use the same definitions of scope:
>>>
>>
>> For discussions of C, it's best to use the well-defined C terms for
>> scope and lifetime.  Other languages may use different terms.
>
> Many of the terms used in the C grammar remind me exactly of the 'twisty
> little passages' variations from the original text Adventure game.
>
> In my program, I choose to use identifiers that make more sense to me,
> and that match my view of how the language works.
>

OK, I suppose. But if you want to talk about C with other people, it
makes sense to use the same terms they are using, in the same way.

I can certainly agree that there are bits of the C standards that are
not as clear as I would like. The definitions of scope are not one of
those parts.

On 07/02/2024 19:05, bart wrote:

> That's a shame. I think there is something to be gained by not sticking
> slavishly to what the C standard says (which very few people will study)
> and using more colloquial terms or ones that more can relate to.

There is something to be said for explaining the technical terms from
the C standards in more colloquial language to make it easier for others
to understand. There is nothing at all to be said for using C standard
terms in clearly and obviously incorrect ways. That's just going to
confuse these non-standard-reading C programmers when they try to find
out more, no matter where they look for additional information.

>
> Apparently both 'typedef' and 'static' are forms of 'linkage'. But no
> identifiers declared with those will ever be linked to anything!

Could you point to the paragraph of the C standards that justifies that
claim? Or are you perhaps mixing things up? (I can tell you the
correct answer, with references, if you are stuck - but I'd like to give
you the chance to show off your extensive C knowledge first.)

On 07/02/2024 16:45, Malcolm McLean wrote:
> On 07/02/2024 15:30, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 07/02/2024 11:04, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> Making some "temp" variables and re-using them was also common for
>>>>> some
>>>>> people in idiomatic C90 code, where all your variables are declared
>>>>> at the
>>>>> top of the function.
>>>> The comma suggests (I think) that it is C90 that mandates that all
>>>> one's
>>>> variables are declared at the top of the function.  But that's not the
>>>> case (as I am sure you know).
>>>
>>> Yes.
>>>
>>>>   The other reading -- that this is done in
>>>> idiomatic C90 code -- is also something that I'd question, but not
>>>> something that I'd want to argue.
>>>
>>> "Idiomatic" is perhaps not the best word.  (And "idiotic" is too
>>> strong!)
>>> I mean written in a way that is quite common in C90 code.
>>
>> The most common meaning of "idiomatic", and the one I usually associate
>> with it in this context, is "containing expressions that are natural and
>> correct".  That's not how I would describe eschewing declarations in
>> inner blocks.

Some people do feel it is more "natural" to have all their declarations
at the start of their functions (and never declare variables in any
inner block scopes). It's common, and their code can be correct. You
and I both think there are usually better ways to structure code, but
does that mean it is not "idiomatic" ? I'm not sure there is a good
answer here. Unfortunately the C standards don't define the term
"idiomatic" :-(

If you can think of a better term to use here, I'd be happy to hear it -
otherwise I think we all know the kind of code structure I meant, which
was the most important point.

>>
> No. It means writing the code in a way which is common in C and has
> certain advantages, but is not so in other languages.

An idiom in C could also be an idiom in C++, Python, or any other
language. Nothing in "idiomatic" implies that it is unique to a
particular language, just that it is commonly used in that language.

On 07/02/2024 17:25, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/02/2024 00:24, Lawrence D'Oliveiro wrote:
>>> On Tue, 6 Feb 2024 09:50:02 +0100, David Brown wrote:
>>>
>>>> And of course there are those two or three unfortunate people that have
>>>> to work with embedded Windows.
>>>
>>> I thought this has pretty much gone away, pushed aside by Linux.
>>
>> It was never common in the first place, and yes, it is almost entirely
>> non-existent now. I'm sure there are a few legacy products still
>> produced that use some kind of embedded Windows, but few more than that
>> - which is what I was hinting at in my post.
>
> Wind river is still popular, I believe, but the linux kernel + busybox is
> probably the most common.

VxWorks, you mean? Yes, that is still used in what might be called
"big" embedded systems. There are other RTOS's that have been common
for embedded systems with screens (and no one would bother with embedded
Windows without a screen!), including QNX, Integrity, eCOS, and Nucleus.

(There are many small RTOS's, but they are competing in a different field.)

On 2/7/2024 12:49 PM, David Brown wrote:
> On 07/02/2024 17:25, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 07/02/2024 00:24, Lawrence D'Oliveiro wrote:
>>>> On Tue, 6 Feb 2024 09:50:02 +0100, David Brown wrote:
>>>>
>>>>> And of course there are those two or three unfortunate people that
>>>>> have
>>>>> to work with embedded Windows.
>>>>
>>>> I thought this has pretty much gone away, pushed aside by Linux.
>>>
>>> It was never common in the first place, and yes, it is almost entirely
>>> non-existent now.  I'm sure there are a few legacy products still
>>> produced that use some kind of embedded Windows, but few more than that
>>> - which is what I was hinting at in my post.
>>
>> Wind river is still popular, I believe, but the linux kernel + busybox is
>> probably the most common.
>
> VxWorks, you mean?  Yes, that is still used in what might be called
> "big" embedded systems.  There are other RTOS's that have been common
> for embedded systems with screens (and no one would bother with embedded
> Windows without a screen!), including QNX, Integrity, eCOS, and Nucleus.
>
> (There are many small RTOS's, but they are competing in a different field.)
>

Fwiw, I think the last one I used was quadros a long time ago.

On Wed, 7 Feb 2024 14:01:27 +0100, David Brown wrote:

> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error. It is very much
> easier for automatic tools (static warnings) to spot issues.

Here’s an example of how granular I like to make my scopes:

struct pollfd topoll[MAX_WATCHES + 1];
int total_timeout = -1; /* to begin with */
for (int i = 0; i < nr_watches; ++i)
{
DBusWatch * const watch = watches[i];
struct pollfd * const entry = topoll + i;
entry->fd = dbus_watch_get_unix_fd(watch);
entry->events = 0; /* to begin with */
if (dbus_watch_get_enabled(watch))
{
const int flags = dbus_watch_get_flags(watch);
if ((flags & DBUS_WATCH_READABLE) != 0)
{
entry->events |= POLLIN | POLLERR;
} /*if*/
if ((flags & DBUS_WATCH_WRITABLE) != 0)
{
entry->events |= POLLOUT | POLLERR;
} /*if*/
} /*if*/
} /*for*/
{
struct pollfd * const entry = topoll + nr_watches;
entry->fd = notify_receive_pipe;
entry->events = POLLIN;
}
for (int i = 0; i < nr_timeouts; ++i)
{
DBusTimeout * const timeout = timeouts[i];
if (dbus_timeout_get_enabled(timeout))
{
const int interval = dbus_timeout_get_interval(timeout);
if (total_timeout < 0 or total_timeout > interval)
{
total_timeout = interval;
} /*if*/
} /*if*/
} /*for*/
const long timeout_start = get_milliseconds();
bool got_io;
{
const int sts = poll(topoll, nr_watches + 1, total_timeout);
fprintf(stderr, "poll returned status %d\n", sts);
if (sts < 0)
{
perror("doing poll");
die();
} /*if*/
got_io = sts > 0;
}

On Wed, 7 Feb 2024 21:49:52 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 07/02/2024 17:25, Scott Lurndal wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> On 07/02/2024 00:24, Lawrence D'Oliveiro wrote:
> >>> On Tue, 6 Feb 2024 09:50:02 +0100, David Brown wrote:
> >>>
> >>>> And of course there are those two or three unfortunate people
> >>>> that have to work with embedded Windows.
> >>>
> >>> I thought this has pretty much gone away, pushed aside by Linux.
> >>
> >> It was never common in the first place, and yes, it is almost
> >> entirely non-existent now. I'm sure there are a few legacy
> >> products still produced that use some kind of embedded Windows,
> >> but few more than that
> >> - which is what I was hinting at in my post.
> >
> > Wind river is still popular, I believe, but the linux kernel +
> > busybox is probably the most common.
>
> VxWorks, you mean? Yes, that is still used in what might be called
> "big" embedded systems. There are other RTOS's that have been common
> for embedded systems with screens (and no one would bother with
> embedded Windows without a screen!),

Then our company and me personally are no-ones 1.5 times.

The first time it was WinCE on small Arm-based board that served as
Ethernet interface and control plane controller for big boards that
was an important building blocks for very expensive industrial
equipment. Equipment as whole was not ours, we were sub-contractor for
this particular piece. This instance of Windows never ever had display
or keyboard.
We still make few boards per year more than 15 years later.

The second one was/is [part of] our own product, a regular Windows
Embedded, starting with XP, then 7, then 10. It runs on SBC that
functions as a host of Compact PCI frame with various I/O boards mostly
of our own making. SBC does both control plane and partial data plane
processing and handles Ethernet communication with the rest of the
system. It's completely different industry, the system as a whole not
nearly as expensive as the first one, but still expensive enough for
this particular computer to be small part of the total cost.
The system does have connectors for display, keyboard and mouse.
Ssometimes it is handy to connect them during manufacturing testing. But
they are never connected in fully assembled product. However since they
exist, with relation to this system I count myself as half-no-one
rather than full no-one.

> including QNX, Integrity, eCOS,
> and Nucleus.
>
> (There are many small RTOS's, but they are competing in a different
> field.)
>