On Wed, 7 Feb 2024 19:53:53 +0000, bart wrote:

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

If you write “average” functions, you know what the answer is.

Some of us don’t write “average” functions.

On Wed, 07 Feb 2024 16:25:45 GMT, Scott Lurndal wrote:

> ... the linux kernel + busybox is probably the most common.

That “Ingenuity” Mars helicopter, that recently met its end after breaking
a rotor blade, ran Linux and other open-source software.

It was very much an afterthought project, a proof of concept, only meant
to last maybe 30 days. It ended up making dozens of flights over 3 years.

On 07/02/2024 20:37, David Brown wrote:
> 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.)

* The standard talks a lot about Linkage but there are no specific
lexical elements for those.

* Instead the standard uses lexical elements called 'storage-class
specifiers' to control what kind of linkage is applied to identifiers

* Because of this association, I use 'linkage symbol' to refer to those
particular tokens

* The tokens include 'typedef extern static'

6.2.2p3 says: "If the declaration of a file scope identifier for an
object or a function contains the storageclass specifier static, the
identifier has internal linkage."

So it talks about statics as having linkage of some kind. What did I
say? I said statics will never be linked to anything.

6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no
linkage', which is one of the three kinds of linkage (external,
internal, none).

So as far as I can see, statics and typedef are still lumped in to the
class of entities that have a form of linkage, and are part of the set
of tokens that control linkage.

---------------------------------------------------

This is to me is all a bit mixed up. Much as you dislike other languages
being brought in, they can give an enlightening perspective.

So for me, linking applies to all named entities that occupy memory, and
that have global/export scope.

But global/export scope applies also to all other named entities,
whether they occupy memory or not. I can show that here in in this chart:

M Scope? M Link? C Linkage?

Function names Y Y Y (internal/external)

Variable names Y Y Y (internal/external)

Enum names Y N ??

Named constants Y N --

Type names Y N Y (none)

Macro names Y N ??

Module names Y N --

