On 2/5/2024 4:03 PM, Chris M. Thomasson wrote:
> On 2/5/2024 3:28 PM, Lawrence D'Oliveiro wrote:
>> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>>
>>> Windows by itself is not a measurable slowdown, but antivirus is, and
>>> until now I didn't find a way to get antivirus-free Windows at work.
>>
>> But if you don’t have antivirus on your build machine, the sad fact of
>> development on Windows is that there are viruses that will insinuate
>> themselves into the build products.
>
> There can be viruses hidden in source code for public domain code...
> Build it and they will come! ;^o

Other viruses can be build, not infected... Run it, BAM!!

On 05/02/2024 21:53, Kaz Kylheku wrote:
> On 2024-02-05, David Brown <david.brown@hesbynett.no> wrote:
>> On 05/02/2024 17:32, Michael S wrote:
>>> On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
>>> Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>>>>
>>>> Is it due to decades of legacy code in GCC? Clang is a newer
>>>> implementatation, so you might think it's faster than GCC. But it
>>>> manages only to be about the same.
>>>>
>>>
>>> I still believe that "decades of legacy" are the main reason.
>>> clang *was* much faster than gcc 10-12 years ago. Since then it
>>> accumulated a decade of legacy. And this particular decade mostly
>>> consisted of code that was written by people that (a) less experienced
>>> than gcc maintainers (b) care about speed of compilation even less than
>>> gcc maintainers. Well, for the later, I don't really believe that it is
>>> possible, but I need to bring a plausible explanation, don't I?
>>>
>>
>> Early clang was faster than C at compilation and static error checking.
>> And it had much nicer formats and outputs for its warnings. But it
>> wasn't close to gcc for optimisation and generated code efficiency, and
>> had less powerful checking.
>>
>> Over time, clang has gained a lot more optimisation and is now similar
>> to gcc in code generation (each is better at some things), while gcc has
>> sped up some aspects and greatly improved the warning formats.
>>
>> clang is now a similar speed to gcc because it does a similar job. It
>> turns out that doing a lot of analysis and code optimisation takes effort.
>
> It takes more and more effort for diminishing results.
>

Yes.

> A compiler can spend a lot of time just searching for the conditions
> that allow a certain optimization, where those conditions turn out to be
> false most of the time. So that in a large code base, there will be just
> a couple of "hits" (the conditions are met, and the optimization can
> take place). Yet all the instruction sequences in every basic block in
> every file had to be looked at to determine that.

This is always the case with optimisations. Each pass might only give a
few percent increase in speed - but when you have 50 passes, this adds
up to a lot. And some passes (that is, some types of optimisation) can
open up new opportunities for if you redo previous passes. And the same
applies to static error checking - there is quite an overlap in the
kinds of analysis used for optimisations and for static error checking.

>
> Mnay of these conditions are specific to the optimization. Another
> kind of optimization has its own conditions that don't reuse anything
> from that one. So the more optimizations you add, the more work it takes
> just to determine applicability.
>
> The optimizer may have to iterate on the program graph. After certain
> optimizations are applied, the program graph changes. And that may
> "unlock" more opportunities to do optimizations that were not possible
> before. But because the program graph changed, its properties have to be
> recalculated, like liveness of variables/temporaries and whatnot.
> More time.
>

Yes.

For a great lot of code, it is not necessary to squeeze out as much
speed as possible. But IMHO it is usually a good idea to have as much
static error checking as you reasonably can without too high a risk of
false positives.

Major compilers aren't really bothered about the speed of compilation of
C code - it is usually fast enough that it is of little concern. Those
that are building a lot, use make (or other build tools), perhaps
ccache, and usually use machines with plenty of cores and plenty of ram.

It's C++ that is the concern, especially big projects. And there you
/do/ need at least some optimisation effort, because C++ is generally
full of little functions that are expected to "disappear" entirely by
inlining. So that is where the compiler developer effort goes for
compiler speed, analysis, and optimisation.

