Bart <bc@freeuk.com> writes:

Every time I do a survey of C codebases, I tend to get about the
same set of results:

* On average functions have only around three local variables

* 80% of all functions have 4 locals or fewer

Here are some statistics from a codebase for a C library:

Average number of locals per function: just over 2

Fraction of functions with 4 locals or fewer: just over 85%

What conclusions should we draw from these statistics?

I don't find such stats a compelling reason for block scopes,

As most people know, a problem with averages is that they rarely
tell the whole story. Despite the similarity of the statistics
shown above with the ones you gave, code in the library codebase
has locals declared in inner blocks, and locals declared in the
outermost block but after some number of executable statements,
and also locals declared in other nested scopes. In no case were
any of these choices made from indifference: the code shows a
clear preference for declaring locals in the outermost block, and
at the top of that block before any executable code. In every
instance that doesn't follow that rule there was a particular
motivation for adopting the choice that was made. The idea that
such averages make a good argument for never accepting locals
other than at the top of the outermost block just doesn't hold
water.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...] An observation pointed out to me at my last gig, and that
I now point out occasionally myself, is that Linux (for example)
is not so much written in C but rather in Linux C, which is the
dialect of the language defined by the compilers they use and
the specific behaviors they force using flags, pragmas, etc, for
those compilers.

Any program accepted by a conforming implementation is a C program.
That remains true even if the program relies on compiler options
such as -fwrap or -fno-strict-aliasing, or takes advantage of
specific behaviors chosen by the compiler in situations that the C
standard deems undefined behavior, or uses non-standard #pragmas
that the implementation has chosen to define. As long as the
implementation stays inside the bounds of being conforming, any
program it accepts is written in C. Writing in a subset of the full
language doesn't change that: a C program that has no 'goto'
statements in it is still a C program. The same reasoning applies
to programs that make use of -fwrapv, etc.

At any rate, it's certainly not strictly
conforming ISO C: is _any_ large program strictly conforming at
this point? I suspect many projects strive for such, but few
actually attain it.

I expect most people don't realize how high a bar it is to write a C
program that is strictly conforming. Except for toy examples I
don't think I've ever seen one. I wouldn't advocate choosing such a
criterion. Even more than that, if a member of any team I was part
of did suggest doing so I would strongly argue against it. Even if
it could be done, which I think is unlikely, the amount of effort
needed to do so would be prohibitive.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <86se72bd74.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...] An observation pointed out to me at my last gig, and that
I now point out occasionally myself, is that Linux (for example)
is not so much written in C but rather in Linux C, which is the
dialect of the language defined by the compilers they use and
the specific behaviors they force using flags, pragmas, etc, for
those compilers.

Any program accepted by a conforming implementation is a C program.
That remains true even if the program relies on compiler options
such as -fwrap or -fno-strict-aliasing, or takes advantage of
specific behaviors chosen by the compiler in situations that the C
standard deems undefined behavior, or uses non-standard #pragmas
that the implementation has chosen to define. As long as the
implementation stays inside the bounds of being conforming, any
program it accepts is written in C. Writing in a subset of the full
language doesn't change that: a C program that has no 'goto'
statements in it is still a C program. The same reasoning applies
to programs that make use of -fwrapv, etc.

This is quibbling, but for the record, Linux is written in an
_extended_ subset of ISO C, and makes use of a number of
non-conforming extensions (e.g., GCC-style function attributes
and so on). While it's obviously "C" in some generic sense,
describing it as a dialect called "Linux C" is entirely
appropriate.

But don't take my word for it: I urge you to have a look at the
code and draw your own conclusion.

At any rate, it's certainly not strictly
conforming ISO C: is _any_ large program strictly conforming at
this point? I suspect many projects strive for such, but few
actually attain it.

I expect most people don't realize how high a bar it is to write a C
program that is strictly conforming. Except for toy examples I
don't think I've ever seen one. I wouldn't advocate choosing such a >criterion. Even more than that, if a member of any team I was part
of did suggest doing so I would strongly argue against it. Even if
it could be done, which I think is unlikely, the amount of effort
needed to do so would be prohibitive.