(Type names include C's struct tags. Enum tags are not listed.)

In the M language, ALL user identifiers declared at file scope can be
imported and exported automatically by the language across modules.

This is the primary control method for visibility.

There is a special mechanism to import into a program/library, or export
from one. This is the only place linkage comes up, where those names
need to appear in EXE, DLL and OBJ file formats. Only functions and
variables (entities that have an address) are involved.

In the C column, ?? are identifiers that usually can't apppear in a
declaration with a storage class. And -- is for things not meaningful in C.

On 2024-02-07, bart <bc@freeuk.com> 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'm saying it's somewhat easier to make a compiler which produces an
object file than to produce a compiler that produces object files *and*
a linker that combines them.

There is all that code you don't have to write to produce object files,
read them, and link them. You don't have to solve the problem of how to
represent unresolved references in an externalized form in a file.

David made it clear he was referring to whole program optimization.

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

Yes, sorry. It is compiling C also: a certain revision of GNU C,
which is family of dialects in the C family.

> Mine at least is a more rigid subset.

Rigid? Where this subset it documented, other than in the code?

GNU C is documented, and tested.

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

That's may be verbal way of expressing what a lot of developers
want, but it it has to be carefully interpreted to avoid a fallacy.

"Most people" expect the C compiler to work on /their/ respective code
they care about, which is different based on who you ask. The more
people you include in a sample of "most people", the more code that is.

Most people don't just expect a compiler to work on /your/ few examples.

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

Oh I want to believe; I just can't do that which I want, without
proper evidence.

Do you have a reference manual for your C dialect, and is it covered by
tests? What programs and constructs are required to work in your C dialect?
What are required to be diagnosed? What is left undefined?

If you make changes to the compiler which accidentally cause it to stray
from the dialect, how are you informed?

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

That's amazingly large for an assembler. Is that stripped of debug info?

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

I'm not interested in working on lower-level systems languages.

I work on a the implementation of a Lisp dialect.

As far as low-level systems goes, I'm quite satisfied with the C
language and its mainstream implementations.

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

Yes, because of the principle that you should test what you ship.

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

That someone will have to hack the superuser account, since those
files are writable only to root, sitting in directories that are
writable only to root.

You will know when someting complains about the file not being found.

(A problem will arise if the file is part of a search, such that another
file will be found if that one is missing.)

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

What if a bit randomly flips in mm.exe? Is it in a byte that is
essential? Who knows ... I don't see where this is going.

Sofware installations big and small can be damaged.

It seems disadvantageous for a compiler to have no satellite files. If
you have to fix something in <stdlib.h>, and that's buried in the
executable, you have to roll out a whole new mm.exe. The user has to
believe you when you say that you changed nothing else.

If the satellite files are kept reasonably small in number, and not
proliferated throughout a complex tree, that could be a good thing.

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

On 07/02/2024 21:38, Lawrence D'Oliveiro wrote:
> On Wed, 7 Feb 2024 19:53:53 +0000, bart wrote:
>
>> 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?
>
> If you write “average” functions, you know what the answer is.
>
> Some of us don’t write “average” functions.

Most functions are short and trivial. But those functions tend to be
easy to understnad and unlikely to have bugs. What matters is how you
write the longer functions.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 07/02/2024 20:44, David Brown wrote:
> On 07/02/2024 16:45, Malcolm McLean wrote:
>> On 07/02/2024 15:30, Ben Bacarisse wrote:
>>>
>>> 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.
>
> 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.
>
We must be able to point to at least one other language where it is not
the idiom, in order to say that it is an idiom.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-02-07, bart <bc@freeuk.com> wrote:
> * The standard talks a lot about Linkage but there are no specific
> lexical elements for those.

Yes; linkage doesn't have a dedicated phrase element in the syntax.

> * Instead the standard uses lexical elements called 'storage-class
> specifiers' to control what kind of linkage is applied to identifiers

Yes. "storage-class specifier" is just a syntactic category, a "part of
speech" of C.

Not everything that is syntactically a "storage class specifier"
determines the kind of storage for an object.

It's not really a great situation and it has gotten worse with the
introduction of new storage class keywords for alignment and whatnot.

> * Because of this association, I use 'linkage symbol' to refer to those
> particular tokens

Your one term for everything is equally flawed and just gratuitously
different.

> * The tokens include 'typedef extern static'

> 6.2.2p3 says: "If the declaration of a file scope identifier for an
> object or a function contains the storageclass specifier static, the
> identifier has internal linkage."

Yes. If it's a function it has no storage class. If it's an object
at file scope, its storage duration is static. The concept of storage
class doesn't apply to anything at file scope, in other words.

The syntax is instead abused for determining linkage.

> So it talks about statics as having linkage of some kind. What did I
> say? I said statics will never be linked to anything.

file scope statics have internal linkage for the reason that they
are allowed to be multiply defined. You're thining of linkage as some
object-file-level resolution mechanism.

In C, linkage just refers to the situation when multiple declarations of
an identifier are permitted, and refer to a single entity according
to some rule.

At file scope "static int x;" has linkage because you can
have a situation like this:
things liek this:

static int x; // declaration / tentative definition

void foo(void)
{
int x;
{
extern int x; // links to the file scope static
}
}

static int x; // declaration / tentative definition

static int x = 42; // definition

The linkage is internal because all these occurrences of x do not
refer to a file scope x in another translation unit.

This internal linkage is not necessarily handled by a linker. Since it
happens in one translation unit, the compiler can take care of it so
that the resulting object file has resolved all the internal linkage;
then the linkage of multiple translation units into a single program
only deals with external linkage. That can make external linkage appear
more "real".

> 6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no
> linkage', which is one of the three kinds of linkage (external,
> internal, none).
>
> So as far as I can see, statics and typedef are still lumped in to the
> class of entities that have a form of linkage, and are part of the set
> of tokens that control linkage.

No; typedef is just the "part of C speech" called "storage class
specifier". When a declaration has "typedef" storage class, it's
understood as defining a typedef name in that scope: file scope
or lexical.

The phrase element called "storage class" serves as a general "command
verb" kind of thing in the declaration (which may be omitted).

It should be renamed accordingly. Maybe "declaration kind" or
"declaration category" or "declaration class" or what have you.

Mainly, get rid of the word "storage".

Good names for entities are important. Sometimes the systems we use
don't get them right.

The naming of "storage class" is less important than the multiple
meanings of static and whatnot. Unlike grammar terminology, that can't
be fixed without breaking programs.

> This is to me is all a bit mixed up. Much as you dislike other languages
> being brought in, they can give an enlightening perspective.

Right, nobody here knows anything outside of C, or can think outside of
the C box, except for you.

You're the newsgroup's Prometheus.

The vultures eat your liver daily and everything.

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

On 2024-02-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 07/02/2024 20:44, David Brown wrote:
>> On 07/02/2024 16:45, Malcolm McLean wrote:
>>> On 07/02/2024 15:30, Ben Bacarisse wrote:
>>>>
>>>> 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.
>>
>> 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.
>>
> We must be able to point to at least one other language where it is not
> the idiom, in order to say that it is an idiom.

There are two meanings of *idiom*.

The "strong" meaning of idiom is that it's a meaning arbitrarily
assigned to a canned combination of words which otherwise make no
sense or are ungrammatical.

The "weak" meaning refers to some often used phrase.

Your proposed rule has a logical flaw because it requires us to confirm
that something is not an idiom in order to confirm that it is.
Even though that is in separate languages, it is still a problem.

Suppose that that all the literal translations of some phrase X into all
known languages are naively considered idioms by all their respective
speakers.

Then according to your criterion, none of the languages have the right
to consider it to be an idiom.