Programmers are notoriously bad at determining which bits of their code
need to be efficient. And if they know their compiler is poor at
optimising, they do "manual optimisation". They use pointers where
arrays would be clearer. They reuse "temp" variables instead of making
new ones. They write jumbles of "gotos" instead of breaking code into
multiple functions. They write "(x << 3) + x" instead of "x * 9". It
is much better to write the clearest source code you can, and let the
compiler do its job and generate efficient object code.

It's never a bad thing if a compiler is faster. But IMHO it is more
important for the compiler to be /better/ - better warnings and checks
that catch issues earlier, and better optimisation because that allows
people to write code in the clearest, safest and most maintainable way
while still getting good results.

On 06/02/2024 00:28, Lawrence D'Oliveiro wrote:
> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>
>> Windows by itself is not a measurable slowdown, but antivirus is, and
>> until now I didn't find a way to get antivirus-free Windows at work.
>
> But if you don’t have antivirus on your build machine, the sad fact of
> development on Windows is that there are viruses that will insinuate
> themselves into the build products.

Nonsense. Well, /almost/ nonsense. When thinking about security, you
should not rule out anything entirely.

And of course there are those two or three unfortunate people that have
to work with embedded Windows.

On 06/02/2024 00:46, Michael S wrote:
> On Mon, 5 Feb 2024 23:28:04 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>>
>>> Windows by itself is not a measurable slowdown, but antivirus is,
>>> and until now I didn't find a way to get antivirus-free Windows at
>>> work.
>>
>> But if you don’t have antivirus on your build machine, the sad fact
>> of development on Windows is that there are viruses that will
>> insinuate themselves into the build products.
>
> No, if I use Windpws there are no danger of viruses like these.
> Besides, it's not like antivirus could have helped against viruses if
> I was stupid enough to catch them. To the opposite, I suspect that
> presence of antivirus increases attak surface.
>

My experience is that antivirus programs rarely catch anything unless
the user is very gullible, or very unlucky. I have seen antivirus
programs block valid programs with false positives more often than I
have seen them catch actual malware. (And that's company wide, not just
my machines.) There is no major antivirus software that has not killed
at least some Windows machines by false-positive blocking of critical
Windows components.

And yes, there have been many successful attacks and hacks that get into
Windows machines via flaws in the massively over-complicated "security"
software.

On 2/6/2024 12:50 AM, David Brown wrote:
> On 06/02/2024 00:28, Lawrence D'Oliveiro wrote:
>> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>>
>>> Windows by itself is not a measurable slowdown, but antivirus is, and
>>> until now I didn't find a way to get antivirus-free Windows at work.
>>
>> But if you don’t have antivirus on your build machine, the sad fact of
>> development on Windows is that there are viruses that will insinuate
>> themselves into the build products.
>
> Nonsense.  Well, /almost/ nonsense.  When thinking about security, you
> should not rule out anything entirely.
>
> And of course there are those two or three unfortunate people that have
> to work with embedded Windows.
>

;^)

On 2/6/2024 12:44 AM, David Brown wrote:
[...]
> Programmers are notoriously bad at determining which bits of their code
> need to be efficient.

This brings me back to a code base I was ask to take a look at. Well,
the keyword register was all over the place! Spooky...

[...]

On Tue, 6 Feb 2024 09:44:20 +0100
David Brown <david.brown@hesbynett.no> wrote:
>
>
> > A compiler can spend a lot of time just searching for the conditions
> > that allow a certain optimization, where those conditions turn out
> > to be false most of the time. So that in a large code base, there
> > will be just a couple of "hits" (the conditions are met, and the
> > optimization can take place). Yet all the instruction sequences in
> > every basic block in every file had to be looked at to determine
> > that.
>
> This is always the case with optimisations. Each pass might only
> give a few percent increase in speed - but when you have 50 passes,
> this adds up to a lot. And some passes (that is, some types of
> optimisation) can open up new opportunities for if you redo previous
> passes.

Except that at least gcc by design never redo previous passes. More so,
it does not even try to compare result of optimization with certain
pass vs result without this pass and to take better of the two.