Agreed.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86se72bd74.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...] An observation pointed out to me at my last gig, and that
I now point out occasionally myself, is that Linux (for example)
is not so much written in C but rather in Linux C, which is the
dialect of the language defined by the compilers they use and
the specific behaviors they force using flags, pragmas, etc, for
those compilers.

Any program accepted by a conforming implementation is a C program.
That remains true even if the program relies on compiler options
such as -fwrap or -fno-strict-aliasing, or takes advantage of
specific behaviors chosen by the compiler in situations that the C
standard deems undefined behavior, or uses non-standard #pragmas
that the implementation has chosen to define. As long as the
implementation stays inside the bounds of being conforming, any
program it accepts is written in C. Writing in a subset of the full
language doesn't change that: a C program that has no 'goto'
statements in it is still a C program. The same reasoning applies
to programs that make use of -fwrapv, etc.

This is quibbling, but for the record, Linux is written in an
_extended_ subset of ISO C, and makes use of a number of
non-conforming extensions (e.g., GCC-style function attributes
and so on).

The C standard allows extensions. As long as the extensions
don't change the meaning of any strictly conforming program,
the extended language still counts as C.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 19 May 2026 15:40:13 +0200, David Brown
<david.brown@hesbynett.no> wrote:

Can you give me an example of a real-world programming language in which
the scope of a local variable begins at the start of the enclosing
block, rather than at its declaration / definition?

PL/I aka PL/1. It was/is infamous for this.

Plus it's the only language I know with a preprocessor almost as ugly
and confusing as C's. But fortunately less needed.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 21 May 2026 21:23:27 +0200, David Brown
<david.brown@hesbynett.no> wrote:

On 21/05/2026 19:26, Bart wrote:

On 21/05/2026 13:55, David Brown wrote:

(The separation of the struct/union/enum tag name space from variable
namespace /is/ a feature that people use

Urgh, another discussion. Let's not go there. Suffice that it is unique
to C.

Fortran -- since it standardized struct under the keyword TYPE in 1990
-- has typenames separate/nonconflicting. So are program-unit names
(including now-outdated COMMON blocks, except for the special handling
of function results) and module names. And, $deity preserve us,
NAMELIST groups -- which act almost like labels and (in Fortran) those
aren't names at all but small integers.

It doesn't have union or enum, though EQUIVALENCE COMMON and certain 'associations' can produce the effect of union.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/05/2026 23:03, fir wrote:

the fact that in c a language/compiler sees only functions or variables
that are up in code is a disaster

it is a disaster becouse it dont alow you to split code on N files
each file has realted functions and variables and not to care on the
global order of it

Are you talking about symbol conflicts when converting internal linkage
symbols to external linkage?

It is common among toolchain providers to give one the means to do that.
GCC, for example, has symbol visibility extensions.

You can also use a toolchain's linker to rename symbols, for example to
give them a namespace prefix, or use a C macro for extern linkage
symbols instead of literal identifiers throughout.

--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 17/05/2026 01:08, Bart wrote:

On 16/05/2026 23:03, fir wrote:

the fact that in c a language/compiler sees only functions or
variables that are up in code is a disaster

it is a disaster becouse it dont alow you to split code on N files
each file has realted functions and variables and not to care on the
global order of it

I mentioned something like this a week ago, suggesting that in C it was harder work than necessary to split one source file up into two or more.

However, some of the regulars here seemed to think it was a non-problem:

I've done it on the basis that when a subsystem is for a small program
(or is the entire program) it is a non-problem, when it is for a big
program then one may have bee selected or trained to account for the
pitfalls at the start or one may be writing anew with a boundary already analysed into one's work-package or (perhaps unknowingly) feeding into a toolchain that provides the necessary transparent modularity.

I can see how "developing" a program - ie, evolving from small
subsystems in small programs to large subsystems in large programs -
will have pitfalls and yet is obviously valuable.

I expect that has been solved with toolchains in the past because
linkers have, for a long time, had symbol rewriting features - and
curiously no corresponding debug rewriting - from which I infer they're
used at a delivery-integration in a development structure where
subsystem and unit test-cases against external linkage symbols are
distilled out of user defect-reports.



--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)