Suppos that English speakers are the first to realize this problem, and
choose to stop considering the English translation of X an idiom.

At that point, the other remaining languages may keep it as an idiom:
their speakers can now point to at least one language where it isn't.

Problem is, the choice of which group must stop treating it as an idiom,
so that the others may, is arbitrary.

This is not a well-founded definition for a term!

On Thu, 8 Feb 2024 00:33:35 +0000, Malcolm McLean wrote:

> We must be able to point to at least one other language where it is not
> the idiom, in order to say that it is an idiom.

How about pointing to alternative ways it might be said in the same
language, and then proclaiming that “for some reason, nobody who uses the
language is supposed to do it that way”?

On 07/02/2024 23:24, Kaz Kylheku wrote:
> On 2024-02-07, bart <bc@freeuk.com> 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'm saying it's somewhat easier to make a compiler which produces an
> object file than to produce a compiler that produces object files *and*
> a linker that combines them.

Is there a 'than' missing above? Otherwise it's contradictory.

> There is all that code you don't have to write to produce object files,
> read them, and link them. You don't have to solve the problem of how to
> represent unresolved references in an externalized form in a file.
Programs that generate object files usually invoke other people's linkers.

But your comments are simplistic. EXE formats can be as hard to generate
as OBJ files. You still have to resolve the dynamic imports into an EXE.

You need to either have a ready-made language designed for whole-program
work, or you need to devise one.

Plus, if the minimal compilation unit is now all N source modules of a
project rather than just 1 module, then you'd better have a pretty fast
compiler, and some strategies for dealing with scale.

If your project involves only OBJ format, then you can also choose to
devise your own simple file format, then linking is a trivial though
fiddly task.

> David made it clear he was referring to whole program optimization.
>
>>> 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>
>
> Yes, sorry. It is compiling C also: a certain revision of GNU C,
> which is family of dialects in the C family.
>
>> Mine at least is a more rigid subset.
>
> Rigid? Where this subset it documented, other than in the code?

In early versions of the compiler, there was a specification. Now, it's
a personal tool and I don't bother. So shoot me.

> GNU C is documented, and tested.
>
>>> 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!
>
> That's may be verbal way of expressing what a lot of developers
> want, but it it has to be carefully interpreted to avoid a fallacy.
>
> "Most people" expect the C compiler to work on /their/ respective code
> they care about, which is different based on who you ask. The more
> people you include in a sample of "most people", the more code that is.
>
> Most people don't just expect a compiler to work on /your/ few examples.

A C compiler that works on any arbitrary existing code is years of
effort. That's hard enough to achieve even with better and more mature
products than mine.

>>> 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.
>
> Oh I want to believe; I just can't do that which I want, without
> proper evidence.
>
> Do you have a reference manual for your C dialect, and is it covered by
> tests? What programs and constructs are required to work in your C dialect?
> What are required to be diagnosed? What is left undefined?

So no one can claim to write a 'C' compiler unless it does everything as
well as gcc which started in 1987, has had hordes of people working with
it, and has had feedback from myriads of users?

I had some particular aims with my project, most of which were achieved,
boxes ticked.

>> The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7%
>> smaller than your giant program.
>
> That's amazingly large for an assembler. Is that stripped of debug info?

The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it was 1.5MB.

Mine is about 100KB, but it covers a subset of x86 opcodes and outputs
only a limited number of formats.

But the size of NASM is not an issue; it's an example of modestly sized
application which seem rare. People here claim their apps are always so
massive and complicated that a 'toy' compiler will never work.

>> 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?
>
> Yes, because of the principle that you should test what you ship.

Then you're being silly. You're not shipping build#139 of 200 that day,
not even #1000 that week. You're debugging a logic bug that is nothing
to do with optimisation.

On 08/02/2024 01:13, Kaz Kylheku wrote:
> On 2024-02-07, bart <bc@freeuk.com> wrote:

>> This is to me is all a bit mixed up. Much as you dislike other languages
>> being brought in, they can give an enlightening perspective.
>
> Right, nobody here knows anything outside of C, or can think outside of
> the C box, except for you.

Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C;
(2) over such a long term; (3) which they have invented themselves; (4)
have implemented themselves; (5) is similar enough to C yet different
enough in how it works to give that perspective.

See, I gave an interesting comparison of how my module scheme works
orthogonally across all kinds of entities, compared with the confusing
mess of C, and you shut down that view.

You're never in a million years going to admit that my language has some
good points are you? Exactly as I said in my OP.

So what's the rule here, that people can only think INSIDE the C box?

Is the point of this group only to show off your master knowledge of C,
or the ins and outs of 300 kinds of Linux systems?