I don't know if the same applies to clang, I never had
conversations with clang maintainers (had plenty with gcc maintainers).
However, the bottom line for last 2-3 years is that when I compare
speed of gcc-compiled code vs clang-compiled then both can do good
job and both can do ordinary stupid things, but clang is much more
likely then gcc to do astonishingly stupid things. Like, for example,
vectorization that reduces the speed by factor of 3 vs non-vectorized
variant.
So, most likely, clang also proceeds pass after pass after pass and
never ever looks back. Seems like they took the lesson of Lot's wife
very seriously.

> And the same applies to static error checking - there is
> quite an overlap in the kinds of analysis used for optimisations and
> for static error checking.
>

On 06/02/2024 12:41, Michael S wrote:
> On Tue, 6 Feb 2024 09:44:20 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>
>>
>>> A compiler can spend a lot of time just searching for the conditions
>>> that allow a certain optimization, where those conditions turn out
>>> to be false most of the time. So that in a large code base, there
>>> will be just a couple of "hits" (the conditions are met, and the
>>> optimization can take place). Yet all the instruction sequences in
>>> every basic block in every file had to be looked at to determine
>>> that.
>>
>> This is always the case with optimisations. Each pass might only
>> give a few percent increase in speed - but when you have 50 passes,
>> this adds up to a lot. And some passes (that is, some types of
>> optimisation) can open up new opportunities for if you redo previous
>> passes.
>
> Except that at least gcc by design never redo previous passes. More so,
> it does not even try to compare result of optimization with certain
> pass vs result without this pass and to take better of the two.

AFAIUI (I am not a gcc developer), gcc redoes certain types of
optimisations after later passes - even if it calls them different pass
numbers. For example, constant propagation and dead code elimination is
done early on in functions. Then after inlining and IPA passes, it is
done again using the new information.

I expect you are correct that it does not try to compare the results
from pass to pass. I think that would quickly be infeasible. You can't
just compare the results of applying optimisation B to base A to see if
it is better or worse than before A was, and then decide which to keep
before moving to step C. Maybe A was better than AB, but ABC is better
than AC. You'd need to keep comparing all sorts of combinations, and it
would be a scalability nightmare.

>
> I don't know if the same applies to clang, I never had
> conversations with clang maintainers (had plenty with gcc maintainers).
> However, the bottom line for last 2-3 years is that when I compare
> speed of gcc-compiled code vs clang-compiled then both can do good
> job and both can do ordinary stupid things, but clang is much more
> likely then gcc to do astonishingly stupid things. Like, for example,
> vectorization that reduces the speed by factor of 3 vs non-vectorized
> variant.

I see the same, though I have not used clang very seriously for real
work. It does, however, seem a bit over-enthusiastic about vectorising
code.

> So, most likely, clang also proceeds pass after pass after pass and
> never ever looks back. Seems like they took the lesson of Lot's wife
> very seriously.
>
>
>> And the same applies to static error checking - there is
>> quite an overlap in the kinds of analysis used for optimisations and
>> for static error checking.
>>
>

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.

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.

On 05/02/2024 08:29, Malcolm McLean wrote:
> On 05/02/2024 01:09, bart wrote:
>>
>> In no particular order.
>>
>> * Software development can ONLY be done on a Unix-related OS
>>
>> * It is impossible to develop any software, let alone C, on pure Windows
>>
>> * You can spend decades developing and implementing systems languages
>> at the level of C, but you still apparently know nothing of the subject
>>
>
> The tone's currently rather bad, and somehow it has developed that you
> and I are on one side and pretty much everyone else on the other. We
> both have open source projects which are or at least attempt to be
> actually useful to other people, whilst I don't think many of the others
> can say that, and maybe that's the underlying reason. But who knows.
>
> I'm trying to improve the tone. It's hard because people have got lots
> of motivations for posting, and some of them aren't very compatible with
> a good humoured, civilised group. And we've got a lot of bad behaviour,
> not all of it directed at us by any means. However whilst you're very
> critical of other people's design decisions, I've rarely if ever heard
> to say that therefore you criticise someone's general character.
>

Well we've both posted code of sizeable, actual and practical projects.
Very few on the 'other side' have. Maybe it's proprietory or there are
other reasons. But it means their own output can't be criticised here.

Myself I've also pretty much given up on discussing new features for C
or new directions. The thread on build systems lies outside the
language. But few regulars are that interested in that side of it; only
in what C does right now.