On 08/02/2024 01:38, Lawrence D'Oliveiro wrote:
> On Thu, 8 Feb 2024 00:33:35 +0000, Malcolm McLean wrote:
>
>> We must be able to point to at least one other language where it is not
>> the idiom, in order to say that it is an idiom.
>
> How about pointing to alternative ways it might be said in the same
> language, and then proclaiming that “for some reason, nobody who uses the
> language is supposed to do it that way”?

So how do you say "My French is lousy" in idomatic French?
Accroding to a Frenchman, it is "Doucement. Le Francais n'est pas ma
langue maternelle."
Now that means literally "Softly. The French is not my maternal language".
You wouldn't say that in English. You'd say "go easy" instead of
"softly". It would be "French" rather than "the French". And whilst you
might say "maternal language" it would be rare. Normally it would be
"native language".
So the French has one idiom and the English another, and we say things
in a slightly different way. What is the convention in one is not so in
the other, and that is what makes it idiom.

And of course the Frenchman made the point that whilst his information
was correct, to actually use his translation would be self-refuting.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-02-08, bart <bc@freeuk.com> wrote:
> On 07/02/2024 23:24, Kaz Kylheku wrote:
>> On 2024-02-07, bart <bc@freeuk.com> 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'm saying it's somewhat easier to make a compiler which produces an
>> object file than to produce a compiler that produces object files *and*
^^^^
>> a linker that combines them.
>
> Is there a 'than' missing above? Otherwise it's contradictory.

Other "than" that one? Hmm.

>> There is all that code you don't have to write to produce object files,
>> read them, and link them. You don't have to solve the problem of how to
>> represent unresolved references in an externalized form in a file.
> Programs that generate object files usually invoke other people's linkers.
>
> But your comments are simplistic. EXE formats can be as hard to generate
> as OBJ files. You still have to resolve the dynamic imports into an EXE.

Generating just the EXE format is objectively less work than generating
OBJ files and linking them into that ... same EXE format, right?

> You need to either have a ready-made language designed for whole-program
> work, or you need to devise one.
>
> Plus, if the minimal compilation unit is now all N source modules of a
> project rather than just 1 module, then you'd better have a pretty fast
> compiler, and some strategies for dealing with scale.

Easy; just drop language conformance, diagnostics, optimization.

>>> Well, don't believe it if you don't want.
>>
>> Oh I want to believe; I just can't do that which I want, without
>> proper evidence.
>>
>> Do you have a reference manual for your C dialect, and is it covered by
>> tests? What programs and constructs are required to work in your C dialect?
>> What are required to be diagnosed? What is left undefined?
>
> So no one can claim to write a 'C' compiler unless it does everything as
> well as gcc which started in 1987, has had hordes of people working with
> it, and has had feedback from myriads of users?

Nope; unless it is documented so that there is a box, where it says what
is in the box, and some way to tell that what's on the box is in the
box.

> I had some particular aims with my project, most of which were achieved,
> boxes ticked.
>
>>> The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7%
>>> smaller than your giant program.
>>
>> That's amazingly large for an assembler. Is that stripped of debug info?
>
> The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it was 1.5MB.

"as" on Ubuntu 18, 32 bit.

$ size /usr/bin/i686-linux-gnu-as
text data bss dec hex filename
430315 12544 37836 480695 755b7 /usr/bin/i686-linux-gnu-as

Still pretty large. Always use the "size" utility, rather than raw
file size. This has 430315 bytes of code, 12544 of non-zero static data, 37836
bytes of zeroed data (not part of the executable size).

That's still large for an assembler, but at least it's not larger
than GNU Awk.

>>> 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?
>>
>> Yes, because of the principle that you should test what you ship.
>
> Then you're being silly. You're not shipping build#139 of 200 that day,

If I make a certain change for build #139, and that part of the code
(function or entire source file) is not touched until build #1459 which
ships, that compiled code remains the same! So in fact, the #139 version of
that code is what build #1459 ships with. That code is being tested as part of
#140, #141, #142, ... even while some other things are changing.

You should not be doing all your development and developer testing with
unoptimized builds so that only Q&A people test optimized code before
shipping.

Every test, even of a private build, is a potential opportunity to find
something wrong with some optimized code that would end up shipping
otherwise.

Here is another reason to work with optimized code. If you have to debug
at the machine language level, optimized code is shorter and way more readable.
And it can help you understand logic bugs, because the compiler performs
logical analysis in doing optimizations. The optimized code shows you what your
calculation reduced to, and can even help you see a better way of writing the
code, like a tutor.

> not even #1000 that week. You're debugging a logic bug that is nothing
> to do with optimisation.

Though debugging logic bugs that have nothing to do with optimization can be
somewhat impeded by optimization, it's still better to prioritize working with
the code in the intended shipping state.

You can drop to an unoptimized build when necessary.

Pretty much that only happens when

1. It is just a logic bug, but you have to resort to a debugger, and
the optimizations are interfering with being able to see variable values.)

2. You suspect it does have to do with optimization, so you see if it
the issue goes away in the unoptimized build.

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

On 2024-02-08, bart <bc@freeuk.com> wrote:
> On 08/02/2024 01:13, Kaz Kylheku wrote:
>> On 2024-02-07, bart <bc@freeuk.com> wrote:
>
>>> This is to me is all a bit mixed up. Much as you dislike other languages
>>> being brought in, they can give an enlightening perspective.
>>
>> Right, nobody here knows anything outside of C, or can think outside of
>> the C box, except for you.
>
> Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C;
> (2) over such a long term; (3) which they have invented themselves; (4)
> have implemented themselves; (5) is similar enough to C yet different
> enough in how it works to give that perspective.

You've taken a perspective is not transferrable to others.

If one can only see something after using your own invention for many
years, and other people don't have that same invention and
implementation experience, then they just cannot see what you see.

You cannot teach (2) through (4), just like a basketball coach cannot
teach a player to be seven foot tall.

> See, I gave an interesting comparison of how my module scheme works
> orthogonally across all kinds of entities, compared with the confusing
> mess of C, and you shut down that view.
>
> You're never in a million years going to admit that my language has some
> good points are you? Exactly as I said in my OP.

I have no idea what it is; I've not seen the reference manual / spec,
and even if I did, I wouldn't have implemented it myself and used it for
a long time, so I don't have the right perspective.

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

On 2024-02-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 08/02/2024 01:38, Lawrence D'Oliveiro wrote:
>> On Thu, 8 Feb 2024 00:33:35 +0000, Malcolm McLean wrote:
>>
>>> We must be able to point to at least one other language where it is not
>>> the idiom, in order to say that it is an idiom.
>>
>> How about pointing to alternative ways it might be said in the same
>> language, and then proclaiming that “for some reason, nobody who uses the
>> language is supposed to do it that way”?
>
> So how do you say "My French is lousy" in idomatic French?

Je parle Quebecois.

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

On 07/02/2024 22:37, Michael S wrote:
> 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.

You are just a rounding error :-)

But it is interesting to hear of exceptions to the general trend.

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

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

>> But your comments are simplistic. EXE formats can be as hard to generate
>> as OBJ files. You still have to resolve the dynamic imports into an EXE.
>
> Generating just the EXE format is objectively less work than generating
> OBJ files and linking them into that ... same EXE format, right?

That depends:

* Are you generating OBJ files, or just ASM files and using a 3rd party
assembler?

* Are you producing OBJ files and relying on a 3rd party linker, or also
writing the linker?

* If the latter, are you using an official binary OBJ format, or
devising your own? That latter can make it a lot simpler.

And also, what exactly do you mean by a whole-program compiler?

I don't mean a C compiler which takes N source files at the same time,
compiles them internally, and links them internally. That's just
wrapping up all the steps involved in independent compilation into one
package.

>> Plus, if the minimal compilation unit is now all N source modules of a
>> project rather than just 1 module, then you'd better have a pretty fast
>> compiler, and some strategies for dealing with scale.
>
> Easy; just drop language conformance, diagnostics, optimization.

You're sceptical about something, I'm not sure what. Maybe you're used
to compilers taking forever to turn source into binary, so that you're
suspicious of anything that figures out how to do it faster.

Have you considered that recompiling after a one-line change, you don't
really the same in-depth analysis that you did 30 seconds ago?

/I/ am suspicious of compilers that produce a benchmark that completes
in 0.0 seconds, since it is most likely shirking the task that has been set.

> "as" on Ubuntu 18, 32 bit.
>
> $ size /usr/bin/i686-linux-gnu-as
> text data bss dec hex filename
> 430315 12544 37836 480695 755b7 /usr/bin/i686-linux-gnu-as
>
> Still pretty large. Always use the "size" utility, rather than raw
> file size. This has 430315 bytes of code, 12544 of non-zero static data, 37836
> bytes of zeroed data (not part of the executable size).

Raw file size is fine. The 'size' thing on my WSL shows that 'as' is
about 700KB for text and data.

BTW the same exercise on the 1.3MB NASM.EXE shwows the code as 0.3MB,
the rest is data. On my mcc compiler:

Compiling cc.m---------- to cc.exe
Code size: 186,647 bytes
Idata size: 86,392
Zdata size: 1,333,240
EXE size: 277,504

> That's still large for an assembler, but at least it's not larger
> than GNU Awk.

So Awk is another product that is still smaller than 1MB. Maybe there's
more of such programs than was thought!

But can you imagine if you're a developer of such a program, and being
told your product is a toy. Or being denied that use of a fast compiler,
because such a compiler will not scale to something that is 100x the size.