From what I can see, the most fascinating topics for them are pedantic
details of the C standard, and the most low level technical details of
Unix-like systems.

> But finally tolerance has snapped.

I usually argue against ideas not people. But there is only so many
personal insults that you can take.

On 05/02/2024 05:58, Kaz Kylheku wrote:
> On 2024-02-05, bart <bc@freeuk.com> wrote:

> Writing a compiler is pretty easy, because the bar can be set very low
> while still calling it a compiler.

> Whole-program compilers are easier because there are fewer requirements.
> You have only one kind of deliverable to produce: the executable.
> You don't have to deal with linkage and produce a linkable format.

David Brown suggested that they were harder than I said. You're saying
they are easier.

BTW your statements are wrong, but I'm not going to argue about it.

My whole-program compiler is here:

https://github.com/sal55/langs/blob/master/MCompiler.md

It has a dozen different outputs.

> GCC is maintained by people who know what a C compiler is, and GCC can
> be asked to be one.

So what is it when it's not a C compiler? What language is it compiling
here:

c:\qx>gcc qc.c
c:\qx>

This program passes. Mine does the same:

c:\qx>mcc qc.c
Compiling qc.c to qc.exe

Whatever language that mcc processes must be similar to that that gcc
processes.

Yet it is true that gcc can be tuned to a particular standard, dialect,
set of extensions and a set of user-specified behaviours. Which means it
can also compile some Frankensteinian version of 'C' that anyone can devise.

Mine at least is a more rigid subset.

> Your idea of writing a C compiler seems to be to pick some random
> examples of code believed to be C and make them work. (Where "work"
> means that they compile and show a few behaviors that look like
> the expected ones.)

That's what most people expect!

> Basically, you don't present a very credible case that you've actually
> written a C compiler.

Well, don't believe it if you don't want. There 1000s of amateur 'C'
compilers about, it must be the most favoured language for such projects
(since it looks deceptively simple).

Among such compilers, mine is quite accomplished by comparison. One task
it is used for is to take APIs defined by C header files and turn into
into bindings in my two languages. It does that as well as any such tool
can. So fuck you.

> I currently work on a a firmware application that compiles to a 100
> megabyte (stripped!) executable.

And yet 90% of the executables on my PC are under 1MB. SOMEBODY must be
writing small programs!

The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7%
smaller than your giant program.

You want to make me feel bad about my stuff because you work on a big
project and mine are small. Let me go and find that length of rope then...

>> * There is not a single feature of my alternate systems language that is
>> superior to the C equivalent
>
> The worst curve ball someone could throw you would be to
> be eagerly interested in your language, and ask for guidance
> in how to get it installed and start working in it.

That happened 2-3 years ago and I was able to help out. However I'm not
pushing my actual language, which is anyway volatile as it is a vehicle
for new ideas, I was only discussing the utility of certain features.

Surely somebody can do that without going to the trouble of creating and
implementation a whole language, and using the feature over years, as
proof of concept.

But when someone actually does that, THEN they are not worth listening to?

I mean, where is YOUR lower-level system language? Where is anybody's? I
don't mean the Zigs and Rusts because that would be like comparing a
40-tonne truck with a car.

My language is a modernish family car compared with C's Model T.

> Not as much as fast executable code, unfortunately.

And yet most people code in Python and JavaScript and a whole pile of
slow languages.

> Compilers that blaze through large amounts of code in the blink of an
> eye are almost certainly dodging on the optimization.

Yes, probably. But the optimisation is overrated. Do you really need
optimised code to test each of those 200 builds you're going to do today?

Not for a language at the level of C. (Maybe for C++ code as it needs it
to collapse the mountain of redundant code that templates etc will produce.)

For the programs I write, gcc-O3 makes then 1.5 to 2.0 faster typically,
for 100 times longer compile time.

And if I do want the boost, I can transpile to C to use gcc-O3. I don't
need the super-optimisation within my own product.