>>>> 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?
>>>
>>> Yes, because of the principle that you should test what you ship.
>>
>> Then you're being silly. You're not shipping build#139 of 200 that day,
>
> If I make a certain change for build #139, and that part of the code
> (function or entire source file) is not touched until build #1459 which
> ships, that compiled code remains the same! So in fact, the #139 version of
> that code is what build #1459 ships with. That code is being tested as part of
> #140, #141, #142, ... even while some other things are changing.
>
> You should not be doing all your development and developer testing with
> unoptimized builds so that only Q&A people test optimized code before
> shipping.
>
> Every test, even of a private build, is a potential opportunity to find
> something wrong with some optimized code that would end up shipping
> otherwise.

OK. This is entirely up to you. But then you can't complain when builds
routinely take makes minutes or even hours.

On the stuff I do, a whole-program build completes in about the time it
takes you to take your finger off the Enter key.

> Here is another reason to work with optimized code. If you have to debug
> at the machine language level, optimized code is shorter and way more readable.

I think the exact opposite is true, since optimised code can bear little
relation to the source code. The code may even have been elided.

> And it can help you understand logic bugs, because the compiler performs
> logical analysis in doing optimizations. The optimized code shows you what your
> calculation reduced to, and can even help you see a better way of writing the
> code, like a tutor.
>
>> not even #1000 that week. You're debugging a logic bug that is nothing
>> to do with optimisation.
>
> Though debugging logic bugs that have nothing to do with optimization can be
> somewhat impeded by optimization, it's still better to prioritize working with
> the code in the intended shipping state.
>
> You can drop to an unoptimized build when necessary.
>
> Pretty much that only happens when
>
> 1. It is just a logic bug, but you have to resort to a debugger, and
> the optimizations are interfering with being able to see variable values.)
>
> 2. You suspect it does have to do with optimization, so you see if it
> the issue goes away in the unoptimized build.

My method is to do 99.99% of builds unoptimised. The program may or may
not be in C.

If I want the finished program to be faster, then I can transpile to C
if necessary, and invoke an optimising C compiler. Or I can just supply
some C source to somebody and they can do what they like.

Millions of people code in scripting languages where there is no deep
analysis or optimisation at all. And yet they manage. Behind the scenes
there will be a fast bytecode compiler that does little other than
generated code that corresponds 99% to the source code.

But you're saying that as soon as you step over the line into AOT
compiled code, nothing less than full -O3 with a million other options
will do FOR EVERY SINGLE CCOMPILATION, even if the only change is to add
an extra space to a string literal because some message annoyingly
doens't line up?

OKay....

On Thu, 8 Feb 2024 02:50:08 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-08, bart <bc@freeuk.com> wrote:
> > On 07/02/2024 23:24, Kaz Kylheku wrote:
> >> On 2024-02-07, bart <bc@freeuk.com> 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'm saying it's somewhat easier to make a compiler which produces
> >> an object file than to produce a compiler that produces object
> >> files *and*
> ^^^^
> >> a linker that combines them.
> >
> > Is there a 'than' missing above? Otherwise it's contradictory.
>
> Other "than" that one? Hmm.
>
> >> There is all that code you don't have to write to produce object
> >> files, read them, and link them. You don't have to solve the
> >> problem of how to represent unresolved references in an
> >> externalized form in a file.
> > Programs that generate object files usually invoke other people's
> > linkers.
> >
> > But your comments are simplistic. EXE formats can be as hard to
> > generate as OBJ files. You still have to resolve the dynamic
> > imports into an EXE.
>
> Generating just the EXE format is objectively less work than
> generating OBJ files and linking them into that ... same EXE format,
> right?
>
> > You need to either have a ready-made language designed for
> > whole-program work, or you need to devise one.
> >
> > Plus, if the minimal compilation unit is now all N source modules
> > of a project rather than just 1 module, then you'd better have a
> > pretty fast compiler, and some strategies for dealing with scale.
>
> Easy; just drop language conformance, diagnostics, optimization.
>
> >>> Well, don't believe it if you don't want.
> >>
> >> Oh I want to believe; I just can't do that which I want, without
> >> proper evidence.
> >>
> >> Do you have a reference manual for your C dialect, and is it
> >> covered by tests? What programs and constructs are required to
> >> work in your C dialect? What are required to be diagnosed? What is
> >> left undefined?
> >
> > So no one can claim to write a 'C' compiler unless it does
> > everything as well as gcc which started in 1987, has had hordes of
> > people working with it, and has had feedback from myriads of users?
> >
>
> Nope; unless it is documented so that there is a box, where it says
> what is in the box, and some way to tell that what's on the box is in
> the box.
>
> > I had some particular aims with my project, most of which were
> > achieved, boxes ticked.
> >
> >>> The NASM.EXE program is bit larger at 1.3MB for example, that's
> >>> 98.7% smaller than your giant program.
> >>
> >> That's amazingly large for an assembler. Is that stripped of debug
> >> info?
> >
> > The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it
> > was 1.5MB.
>
> "as" on Ubuntu 18, 32 bit.
>
> $ size /usr/bin/i686-linux-gnu-as
> text data bss dec hex filename
> 430315 12544 37836 480695 755b7 /usr/bin/i686-linux-gnu-as
>
> Still pretty large. Always use the "size" utility, rather than raw
> file size. This has 430315 bytes of code, 12544 of non-zero static
> data, 37836 bytes of zeroed data (not part of the executable size).
>

$ /mingw32/bin/as.exe --version
GNU assembler (GNU Binutils) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i686-w64-mingw32'.

$ size /mingw32/bin/as.exe
text data bss dec hex filename
2941952 10392 43416 2995760 2db630
C:/bin/msys64a/mingw32/bin/as.exe

$ /mingw64/bin/as.exe --version
GNU assembler (GNU Binutils) 2.39
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

$ size /mingw64/bin/as.exe
text data bss dec hex filename
2966156 14776 45216 3026148 2e2ce4
C:/bin/msys64a/mingw64/bin/as.exe

> That's still large for an assembler, but at least it's not larger
> than GNU Awk.
>

$ awk --version
GNU Awk 5.1.1, API: 3.1 (GNU MPFR 4.1.0-p13, GNU MP 6.2.1)
Copyright (C) 1989, 1991-2021 Free Software Foundation.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.

$ size /usr/bin/awk.exe
text data bss dec hex filename
619497 15884 23104 658485 a0c35 C:/bin/msys64a/usr/bin/awk.exe

Looks like on msys2 GNU as is much larger than GNU awk.

On Wed, 07 Feb 2024 16:21:25 GMT
scott@slp53.sl.home (Scott Lurndal) 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 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.

That's completely orthogonal to the scope of declaration, at least as
long as compiler is not completely idiotic.

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.

It's spin, because the term is emotive. "Cluttering up" is how you feel
about it. The phrase is just a mildly pejorative one about appearances.
There's no substance there. To make a technical point you would have to
explain how, for example,

struct item *items;
...
n_elements = get_number_of_items(...);
items = malloc(n_elements * sizeof *items);
...

is technically better than

n_elements = get_number_of_items(...);
struct item *items = malloc(n_elements * sizeof *items);

I've explained (more than once) how I find reasoning about the direct
initialise at first use style easier with fewer distractions.

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

I agree. That's one big win for languages like Haskell with
sophisticated type inference. But the discussion (here) should be about
C where the disagreement is only about where to put the declaration.

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

That's not a related example. No one is suggesting anything remotely
like this.

This is why I keep asking if you have some political (or PR) background.
There is no reason at all to present an example where type information
is removed from the function prototype because no one is suggesting
that. It's a straw-man that you can argue against where, presumably,
you don't want to argue in favour of splitting the declaration away from
the point of first use.

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

That's fine. I have other concerns that I feel trump rather subjective
notions of aesthetics.

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

Avoiding incorrect use of technical terms never gets in the way of
writing clear and easy to understand explanations. Quite the reverse.
If you try to explain C's notions of scope and linkage by mixing them up
into terms like "global variables" you can only sow confusion.

But you rather like that:

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

You /could/ explain what the term linkage means in relation to C
identifiers, but your preference is rarely to help people understand.
You'd rather just make a snide remark: "look, the C standard uses an
ordinary English word in a way that is not normal!".

--
Ben.

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

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

Where do you get your superior knowledge of English from, and is there a
way anyone else can hope to achieve your level of competence?

--
Ben.

On 07/02/2024 23:52, bart wrote:
> On 07/02/2024 20:37, David Brown wrote:
>> 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.)
>
> * The standard talks a lot about Linkage but there are no specific
> lexical elements for those.
>
> * Instead the standard uses lexical elements called 'storage-class
> specifiers' to control what kind of linkage is applied to identifiers
>
> * Because of this association, I use 'linkage symbol' to refer to those
> particular tokens

So I was correct that you were mixing things up, and can't provide a
reference in the C standards?

You are correct that there are no lexical elements that explicitly
control linkage, and that storage-class specifiers can affect linking.
That does not mean linkage is determined solely by storage-class
specifiers, nor does it mean all storage-class specifiers affect
linkage. They cover related, but separate concepts. (It's a bit like
scope and lifetime - they are related, but they are not the same thing.)

>
> * The tokens include 'typedef extern static'

They also include _Thread_local, auto and register.

And pay attention to 6.7.1p5 :
"""
The typedef specifier is called a "storage-class specifier" for
syntactic convenience only;
"""

>
> 6.2.2p3 says: "If the declaration of a file scope identifier for an
> object or a function contains the storageclass specifier static, the
> identifier has internal linkage."
>
> So it talks about statics as having linkage of some kind. What did I
> say? I said statics will never be linked to anything.