> And because they
> don't need the internal /architecture/ to support the kinds
> optimizations they are not doing, they can speed up the code generation
> also. There is no need to generate an intermediate representation like
> SSA; you can pretty much just parse the syntax and emit assembly code in
> the same pass. Particularly if you only target one architecture.
>
> A poorly optimizing retargetable compiler that emits an abstract
> intermediate code will never be as blazingly fast as something equally
> poorly optimizing that goes straight to code in one pass.

My non-C compiler uses multiple passes including an IL stage. It is not
much slower than TCC which is one pass, but generally produces faster code.

It can compile itself at about 15Hz. (That is, 15 new generations per
second. Unoptimised.)

>> * There is no benefit at all in having a tool like a compiler, be a
>> small, self-contained executable.
>
> Not as much as there used to, decades ago.

Simplicity is always good. Somebody deletes one of the 1000s of files of
your gcc installation. Is it something that is essential? Who knows.

But if your compiler is the one file mm.exe, it's easy to spot if it's
missing!

On 2024-02-07, bart <bc@freeuk.com> wrote:
> Well we've both posted code of sizeable, actual and practical projects.
> Very few on the 'other side' have. Maybe it's proprietory or there are
> other reasons. But it means their own output can't be criticised here.

Posting large amounts of code into discussion groups isn't practical,
and against netiquette.

The right thing is to host your code somewhere (which it behooves you to
do for obvious other reasons) and post a link to it.

People used to share code via comp.sources.*. Some well-known old
projects first made their appearance that way. E.g. Dick Grune posted
the first version of CVS in what was then called mod.sources in 1986.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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.

However, the context here was compiler optimisation. Not all compilers
have good optimisation. In the embedded world, there are vast numbers
of C compilers, many of which are much more limited than the modern and
advanced tools most of us use today. These weaker compilers are much
rarer now, as are many of the ISAs they served - 32-bit ARM "M" cores
are dominant along with gcc. But in the old days, an embedded C
programmer had to write their code in a way that suited the compiler if
they wanted the best out of their microcontroller - and efficient code
means cheaper devices, lower power and longer battery life. Some of
these weaker tools would allocate registers to local variables on a
first come, first served basis, with no lifetime analysis or reuse
inside a function. Thus you re-used your temporary variables.

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.

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.

On 07/02/2024 03:18, bart wrote:
> On 05/02/2024 05:58, Kaz Kylheku wrote:
>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>
>> Writing a compiler is pretty easy, because the bar can be set very low
>> while still calling it a compiler.
>
>> Whole-program compilers are easier because there are fewer requirements.
>> You have only one kind of deliverable to produce: the executable.
>> You don't have to deal with linkage and produce a linkable format.
>
> David Brown suggested that they were harder than I said. You're saying
> they are easier.

I described what /I/ see as "whole program compilers", and where I see
them being used as serious tools that give better results than
traditional compile-and-link toolchains. The key here is whole program
/optimisation/ and static analysis. And I think there can be little
doubt that this is a far harder task than the much more limited tools
you are talking about.

Maybe it was unreasonable of me to conflate "whole program compiler" and
"whole program optimiser", even though I see no real-world use of the
former without the later. Using your definition of the term, your tool
is a "whole program compiler".

And I think Kaz was using the term in the same way as you do when he
says he thinks it is easier. I don't know either way, but it would
certainly skip several things that are otherwise necessary in a
traditional setup - assembly generation, an assembler, and a linker.
You also don't have to deal with linking object files from other sources.