They have "internal linkage". This means they are allocated space (in
ram for objects, code space for functions) by the linker, but static
symbols from one translation unit do not link to the same names from
other units.

This is distinct from "external linkage", where space is allocated,
identical symbols from different units are linked together, you must
have no more than one definition (but you can have multiple
declarations), and the definition and declarations must match in type.

And it is distinct from "no linkage" - things that are not involved in
the linking process, and have no connection between the identifier and
an item in memory (code or data). Things like typedef names, non-static
local variables, struct tags, and macro names are amongst the things
that have no linkage.

So static objects, with internal linkage, /are/ linked - the use of the
identifier in the source code is linked to the linker-allocated memory
address (relative or absolute, depending on the kind of linking and kind
of target).

>
> 6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no
> linkage', which is one of the three kinds of linkage (external,
> internal, none).

It is not by omission - it is covered in 6.2.2p6.

>
> So as far as I can see, statics and typedef are still lumped in to the
> class of entities that have a form of linkage, and are part of the set
> of tokens that control linkage.

No, you are mistaken. But I can understand how you got it wrong, and I
hope my post here can help clear it up.

Your mixup stems from a limited view of "linking". You are viewing the
term to mean something like "linking identical global identifiers from
different units so that they refer to the same object". That is part of
the process, but it /also/ means "linking identifiers and references
with code or data memory areas". That applies equally to static data
(with C "internal linkage") as to "global" data (with "external
linkage") - but it does /not/ apply to things with "no linkage".

>
> ---------------------------------------------------
>
> This is to me is all a bit mixed up. Much as you dislike other languages
> being brought in, they can give an enlightening perspective.

They can't give much help with terms unless they are established
languages, and even then the terms can vary significantly between languages.

This is about your misunderstanding of the term "linkage" - at most,
references to your language could illustrate what you have got wrong.
But I think that has already been established and does not need extra help.

>
> So for me, linking applies to all named entities that occupy memory,

Yes.

> and
> that have global/export scope.

No. It is that extra restriction here that is wrong.

(And "global scope" is a /really/ bad term to use. Scope is about when
an identifier is visible in a program, and is not the same as linkage or
lifetime. I know what you are trying to say here, but it is not an
accurate term.)

On 08/02/2024 11:37, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> That sounds like your opinion against mine. It's nothing to do with spin,
>> whatever that means.
>
> It's spin, because the term is emotive. "Cluttering up" is how you feel
> about it. The phrase is just a mildly pejorative one about appearances.
> There's no substance there. To make a technical point you would have to
> explain how, for example,
>
> struct item *items;
> ...
> n_elements = get_number_of_items(...);
> items = malloc(n_elements * sizeof *items);
> ...
>
> is technically better than
>
> n_elements = get_number_of_items(...);
> struct item *items = malloc(n_elements * sizeof *items);
>
> I've explained (more than once) how I find reasoning about the direct
> initialise at first use style easier with fewer distractions.
>
items = malloc(n_elements * sizeof *items);

is shorter than

struct item *items = malloc(n_elements * sizeof *items);

and that is an objective statement about which there can be no dispute.

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

On 08/02/2024 11:45, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> 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.
>
> Where do you get your superior knowledge of English from, and is there a
> way anyone else can hope to achieve your level of competence?
>
Degree in English literature.
Places are difficult to obtain but not impossible. You need to convince
the dons that you deserve one as many other people will be after them.

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

On 08/02/2024 13:10, Malcolm McLean wrote:
> On 08/02/2024 11:37, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> That sounds like your opinion against mine. It's nothing to do with
>>> spin,
>>> whatever that means.
>>
>> It's spin, because the term is emotive.  "Cluttering up" is how you feel
>> about it.  The phrase is just a mildly pejorative one about appearances.
>> There's no substance there.  To make a technical point you would have to
>> explain how, for example,
>>
>>     struct item *items;
>>     ...
>>     n_elements = get_number_of_items(...);
>>     items = malloc(n_elements * sizeof *items);
>>     ...
>>
>> is technically better than
>>
>>     n_elements = get_number_of_items(...);
>>     struct item *items = malloc(n_elements * sizeof *items);
>>
>> I've explained (more than once) how I find reasoning about the direct
>> initialise at first use style easier with fewer distractions.
>>
> items = malloc(n_elements * sizeof *items);
>
> is shorter than
>
> struct item *items = malloc(n_elements * sizeof *items);
>
> and that is an objective statement about which there can be no dispute.
>

But that is not the comparison.

struct item *items = malloc(n_elements * sizeof *items);

is shorter than:

struct item *items;
items = malloc(n_elements * sizeof *items);

You have to define the variable somewhere. Doing so when you initialise
it when you first need it, is, without doubt, objectively shorter.
Opinions may differ on whether it is clearer, or "cluttered", but which
is shorter is not in doubt. (What relevance that might have, is much
more in doubt.)