(For the record, I there are many things that cannot be done with C and
traditional compile-link setups, that could be done with some kind of
whole-program analysis and a suitable language. Rust's borrow checker,
and XMOS XC's thread analysis are two examples.)

>
>> GCC is maintained by people who know what a C compiler is, and GCC can
>> be asked to be one.
>
> So what is it when it's not a C compiler? What language is it compiling
> here:
>

You walked right into that one - how many times has the difference
between standard C and sort-of-C been explained to you? As always, I
must point out that a tool does not have to be standards compliant -
that's a choice of the tool developer. But when the distinction is
made, and Kaz was clearly making that distinction, a "C compiler" is one
that follows the C standards (one or more published version) accurately
in terms of what it accepts or does not accept, the minimum guaranteed
behaviour, and the minimum required diagnostics. As has been explained
many times, "gcc" is not, in those terms, a "C compiler" by default - it
needs flags to put it in a compliant mode. Your tool, AFAIK, has never
claimed to be a standards-compliant C compiler.

>
> Whatever language that mcc processes must be similar to that that gcc
> processes.

Yes. Both accept some version of sort-of-C, with a common subset. (The
common subset in this example code may also, by coincidence, be standard
C. I haven't looked at it to see.)

>
> Yet it is true that gcc can be tuned to a particular standard, dialect,
> set of extensions and a set of user-specified behaviours. Which means it
> can also compile some Frankensteinian version of 'C' that anyone can
> devise.
>
> Mine at least is a more rigid subset.
>

Your idea of "rigid" is other people's idea of "inflexible". Rigid is
fine for one user.

>> Your idea of writing a C compiler seems to be to pick some random
>> examples of code believed to be C and make them work.  (Where "work"
>> means that they compile and show a few behaviors that look like
>> the expected ones.)
>
> That's what most people expect!
>

No, it is not. /I/ expect a compiler to be written by people who have
extensive knowledge of the C standards and who do their best to get the
compiler correct /by design/. Not by luck or trial and error. By
/design/. And I expect it to have an extensive test suite of both
simple code and extreme code and corner cases, because even the best
designers can get things wrong sometimes and testing helps catch bugs.

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.

However there are also strong arguments for ducntion scope. A function
is a natural unit. Adn all the varibales 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. And there are only three levels of
scope. A varibale is global, or it is file scope, or it is scoped to the
function.

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.

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

On 07/02/2024 02:18, bart wrote:
> On 05/02/2024 05:58, Kaz Kylheku wrote:
>>
>
>> Basically, you don't present a very credible case that you've actually
>> written a C compiler.
>
> Well, don't believe it if you don't want. There 1000s of amateur 'C'
> compilers about, it must be the most favoured language for such projects
> (since it looks deceptively simple).
>

It's absolutely clear to me that Bart has written a C compiler, and this
statement by Kaz is ridiculous.

>

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

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

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.

--
Ben.

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?
How about medical equipment?
The first question is mostly rhetorical, the second is not.

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.

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.

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

Other people, not familiar with" modern" C, might interpret the term to
mean declaring names at the top of the inner-most appropriate block.

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

> However there are also strong arguments for ducntion scope. A function is a
> natural unit. Adn all the varibales 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.

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. I'd argue that
this is also a big win for "short scopes". A policy that leads to early
triggers for refactoring is worth considering.

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

> I tend to prefer function scope for C.

We could call it outer-most block scope rather than re-use a term with
an existing, but different, technical meaning.

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

--
Ben.

On 07/02/2024 02:26, Kaz Kylheku wrote:
> On 2024-02-07, bart <bc@freeuk.com> wrote:
>> Well we've both posted code of sizeable, actual and practical projects.
>> Very few on the 'other side' have. Maybe it's proprietory or there are
>> other reasons. But it means their own output can't be criticised here.
>
> Posting large amounts of code into discussion groups isn't practical,
> and against netiquette.
>
> The right thing is to host your code somewhere (which it behooves you to
> do for obvious other reasons) and post a link to it.
>
> People used to share code via comp.sources.*. Some well-known old
> projects first made their appearance that way. E.g. Dick Grune posted
> the first version of CVS in what was then called mod.sources in 1986.
>

Directly including source code as part of a post is not that practical
beyond a few hundred lines of code.

Clearly that wouldn't count as 'sizeable'. That would need to be done
via a link.

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.

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

int abc; // inter-file scope, may be imported or exported
static int def; // file scope

void F(void) {
int ghi; // function-scope
}

If I look inside my compiler, I can see these sets of enums to describe
scope (not C code):

(function_scope, "Fn"), !within a function (note
import/exported names can be declared in a block scope)
(local_scope, "Loc"), !file-scope/not exported
(imported_scope, "Imp"), !imported from another module
(exported_scope, "Exp") !file-scope/exported
end

Within a function, there is an additional mechanism to deal with block
scopes. Plus another overall to deal with namespaces.

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.

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.

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

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

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

>> 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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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

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.