Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402418 > unrolled thread

official library of tiny functions lacking in c

Back to article view | Back to comp.lang.c

Contents

  official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 10:20 +0200
    Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 20:04 +0200
      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-27 21:38 +0100
        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 23:16 +0200
          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 00:53 +0100
            Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 04:31 +0200
            Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 10:25 +0200
              Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:45 +0100
                Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 13:56 +0200
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 14:38 +0100
                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 16:12 +0200
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:52 +0100
                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 18:49 +0200
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 20:26 +0100
                            Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:45 +0200
                              Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 12:54 +0100
                                Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 15:56 +0200
                                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 18:15 +0100
                                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 20:24 +0200
                                      Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 19:41 +0000
                                        Re: official library of tiny functions lacking in c cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-29 21:37 +0000
                                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:33 +0100
                                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:28 +0200
                                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 13:41 +0300
                                              Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:25 -0700
                                                Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 17:50 +0300
                                                  Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 09:37 -0700
                                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:19 +0100
                                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:44 +0200
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 16:01 +0200
                                Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 01:00 -0700
                                  Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 13:01 +0200
                                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:52 +0000
                            Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:56 +0000
                            Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:15 -0700
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:28 +0200
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:10 +0000
                      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:30 -0700
                      Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:03 +0200
                        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 11:11 +0100
                          Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:38 +0000
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:02 +0200
                            Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 11:35 +0100
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:14 +0200
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:45 +0100
                                  Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 15:30 +0200
                                    Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 17:14 +0300
                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 16:42 +0200
                                        Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 18:02 +0300
                                    Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 16:54 +0100
                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 18:26 +0200
                                        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 22:12 +0100
                                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 09:44 +0200
                                            Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 10:42 +0100
                                              Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 13:50 +0300
                                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 12:29 +0100
                                                  Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 09:35 +0200
                                                    Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 04:03 -0700
                                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 13:50 +0200
                                                        Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 11:22 -0700
                                                          Re: official library of tiny functions lacking in c gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-02 18:33 +0000
                                                          Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-03 14:30 +0000
                                                            Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:37 -0700
                                              Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 13:29 +0200
                                            Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-01 14:46 +0000
                                            Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:37 -0700
                                              Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 08:57 +0200
                                                Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-02 00:37 -0700
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 17:12 +0100
                        Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:09 +0300
                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 13:55 +0200
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:31 +0200
                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 16:12 +0300
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 19:33 +0200
                                Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-30 18:14 +0000
                          Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:34 -0400
                    Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:08 +0000
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 15:02 +0100
                        Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:43 +0000
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 16:07 +0100
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:58 +0000
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 00:13 +0100
                            Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 07:13 +0000
                              Re: official library of tiny functions lacking in c Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-01 02:41 +0800
                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:15 +0300
                              Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:18 +0300
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:24 +0100
                                  Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:45 +0200
                                  Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 15:56 +0300
                                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:31 +0000
                          Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:32 +0300
                  Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 17:22 +0200
                  Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-28 17:24 -0700
                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:54 +0200
                      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:48 -0700
                Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 14:16 +0200
                Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:15 -0400
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:40 +0100
                    Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:50 -0700
                Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 06:38 +0000
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 14:36 +0100
                    Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:49 +0000
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 23:59 +0100
                        Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:51 -0700
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:54 +0000
                    Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-29 22:09 -0400
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 10:52 +0100
                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 12:38 +0200
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:49 +0000
                        Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:48 -0400
      Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 06:45 +0000
        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 12:42 +0200
          Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:58 +0000
            Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 03:02 +0200
              Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:16 +0000
                Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 14:20 +0200
                  Re: official library of tiny functions lacking in c Paul <nospam@needed.invalid> - 2026-09-29 12:39 -0400
                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:50 +0000
                    Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 02:57 +0200
                      Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:00 +0000
                        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 10:08 +0200
                          Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 13:58 +0200
        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:43 +0100
          Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 01:00 +0000
          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:59 +0200
        Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:03 -0400
      Re: official library of tiny functions lacking in c NOTE fir <profesor.fir@gmail.com> - 2026-09-28 17:50 +0200
      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 12:42 -0700
    Re: official library of tiny functions lacking in c tTh <tth@none.invalid> - 2026-09-28 00:02 +0200

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#402509

bart <bc@freeuk.com> writes:
>On 29/09/2026 08:03, Janis Papanagnou wrote:
>> On 2026-09-28 16:12, David Brown wrote:

>You can see the same thing in file systems: in older Windows shells, it 
>will first look up a file ABC in the current directory. In newer ones 
>and on Linux, that is not allowed, you have to do ./ABC or .\ABC to 
>explicitly refer to the local version.

You are referring, of course, to the algorithms used to locate
the executable corresponding to a command that is not built-in
to the shell.

Your characterization of Unix-like systems is incorrect.  If you
specify '.' in the $PATH environment variable, the shell will
happily look in the current working directory when searching
for an executable.

I suspect the same might even be true for DOS.

Given that it is a security issue to include '.'
in the PATH, it is not there by default on most
distributions.

[toc] | [prev] | [next] | [standalone]

#402538

On 2026-09-29 12:11, bart wrote:
> On 29/09/2026 08:03, Janis Papanagnou wrote:
>> On 2026-09-28 16:12, David Brown wrote:
>>> On 28/09/2026 15:38, bart wrote:
>>>>
>>>> - Always available without needing those annoying #includes (and is
>>>>    it math.h or float.h? I can never remember).
>>>
>>> Other C programmers manage that without effort.
>>
>> I seem to recall that on his platform there's no man-pages.
>> (Or that he, maybe, dislikes looking into the documentation?
>> Sometime he gives that impression.)
>>
>>>
>>>> (Funny how shadowing or overriding is usually perceived as bad, 
>>>> until you want to shadow something like 'sin' then it's a must-have!)
>>
>> Since when is shadowing (or "overriding" in its various forms)
>> "perceived as bad"? - I've always seen it as a useful feature.
>> And never heard anyone complaining about it.
> 
> It can be useful, it can also introduce subtle bugs if done inadvertently.

I interpret it that as that you are telling me that *you* introduced
"subtle bugs". (Okay, we know you, so that is not too surprising. But
I rather suspect you are just saying that just to make an argument.)

> 
> For example you are using a global name inside a function but also 
> happen to define a local of that name, so the global one is hidden.

That is the point of shadowing! If you introduce a new name in an
embedded local context you do so to want to refer to that. That's
the whole point of shadowing that you don't get errors but can use
a local name instance without interference and without destroying
a "global" value of the same name.

Would you prefer a language without hierarchical blocks, scopes,
and shadowing?! (rhetoric)

> 
> Of you forget to define a local variable and accidentally overwrite, or 
> just use, the global version.

This is obviously your personal problem; operating on something you
haven't declared is not a problem of shadowing.

Shadowing is a sensible, useful, and safe concept that appeared with
block structured, stack oriented languages (I think with Algol 60),
and which had been inherited for good reasons to most (if not all)
subsequently appearing languages that support blocks and local scopes.

> 
> You can see the same thing in file systems: [...]

That is something completely different; you are shifting the goalpost!
(I won't explain you the PATH concept here, or why it is very useful.
And some things have already been explained elsethread by Scott.)

Janis

[toc] | [prev] | [next] | [standalone]

#402547

On 30/09/2026 06:02, Janis Papanagnou wrote:
> On 2026-09-29 12:11, bart wrote:

> Would you prefer a language without hierarchical blocks, scopes,
> and shadowing?! (rhetoric)
I do without block-scopes.

> Of you forget to define a local variable and accidentally overwrite, 
>> or just use, the global version.
> 
> This is obviously your personal problem;

Fuck you and your personal vendetta.

It is a problem for ANYBODY; people make mistakes: they forget, they 
inadvertently comment out, they make typos, they choose a local that is 
also a needed global.

Those errors are generally not reported so long as the program is still 
valid.

Of course, in your world everyone except me is perfect: you never make 
any such errors!

I'm not arguing against shadowing, just pointing out some issues.


Here's one of many internet quotes:

"Variable shadowing happens when a local variable or parameter uses the 
same name as a variable in an outer scope. This causes the inner 
variable to hide (“shadow”) the outer one, leading to bugs that can 
break your code in subtle ways — costing companies millions."

And another:

"Variable shadowing itself is not inherently bad. The trouble comes when 
it happens unintentionally,"

So again, fuck you for your CONSTANT FUCKING PERSONAL INSULTS.


>> You can see the same thing in file systems: [...]
> 
> That is something completely different; you are shifting the goalpost!
> (I won't explain you the PATH concept here, or why it is very useful.
> And some things have already been explained elsethread by Scott.)
No, please do explain how it is different.

To me it looks the same: a compiler uses some name-resolution scheme 
that works across a hierarchy, so does a file system.

A file system may choose not to automatically search in the local 
context first: what are the reasons, and could those reasons apply to 
scoped variables too?

[toc] | [prev] | [next] | [standalone]

#402558

On 2026-09-30 12:35, bart wrote:
> On 30/09/2026 06:02, Janis Papanagnou wrote:
>> On 2026-09-29 12:11, bart wrote:
> 
>> Would you prefer a language without hierarchical blocks, scopes,
>> and shadowing?! (rhetoric)
>
> I do without block-scopes.

We know you are doing a lot things and omitting yet more things than
other experienced CS folks. I wonder that you still think the Sun is
rotating around the Earth.

> 
>> Of you forget to define a local variable and accidentally overwrite,
>>> or just use, the global version.
>>
>> This is obviously your personal problem;
> 
> Fuck you and your personal vendetta.

You are again hallucinating things that are non-existing.

> 
> It is a problem for ANYBODY; people make mistakes: they forget, they 
> inadvertently comment out, they make typos, they choose a local that is 
> also a needed global.

You are again making unsubstantiated statements about "anybody" and
"people" in general. - All we can see is that obviously *you* have a
problem here where others don't. (Call it [wrongly] "vendetta" if it
makes you feel better and continue with your ignorance, it won't
change the world.)

> 
> Those errors are generally not reported so long as the program is still 
> valid.

You are very generous with such "general" statements. You've regularly
demonstrated that you have actually no clue about the world outside
your bubble and limited imagination, and (only?) stubbornness hinders
you to acknowledge reports about the concrete (CS and IT) world. - If
you'd be just a bit smarter you'd recognize that you cannot in principle
and substantially backup such claims.

> 
> Of course, in your world everyone except me is perfect: you never make 
> any such errors!

Again a standard phrase as a result of your pathological mental stance.
You make up stupid wrong generalizing statements about "everyone" that
no one has ever said or assumed.

You seem to be assuming that scopes are bad, and the consequent design
decisions of shadowing in block oriented scoped languages a collective
bad design decision of the language designer, scientists, and language
users (the programmers). - Can you, for a moment, shut up (i.e. not
immediately write another post), and take the time pondering about the
situation. - Is your hubris really so huge, your recognition of all the
existing expertise so non-existent, and your perception that impaired?
(again rhetoric; but you like to answer anyway as we saw above)

> 
> I'm not arguing against shadowing, just pointing out some issues.
> 
> 
> Here's one of many internet quotes:
> 
> "Variable shadowing happens when a local variable or parameter uses the 
> same name as a variable in an outer scope. This causes the inner 
> variable to hide (“shadow”) the outer one, leading to bugs that can 
> break your code in subtle ways — costing companies millions."

This looks like an unsubstantiated AI quote.

> 
> And another:
> 
> "Variable shadowing itself is not inherently bad. The trouble comes when 
> it happens unintentionally,"

This has already been addressed, but you still quote it; why? - I see
that the relevant part is not explained, there's no substance.

Both quotes are vague ("leading to bugs that can break your code in
subtle ways", "it happens unintentionally") and just FUD.

> 
> So again, fuck you for your CONSTANT FUCKING PERSONAL INSULTS.

You mean when I point out that you are hallucinating, presenting your
personal opinions as facts, don't give substantiated arguments, make
wrong presumptions about what people think, making wrong generalizing
claims, quote non-substantiated statements from own brain or from the
net arbitrarily. - I'd really appreciate if you'd omit all that; it
would make communication with you much easier. But sadly, despite you
are regularly hinted at that, to omit that, you continue that way. -
What do you expect? (rhetoric again)

> 
> 
>>> You can see the same thing in file systems: [...]
>>
>> That is something completely different; you are shifting the goalpost!
>> (I won't explain you the PATH concept here, or why it is very useful.
>> And some things have already been explained elsethread by Scott.)
> No, please do explain how it is different.
> 
> To me it looks the same: a compiler uses some name-resolution scheme 
> that works across a hierarchy, so does a file system.

But they are factually completely different. - The PATH is there to
primarily address _dedicated_ locations for executable programs. It
defines a strict precedence, say, that a user's $HOME/bin program
takes precedence over a system binary, or that a global 'local/bin'
installed software has precedence over the system installation. Its
purpose is to control the "precedence path". And a user can define
that in any way he seems it best fitting. - In scoped nested blocks
it's a completely different intention and logic; the programmer does
not need to know or track every variable instance, he can generally
operate locally without affecting the surrounding variables. Say, you
need an index, just declare "int i;" and use it; it won't affect any
'i' declared on some outer, distinct, external, wherever item. You are
completely safe. And if you're leaving that scope no other variable
with the same name in the reach of the environment is tackled. That's
really a great principle! (And hard to imaging to have no blocks with
scope and shadowing when we want to do safe structured programming.)

Actually, since you made up that (IMO inappropriate) PATH comparison;
if you want to compare the shadowing with Unix mechanisms consider
the environment variables instead; they can be exported to sub-shells,
you can declare your own variables in sub-processes, none affects any
outer variables. - This as well is not the same as shadowing in scopes
of blocks but it better explains about the principle concept to have
changes in sub-components of hierarchical structures not affecting the
environment, the "outer blocks". - Try to understand that principle
that we can find in many (also non-IT) places; it really makes sense.
And, again, before getting rabid again and send another post, *please*
_think about it_.

(I don't believe you will be able to change your habit or even become
enlightened, but... - well, we'll see.)

> 
> A file system may choose not to automatically search in the local 
> context first: what are the reasons, and could those reasons apply to 
> scoped variables too?

This statement shows that you are completely uninformed about what you
have chosen to pick as comparison. - I'm sure I've read it had already
been answered elsethread. Why do you ignore that? Why don't you inform
yourself before making false and stupid statements? (rhetoric)

(You're amazingly ignorant, and obviously keen to maintain that state.)

Janis

[toc] | [prev] | [next] | [standalone]

#402563

On 30/09/2026 13:14, Janis Papanagnou wrote:


> You mean when I point out that you are hallucinating, presenting your
> personal opinions as facts,

About shadowing? Michael S made similar remarks to mine. Perhaps he's 
hallucinating too.

>> To me it looks the same: a compiler uses some name-resolution scheme 
>> that works across a hierarchy, so does a file system.
> 
> But they are factually completely different.

Is there a hierarchy in both cases?

Is there a scheme/algorithm involved in both cases?

Is there a way to override or control behaviour in both cases?

Is there way to denote qualifier chains in both cases? (Eg. a/b/c
    or a.b.c)

The answers are Yes or No to each.

If they are all Yes than they are not 'completely different'.

The details are not relevant - we know that a file system is not 
language source code.

> (I don't believe you will be able to change your habit or even become
> enlightened, but... - well, we'll see.)

Sadly you're not going to change /your/ habits. What a nasty, vindictive 
  attitude you have.

[toc] | [prev] | [next] | [standalone]

#402566

On 30/09/2026 14:45, bart wrote:
> On 30/09/2026 13:14, Janis Papanagnou wrote:
> 
> 
>> You mean when I point out that you are hallucinating, presenting your
>> personal opinions as facts,
> 
> About shadowing? Michael S made similar remarks to mine. Perhaps he's 
> hallucinating too.

Michael wrote that /sometimes/ shadowing hides bugs that might otherwise 
have been noticed by the programmer and/or trigger a compilation error. 
And some people and coding standards actively avoid shadowing.

That's all fair.

And it also shows that it is personal opinion - even when multiple 
people happen to share the same opinion.  Janis's opinions on shadowing 
are no more or less factual than yours, and no more or less valid.  You 
can dislike shadowing if you want, you can disable it in your language 
if you want, use "gcc -Wshadow" if you want.  But be careful about 
turning your preferences and personal experiences into generalisations 
and assuming they apply to others.  (I have been known to do that myself 
from time to time - it does not mean it is a good thing!)

(I don't believe Michael gave his own preferences for whether or not to 
try to avoid shadowing.  I'm guessing he aims to pick his identifier 
names in a way that makes his code as clear as he can reasonably make 
it, unless he is required to follow a style guide with rules on the matter.)

Support for shadowing is the norm for languages with scoped identifiers 
- identifiers in inner scopes can shadow those of outer scopes.  Things 
can be complicated when there are multiple types of scope in a language, 
but shadowing is pretty much essential for scalability of a language, 
even though it can usually be avoided.

gcc has warnings "-Wshadow-compatible-local" and "-Wshadow=local" which 
warn on local variables shadowing each other, which can be a good 
compromise for what to avoid without risking false positives.  But it's 
a personal style choice.

[toc] | [prev] | [next] | [standalone]

#402568

On Wed, 30 Sep 2026 15:30:29 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 30/09/2026 14:45, bart wrote:
> > On 30/09/2026 13:14, Janis Papanagnou wrote:
> > 
> >   
> >> You mean when I point out that you are hallucinating, presenting
> >> your personal opinions as facts,  
> > 
> > About shadowing? Michael S made similar remarks to mine. Perhaps
> > he's hallucinating too.  
> 
> Michael wrote that /sometimes/ shadowing hides bugs that might
> otherwise have been noticed by the programmer and/or trigger a
> compilation error. And some people and coding standards actively
> avoid shadowing.
> 
> That's all fair.
> 
> And it also shows that it is personal opinion - even when multiple 
> people happen to share the same opinion.  Janis's opinions on
> shadowing are no more or less factual than yours, and no more or less
> valid.  You can dislike shadowing if you want, you can disable it in
> your language if you want, use "gcc -Wshadow" if you want.  But be
> careful about turning your preferences and personal experiences into
> generalisations and assuming they apply to others.  (I have been
> known to do that myself from time to time - it does not mean it is a
> good thing!)
> 
> (I don't believe Michael gave his own preferences for whether or not
> to try to avoid shadowing.  I'm guessing he aims to pick his
> identifier names in a way that makes his code as clear as he can
> reasonably make it, unless he is required to follow a style guide
> with rules on the matter.)
> 
> Support for shadowing is the norm for languages with scoped
> identifiers 
> - identifiers in inner scopes can shadow those of outer scopes.

Generally yes, but there exist variations.
For example, in C# local variable in the inner block is not allowed to
to have the same name as local variable in the outer score.

Rust is extreme in opposite direction - shadowing is allowed even
without creation of the new block.  Although in this case shadowing is,
may be, not the best name.

> Things can be complicated when there are multiple types of scope in a
> language, but shadowing is pretty much essential for scalability of a
> language, even though it can usually be avoided.
> 
> gcc has warnings "-Wshadow-compatible-local" and "-Wshadow=local"
> which warn on local variables shadowing each other, which can be a
> good compromise for what to avoid without risking false positives.
> But it's a personal style choice.
> 

[toc] | [prev] | [next] | [standalone]

#402571

On 30/09/2026 16:14, Michael S wrote:
> On Wed, 30 Sep 2026 15:30:29 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 30/09/2026 14:45, bart wrote:
>>> On 30/09/2026 13:14, Janis Papanagnou wrote:
>>>
>>>    
>>>> You mean when I point out that you are hallucinating, presenting
>>>> your personal opinions as facts,
>>>
>>> About shadowing? Michael S made similar remarks to mine. Perhaps
>>> he's hallucinating too.
>>
>> Michael wrote that /sometimes/ shadowing hides bugs that might
>> otherwise have been noticed by the programmer and/or trigger a
>> compilation error. And some people and coding standards actively
>> avoid shadowing.
>>
>> That's all fair.
>>
>> And it also shows that it is personal opinion - even when multiple
>> people happen to share the same opinion.  Janis's opinions on
>> shadowing are no more or less factual than yours, and no more or less
>> valid.  You can dislike shadowing if you want, you can disable it in
>> your language if you want, use "gcc -Wshadow" if you want.  But be
>> careful about turning your preferences and personal experiences into
>> generalisations and assuming they apply to others.  (I have been
>> known to do that myself from time to time - it does not mean it is a
>> good thing!)
>>
>> (I don't believe Michael gave his own preferences for whether or not
>> to try to avoid shadowing.  I'm guessing he aims to pick his
>> identifier names in a way that makes his code as clear as he can
>> reasonably make it, unless he is required to follow a style guide
>> with rules on the matter.)
>>
>> Support for shadowing is the norm for languages with scoped
>> identifiers
>> - identifiers in inner scopes can shadow those of outer scopes.
> 
> Generally yes, but there exist variations.
> For example, in C# local variable in the inner block is not allowed to
> to have the same name as local variable in the outer score.
> 

I don't know C#, so thanks for that information.

> Rust is extreme in opposite direction - shadowing is allowed even
> without creation of the new block.  Although in this case shadowing is,
> may be, not the best name.
> 

I have always thought it would be nice in C and C++, to be able to 
re-declare variables (especially const "variables") without having to be 
able to introduce new blocks :

	const int data = get_next();
	do_first_thing(data);

	const int data = get_next();
	do_second_thing(data);

(The semantics would be basically as though a new block was introduced 
before the pair of lines.  Then let the compiler's lifetime analysis 
handle efficient re-use of registers and stack slots.)

While it could lead to confusing code sometimes, I think it could also 
be helpful in code that has repetitive patterns.  As it is, you need to 
either have new names, make the variable non-const, or include extra 
blocks around the sections.  I'd be quite happy if this were restricted 
to "const" objects.

Is that the sort of thing Rust allows here?	

>> Things can be complicated when there are multiple types of scope in a
>> language, but shadowing is pretty much essential for scalability of a
>> language, even though it can usually be avoided.
>>
>> gcc has warnings "-Wshadow-compatible-local" and "-Wshadow=local"
>> which warn on local variables shadowing each other, which can be a
>> good compromise for what to avoid without risking false positives.
>> But it's a personal style choice.
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#402572

On Wed, 30 Sep 2026 16:42:09 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 30/09/2026 16:14, Michael S wrote:
> > Rust is extreme in opposite direction - shadowing is allowed even
> > without creation of the new block.  Although in this case shadowing
> > is, may be, not the best name.
> >   
> 
> I have always thought it would be nice in C and C++, to be able to 
> re-declare variables (especially const "variables") without having to
> be able to introduce new blocks :
> 
> 	const int data = get_next();
> 	do_first_thing(data);
> 
> 	const int data = get_next();
> 	do_second_thing(data);
> 
> (The semantics would be basically as though a new block was
> introduced before the pair of lines.  Then let the compiler's
> lifetime analysis handle efficient re-use of registers and stack
> slots.)
> 
> While it could lead to confusing code sometimes, I think it could
> also be helpful in code that has repetitive patterns.  As it is, you
> need to either have new names, make the variable non-const, or
> include extra blocks around the sections.  I'd be quite happy if this
> were restricted to "const" objects.
> 
> Is that the sort of thing Rust allows here?	
> 

Yes, but it allows mutables as well. And different types.

[toc] | [prev] | [next] | [standalone]

#402573

On 30/09/2026 14:30, David Brown wrote:
> On 30/09/2026 14:45, bart wrote:
>> On 30/09/2026 13:14, Janis Papanagnou wrote:
>>
>>
>>> You mean when I point out that you are hallucinating, presenting your
>>> personal opinions as facts,
>>
>> About shadowing? Michael S made similar remarks to mine. Perhaps he's 
>> hallucinating too.
> 
> Michael wrote that /sometimes/ shadowing hides bugs that might otherwise 
> have been noticed by the programmer and/or trigger a compilation error. 
> And some people and coding standards actively avoid shadowing.
> 
> That's all fair.
> 
> And it also shows that it is personal opinion - even when multiple 
> people happen to share the same opinion.  Janis's opinions on shadowing 
> are no more or less factual than yours, and no more or less valid.  You 
> can dislike shadowing if you want,


I didn't give my opinions on it. I pointed out some issues with it.
Examples:

BC (me):

 >It can be useful, it can also introduce subtle bugs if done 
inadvertently.

JP:
 >I interpret it that as that you are telling me that *you* introduced
"subtle bugs". (Okay, we know you, so that is not too surprising. But
I rather suspect you are just saying that just to make an argument.)

BC:
 > Of you forget to define a local variable and accidentally overwrite, 
or just use, the global version.

JP:
 >This is obviously your personal problem; operating on something you
haven't declared is not a problem of shadowing.


JP about possible issues with shadowing:

 > And never heard anyone complaining about it.

 > In decades I also
 > don't recall that subtile (or obvious) errors had been reported
 > because of that. (Are you, yet again, just making things up for
 > the argument or have you any different observations from your
 > personal coding practice?)

Every single riposte from JP has to be a personal barb and insult, and 
of course dismisses my point 100% out of hand. Something wrong there.


> you can disable it in your language 
> if you want,

I don't like that inadvertent shadowing that leads to odd bugs isn't 
reported. But that is how it has worked for decades.

(However, one feature I have which is out-of-order definitions, together 
with the ability to omit having a main() wrapper around top-level 
executable statement, is very susceptible to such errors. So that has 
been banned on one language and in another is only used for throwaway 
programs.)

Clashes between the same imported name /are/ detected, so that I know to 
do something about it. Another approach would be to silently use the 
first match.

(I don't know what languages do that other than Python using 'from' 
imports. I don't know enough C++ to try it out via 'using'.)

[toc] | [prev] | [next] | [standalone]

#402577

On 30/09/2026 17:54, bart wrote:
> On 30/09/2026 14:30, David Brown wrote:
>> On 30/09/2026 14:45, bart wrote:
>>> On 30/09/2026 13:14, Janis Papanagnou wrote:
>>>

>> And it also shows that it is personal opinion - even when multiple 
>> people happen to share the same opinion.  Janis's opinions on 
>> shadowing are no more or less factual than yours, and no more or less 
>> valid.  You can dislike shadowing if you want,
> 
> 
> I didn't give my opinions on it. I pointed out some issues with it.

OK.  Let's drop this - nothing useful can be gained from continuing this 
bit.

>> you can disable it in your language if you want,
> 
> I don't like that inadvertent shadowing that leads to odd bugs isn't 
> reported. But that is how it has worked for decades.
> 
> (However, one feature I have which is out-of-order definitions, together 
> with the ability to omit having a main() wrapper around top-level 
> executable statement, is very susceptible to such errors. So that has 
> been banned on one language and in another is only used for throwaway 
> programs.)

Out-of-order definitions within a scope is susceptible to a lot of 
risks, unless it is quite restricted.  In particular, I would restrict 
it to constant "things" - constant objects and functions, and perhaps 
types.  I would hate to figure out what is going on with "x = 2;" 
followed by "int x = 3;" in the same scope.  (Maybe you don't allow 
initialisation in variable definitions?)

> 
> Clashes between the same imported name /are/ detected, so that I know to 
> do something about it. Another approach would be to silently use the 
> first match.
> 

Noisy errors on clashes are a good idea if there is no clear and 
consistent ordering.

> (I don't know what languages do that other than Python using 'from' 
> imports. I don't know enough C++ to try it out via 'using'.)
> 

Python is always a bit special in that it does not have the same 
compile-time / run-time distinction as C.  It actually requires that all 
identifiers are defined (bound) before use - but identifiers within a 
block in a function are not "used" until the code is actually run.  As 
you "run" the file itself, that binds the names declared at that scope. 
Identifiers are bound when they are run, overriding any previous binding 
for the same identifier at the same scope.  (It's just a new entry or 
update in the "__dir__" map for the appropriate object.)  Details beyond 
that are, of course, outside the scope of c.l.c.

[toc] | [prev] | [next] | [standalone]

#402589

On 30/09/2026 17:26, David Brown wrote:
> On 30/09/2026 17:54, bart wrote:

>> (However, one feature I have which is out-of-order definitions, 
>> together with the ability to omit having a main() wrapper around top- 
>> level executable statement, is very susceptible to such errors. So 
>> that has been banned on one language and in another is only used for 
>> throwaway programs.)
> 
> Out-of-order definitions within a scope is susceptible to a lot of 
> risks, unless it is quite restricted.  In particular, I would restrict 
> it to constant "things" - constant objects and functions, and perhaps 
> types.  I would hate to figure out what is going on with "x = 2;" 
> followed by "int x = 3;" in the same scope.  (Maybe you don't allow 
> initialisation in variable definitions?)

Names can be declared anywhere in a scope, even all at the end.

That is uncommon for manually written code, but it is highly useful for 
machine-generated code, when you don't have all the info needed for a 
declaration until the body of a function has been generated.

If there is a runtime initialisation for a variable, then that will be 
done at the declaration point. If that declaration is encountered again, 
it will be reinitialised.

C works the same way, except the name is not in scope until after the 
declaration.

This gives the side-effect of allowing two identifiers with the same 
name within the scope:

  int abc=100;                   // [1]

  int main() {
      printf("%d\n", abc);       // abc [1]
      char* abc="200";           // [2]
      printf("%s\n", abc);       // abc [2]
  }

This can give some odd effects: move that second declaration after the 
second printf, or comment it out, and it will go wrong. If it still 
compiles, you now have a bug.

(The problem I mentioned is this in my systems language:

    proc F(int n) =
        for i in 1..n do print "*" end
        println
    end

    for i in 1..5 do F(i) end

For-loop indices are auto-declared if no variable of that name is in 
scope. The second 'i' is thus declared to be 'int', at module scope, 
visible everywhere.

Inside F(), since no local 'i' has been declared, it will use that outer 
'i' and overwrite the caller's 'i' when it runs that loop.

Python has a similar problem, but it is not as bad since, if F tries to 
modify 'i', it assumes it is a local.)

>>
>> Clashes between the same imported name /are/ detected, so that I know 
>> to do something about it. Another approach would be to silently use 
>> the first match.
>>
> 
> Noisy errors on clashes are a good idea if there is no clear and 
> consistent ordering.
> 
>> (I don't know what languages do that other than Python using 'from' 
>> imports. I don't know enough C++ to try it out via 'using'.)

I've now tested C++, and with 'namespaces' and 'using', ambiguities are 
reported by g++.

(My scheme is more about modules, which also create a namespace; I've 
not attempted C++ modules.)

[toc] | [prev] | [next] | [standalone]

#402603

On 30/09/2026 23:12, bart wrote:
> On 30/09/2026 17:26, David Brown wrote:
>> On 30/09/2026 17:54, bart wrote:
> 
>>> (However, one feature I have which is out-of-order definitions, 
>>> together with the ability to omit having a main() wrapper around top- 
>>> level executable statement, is very susceptible to such errors. So 
>>> that has been banned on one language and in another is only used for 
>>> throwaway programs.)
>>
>> Out-of-order definitions within a scope is susceptible to a lot of 
>> risks, unless it is quite restricted.  In particular, I would restrict 
>> it to constant "things" - constant objects and functions, and perhaps 
>> types.  I would hate to figure out what is going on with "x = 2;" 
>> followed by "int x = 3;" in the same scope.  (Maybe you don't allow 
>> initialisation in variable definitions?)
> 
> Names can be declared anywhere in a scope, even all at the end.
> 
> That is uncommon for manually written code, but it is highly useful for 
> machine-generated code, when you don't have all the info needed for a 
> declaration until the body of a function has been generated.

I honestly have no use or sympathy for features like this that are to 
make life easier for machine-generation of code.  I cannot imagine that 
it is a major challenge to separate the "create the function" and the 
"write the function to the file" parts, and inject the declarations at 
the start of the written function instead of the end.

I do realise that you can take shortcuts when it is your private 
language, and the shortcuts save you time and effort in writing your 
tools.  But that does not apply to languages for other people.

> 
> If there is a runtime initialisation for a variable, then that will be 
> done at the declaration point. If that declaration is encountered again, 
> it will be reinitialised.

So what does this do?

	x = x + 1
	print x
	int x = 100


> 
> C works the same way, except the name is not in scope until after the 
> declaration.

No - you can't really "reinitialise" anything in C.  If you have :

	while (true)
	{				// line 0
		printf("Start\n");	// line 1
		int x = 1;		// line 2
		printf("X = %i\n", x);	// line 3
	}				// line 4

you are /not/ re-initialising "x" each pass through the loop.

As control flow enters the block in line 0, a new object of type "int" 
starts its lifetime.  It is as yet unnamed, uninitialised, and 
unconnected to any scope.

In line 2, after "int x" we now have a name for this int object, and its 
scope starts.  (The scope starts at that point, before the initialiser 
is evaluated and therefore before the declaration is complete.  Writing 
"int y = y;" attempts to initialise a new "y" with itself, even if there 
is another "y" declared in an outer scope.)  In the rest of line 2, the 
initialiser is evaluated and assigned to "x" - "initialisation" is the 
assignment that occurs in connection with the declaration, and has 
additional restrictions that do not apply in normal assignments.

Line 3 prints the value of "x".  Note that while executing the printf 
call, "x" is still within its lifetime, but not within its scope.

At line 4, the scope of "x" ends at the end of the block.  The lifetime 
of "x" also ends as it leaves the block.

When flow then goes back to the start of the block in line 0, a 
completely new int object is created, and a new variable "x" is bound to 
this and enters scope in line 2.

At no point is "x" reinitialised - it's a different "x" object for each 
pass of the loop.  And the scope of each "x" starts after the "int x" 
bit, before the declaration is complete.  (I personally would have 
preferred the scope to start after the initialisation, but C is what it 
is, and there are perhaps good reasons for that choice.)


It is possible to jump over a declaration, or "re-run" it, using goto. 
This is why lifetime - a run-time property - starts at the beginning of 
the block, while scope - a compile-time property - starts in the 
declaration.  In this example, there is only one "x", but it is never 
actually initialised.  (If the "x = 42;" line were removed, the first 
call to "foo(x)" would use an unspecified value and be UB.)  Instead, it 
is re-assigned each time flow passes through "int x = 12;", just like at 
"x = 42".

extern void foo(int x);
void bar(void) {
     goto a;
b:
     int x = 12;
     foo(x);
a:
     x = 42;
     foo(x);
     goto b;
}


> 
> This gives the side-effect of allowing two identifiers with the same 
> name within the scope:
> 
>   int abc=100;                   // [1]
> 
>   int main() {
>       printf("%d\n", abc);       // abc [1]
>       char* abc="200";           // [2]
>       printf("%s\n", abc);       // abc [2]
>   }
> 

That is not a side-effect - that is just how languages with scoped 
identifiers work.

And like most language features, it lets you write more useful correct 
code, and also lets you accidentally write other kinds of incorrect code.

> This can give some odd effects: move that second declaration after the 
> second printf, or comment it out, and it will go wrong. If it still 
> compiles, you now have a bug.
> 
> (The problem I mentioned is this in my systems language:
> 
>     proc F(int n) =
>         for i in 1..n do print "*" end
>         println
>     end
> 
>     for i in 1..5 do F(i) end
> 
> For-loop indices are auto-declared if no variable of that name is in 
> scope. The second 'i' is thus declared to be 'int', at module scope, 
> visible everywhere.

Your problem here, I would say, is inconsistent rules about declarations 
and when they must be explicit or are automatically declared, combined 
with poor choices of scoping rules.  If you want to have implicit 
declarations for your "for" loop variables, then make them /always/ 
implicit declarations, and always minimal scope.

> 
> Inside F(), since no local 'i' has been declared, it will use that outer 
> 'i' and overwrite the caller's 'i' when it runs that loop.
> 
> Python has a similar problem, but it is not as bad since, if F tries to 
> modify 'i', it assumes it is a local.)
> 
>>>
>>> Clashes between the same imported name /are/ detected, so that I know 
>>> to do something about it. Another approach would be to silently use 
>>> the first match.
>>>
>>
>> Noisy errors on clashes are a good idea if there is no clear and 
>> consistent ordering.
>>
>>> (I don't know what languages do that other than Python using 'from' 
>>> imports. I don't know enough C++ to try it out via 'using'.)
> 
> I've now tested C++, and with 'namespaces' and 'using', ambiguities are 
> reported by g++.
> 
> (My scheme is more about modules, which also create a namespace; I've 
> not attempted C++ modules.)
> 
> 

I recommend you do not think about C++ modules - they add a layer of 
complexity that will not help, and they are entirely orthogonal to 
namespaces.  (i.e., you don't need modules for namespaces, and modules 
do not implicitly use or declare namespaces.)  In particular, you can 
play around with namespaces, using, etc., on godbolt.org, but you can't 
practice modules there in any real way, since you only have one file.

[toc] | [prev] | [next] | [standalone]

#402611

On 01/10/2026 08:44, David Brown wrote:
> On 30/09/2026 23:12, bart wrote:
>> On 30/09/2026 17:26, David Brown wrote:
>>> On 30/09/2026 17:54, bart wrote:
>>
>>>> (However, one feature I have which is out-of-order definitions, 
>>>> together with the ability to omit having a main() wrapper around 
>>>> top- level executable statement, is very susceptible to such errors. 
>>>> So that has been banned on one language and in another is only used 
>>>> for throwaway programs.)
>>>
>>> Out-of-order definitions within a scope is susceptible to a lot of 
>>> risks, unless it is quite restricted.  In particular, I would 
>>> restrict it to constant "things" - constant objects and functions, 
>>> and perhaps types.  I would hate to figure out what is going on with 
>>> "x = 2;" followed by "int x = 3;" in the same scope.  (Maybe you 
>>> don't allow initialisation in variable definitions?)
>>
>> Names can be declared anywhere in a scope, even all at the end.
>>
>> That is uncommon for manually written code, but it is highly useful 
>> for machine-generated code, when you don't have all the info needed 
>> for a declaration until the body of a function has been generated.
> 
> I honestly have no use or sympathy for features like this that are to 
> make life easier for machine-generation of code.

That wasn't the intention. Just a convenient consequence.

C is commonly used as a compiler target; this was the first time I'd 
tried mine for such a purpose, and it worked great.

>  I cannot imagine that 
> it is a major challenge to separate the "create the function" and the 
> "write the function to the file" parts, and inject the declarations at 
> the start of the written function instead of the end.

It's already messy enough, you want to keep it simple. Here it is 
convenient to linearly build the output as one in-memory string.

>> If there is a runtime initialisation for a variable, then that will be 
>> done at the declaration point. If that declaration is encountered 
>> again, it will be reinitialised.
> 
> So what does this do?
> 
>      x = x + 1
>      print x
>      int x = 100

This would be equivalent to this C:

    {  int x;
       x = x + 1
       printf("%lld", x);
       x = 100;
    }

So it basically prints garbage. (My scripting language works a little 
differently: declaring x is optional, but if declared like the above, 
the initialisation is done on function entry. It will print 101.

This is an oversight though and needs to be brought into line. The two 
languages have been slowly converging.)


> 
> 
>>
>> C works the same way, except the name is not in scope until after the 
>> declaration.
> 
> No - you can't really "reinitialise" anything in C.  If you have :
> 
>      while (true)
>      {                // line 0
>          printf("Start\n");    // line 1
>          int x = 1;        // line 2
>          printf("X = %i\n", x);    // line 3
>      }                // line 4
> 
> you are /not/ re-initialising "x" each pass through the loop.

Having 'int x' at this point just limits its visibly from here to the 
end of the block. A compiler will tend to keep it in the same location 
(stack frame offset or register) each time through.

Some compilers may reuse the location for other purposes when lifetimes 
don't overlap (so x's value before 'int x =...' can't be assumed to be 
the same as its last value, if monitoring via a pointer reference in an 
outer scope).

Optimising compilers may do something else, such as elide the code 
completely.

It seems perfectly reasonable to refer to it as reinitialising if it is 
'encountered again'. After all, 'x' HAS been initialised at least once 
before!


> As control flow enters the block in line 0, a new object of type "int" 
> starts its lifetime.  It is as yet unnamed, uninitialised, and 
> unconnected to any scope.

Whoa - 'int x' is some way off yet, why should the compiler do anything 
at all at this point? In fact why should anything at all even be deemed 
to happen?

> (I personally would have 
> preferred the scope to start after the initialisation, but C is what it 
> is, and there are perhaps good reasons for that choice.)

That could mean overlapping visibility for identically named variables. 
Funnily enough however, my language can do your 'int y = y' example:

   int y = 999

   proc main =
       int y := test.y + 1    # module is called 'test'
       println y              # 1000
   end

But it needs to use a qualifier to refer to the outer 'y'.

(Since there are no block scopes, that other y must be outside the 
function.)

> It is possible to jump over a declaration, or "re-run" it, using goto. 
> This is why lifetime - a run-time property - starts at the beginning of 
> the block, while scope - a compile-time property - starts in the 
> declaration.  In this example, there is only one "x", but it is never 
> actually initialised.  (If the "x = 42;" line were removed, the first 
> call to "foo(x)" would use an unspecified value and be UB.)  Instead, it 
> is re-assigned each time flow passes through "int x = 12;", just like at 
> "x = 42".
> 
> extern void foo(int x);
> void bar(void) {
>      goto a;
> b:
>      int x = 12;
>      foo(x);
> a:
>      x = 42;
>      foo(x);
>      goto b;
> }

Are you sure you haven't made a mistake: there are two 'x's in this 
function.

One is the parameter with a value set by the caller. It's visibility 
extents to 'b:'. The other is 'int x = 12'. It is initialised here and 
reassigned at a:.

Its 'lifetime' can only meaningfully start at its declaration.

This is why single, function-wide scopes are so much simpler!

> 
> 
>>
>> This gives the side-effect of allowing two identifiers with the same 
>> name within the scope:
>>
>>   int abc=100;                   // [1]
>>
>>   int main() {
>>       printf("%d\n", abc);       // abc [1]
>>       char* abc="200";           // [2]
>>       printf("%s\n", abc);       // abc [2]
>>   }
>>
> 
> That is not a side-effect - that is just how languages with scoped 
> identifiers work.

No this is a peculiarity of C at least. {...} is a block scope, but this 
allows two separate entities called 'A' to exist in the same block scope:

   int A; {...; int A;...}

Here both the 1st and 2nd A are visible within the same {...} block, but 
not at the same time. Effectively you have:

   int A; {...; {int A;...}}

An implicit nested block.


>> I've now tested C++, and with 'namespaces' and 'using', ambiguities 
>> are reported by g++.
>>
>> (My scheme is more about modules, which also create a namespace; I've 
>> not attempted C++ modules.)
>>
>>
> 
> I recommend you do not think about C++ modules - they add a layer of 
> complexity

Why is that not a surprise!

This was my C++ namespaces test:

   namespace fred{enum {a = 100};};
   namespace bill{enum {a = 999};};
   using namespace fred;
   using namespace bill;

   int main() {
       fred::a;
       bill::a;
   //  a;                 // ambiguous
   }

I tried to recreate this in mine and could do this:

   record fred = const a = 100 end
   record bill = const a = 999 end

   proc main=
       eval fred.a
       eval bill.a
   #   eval a             # undefined
   end

(Records can be used as makeshift namespaces.) So far it works like C++.

But that lone 'a', which is ambiguous in C++ using 'using', is just 
undefined in mine: I don't have a mechanism like 'using' to allow the 
qualifier to dropped.

That only exists for modules, where 'using' is automatic. It's designed 
for ultra simplicity.

[toc] | [prev] | [next] | [standalone]

#402612

On Thu, 1 Oct 2026 10:42:54 +0100
bart <bc@freeuk.com> wrote:
> On 01/10/2026 08:44, David Brown wrote:
> > It is possible to jump over a declaration, or "re-run" it, using
> > goto. This is why lifetime - a run-time property - starts at the
> > beginning of the block, while scope - a compile-time property -
> > starts in the declaration.  In this example, there is only one "x",
> > but it is never actually initialised.  (If the "x = 42;" line were
> > removed, the first call to "foo(x)" would use an unspecified value
> > and be UB.)  Instead, it is re-assigned each time flow passes
> > through "int x = 12;", just like at "x = 42".
> > 
> > extern void foo(int x);
> > void bar(void) {
> >      goto a;
> > b:
> >      int x = 12;
> >      foo(x);
> > a:
> >      x = 42;
> >      foo(x);
> >      goto b;
> > }  
> 
> Are you sure you haven't made a mistake: there are two 'x's in this 
> function.
> 
> One is the parameter with a value set by the caller. It's visibility 
> extents to 'b:'. The other is 'int x = 12'. It is initialised here
> and reassigned at a:.
> 
> Its 'lifetime' can only meaningfully start at its declaration.
> 
> This is why single, function-wide scopes are so much simpler!
>

The code of David looks o.k. x is parameter of foo(), not of
bar().

[toc] | [prev] | [next] | [standalone]

#402614

On 01/10/2026 11:50, Michael S wrote:
> On Thu, 1 Oct 2026 10:42:54 +0100
> bart <bc@freeuk.com> wrote:
>> On 01/10/2026 08:44, David Brown wrote:
>>> It is possible to jump over a declaration, or "re-run" it, using
>>> goto. This is why lifetime - a run-time property - starts at the
>>> beginning of the block, while scope - a compile-time property -
>>> starts in the declaration.  In this example, there is only one "x",
>>> but it is never actually initialised.  (If the "x = 42;" line were
>>> removed, the first call to "foo(x)" would use an unspecified value
>>> and be UB.)  Instead, it is re-assigned each time flow passes
>>> through "int x = 12;", just like at "x = 42".
>>>
>>> extern void foo(int x);
>>> void bar(void) {
>>>       goto a;
>>> b:
>>>       int x = 12;
>>>       foo(x);
>>> a:
>>>       x = 42;
>>>       foo(x);
>>>       goto b;
>>> }
>>
>> Are you sure you haven't made a mistake: there are two 'x's in this
>> function.
>>
>> One is the parameter with a value set by the caller. It's visibility
>> extents to 'b:'. The other is 'int x = 12'. It is initialised here
>> and reassigned at a:.
>>
>> Its 'lifetime' can only meaningfully start at its declaration.
>>
>> This is why single, function-wide scopes are so much simpler!
>>
> 
> The code of David looks o.k. x is parameter of foo(), not of
> bar().
Ah, OK! Then I misread it twice because earlier I pasted it into a 
program to try it. It reported an undefined 'foo' then I realised it was 
a separate declaration. (I suffer from C-blindness.)

I think I understand now why the lifetime of 'x' has to extend to before 
its declaration, but I don't think that example explains it well.

I think this is better:

   void bar(void) {
       goto c;

   a:  goto d;

   b:  int x = 12;
       printf("%d\n", x);

   c:  x = 42;
       goto a;

   d:  printf("%d\n", x);
   }

Here, 'x's visibility extends from b: to the }.

But after assigning 42 to it, it jumps outside of that span, then back 
inside. 'x' is expected to keep its value so its lifetime must extend to 
that last matching {.

For this example, the declaration isn't encountered at all.

This all means that {...; int x;} can't be equivalent to {...; {int 
x;}}, which makes these partial scopes even messier:

   int x;

   void bar(void) {
       goto c;

   a:  x = 99999;
       goto d;

   b:  int x = 12;
       printf("%d\n", x);

   c:  x = 42;
       goto a;

   d:  printf("%d\n", x);
   }

Here it jumps to a:, sets 'x' (the outer one!) then back into the 
lexical scope of the local 'x' which is still 42.

On the face of it, this looks confusing. Suppose that 'int x' (with init 
or not) was moved back a few lines, then that x = 99999 assigns the 
wrong variable. Poor show.

[toc] | [prev] | [next] | [standalone]

#402634

On 01/10/2026 13:29, bart wrote:
> On 01/10/2026 11:50, Michael S wrote:
>> On Thu, 1 Oct 2026 10:42:54 +0100
>> bart <bc@freeuk.com> wrote:
>>> On 01/10/2026 08:44, David Brown wrote:
>>>> It is possible to jump over a declaration, or "re-run" it, using
>>>> goto. This is why lifetime - a run-time property - starts at the
>>>> beginning of the block, while scope - a compile-time property -
>>>> starts in the declaration.  In this example, there is only one "x",
>>>> but it is never actually initialised.  (If the "x = 42;" line were
>>>> removed, the first call to "foo(x)" would use an unspecified value
>>>> and be UB.)  Instead, it is re-assigned each time flow passes
>>>> through "int x = 12;", just like at "x = 42".
>>>>
>>>> extern void foo(int x);
>>>> void bar(void) {
>>>>       goto a;
>>>> b:
>>>>       int x = 12;
>>>>       foo(x);
>>>> a:
>>>>       x = 42;
>>>>       foo(x);
>>>>       goto b;
>>>> }
>>>
>>> Are you sure you haven't made a mistake: there are two 'x's in this
>>> function.
>>>
>>> One is the parameter with a value set by the caller. It's visibility
>>> extents to 'b:'. The other is 'int x = 12'. It is initialised here
>>> and reassigned at a:.
>>>
>>> Its 'lifetime' can only meaningfully start at its declaration.
>>>
>>> This is why single, function-wide scopes are so much simpler!
>>>
>>
>> The code of David looks o.k. x is parameter of foo(), not of
>> bar().
> Ah, OK! Then I misread it twice because earlier I pasted it into a 
> program to try it. It reported an undefined 'foo' then I realised it was 
> a separate declaration. (I suffer from C-blindness.)
> 
> I think I understand now why the lifetime of 'x' has to extend to before 
> its declaration, but I don't think that example explains it well.
> 
> I think this is better:
> 
>    void bar(void) {
>        goto c;
> 
>    a:  goto d;
> 
>    b:  int x = 12;
>        printf("%d\n", x);
> 
>    c:  x = 42;
>        goto a;
> 
>    d:  printf("%d\n", x);
>    }
> 
> Here, 'x's visibility extends from b: to the }.
> 
> But after assigning 42 to it, it jumps outside of that span, then back 
> inside. 'x' is expected to keep its value so its lifetime must extend to 
> that last matching {.

You mean it extends until the last matching } ?  More accurately, it 
lasts until the block is exited - if there is a return statement or a 
goto that leaves the block, that also ends the lifetime of "x".

Otherwise, I agree with your explanation of your example.  (Some of the 
details don't actually have a relevance unless someone is writing 
spaghetti code that jumps back and forth across declarations, but C does 
allow that.)

> 
> For this example, the declaration isn't encountered at all.
> 
> This all means that {...; int x;} can't be equivalent to {...; {int 
> x;}}, which makes these partial scopes even messier:
> 
>    int x;
> 
>    void bar(void) {
>        goto c;
> 
>    a:  x = 99999;
>        goto d;
> 
>    b:  int x = 12;
>        printf("%d\n", x);
> 
>    c:  x = 42;
>        goto a;
> 
>    d:  printf("%d\n", x);
>    }
> 
> Here it jumps to a:, sets 'x' (the outer one!) then back into the 
> lexical scope of the local 'x' which is still 42.
> 
> On the face of it, this looks confusing. Suppose that 'int x' (with init 
> or not) was moved back a few lines, then that x = 99999 assigns the 
> wrong variable. Poor show.
> 

It's all easy if you remember that scope and lifetime are different 
concepts.

"scope" is a compile-time concept.  The scope of a local variable starts 
with its declaration, and continues to the end of the containing block 
(the closing "}" ) - totally independently of how execution flows.  It 
applies only to the code in the block, not to any other functions that 
might be called.  During this period (what the C++ standards call 
"potential scope", which I think is useful), the identifier can go out 
of scope if it is shadowed by another declaration of the same 
identifier.  (It does not make sense to say it goes out of scope during 
function calls, because function calls are a run-time concept, not 
compile-time.)

"lifetime" is a run-time concept.  Lifetime of a local variable starts 
when the enclosing block is entered by the execution, and ends when the 
enclosing block is exited (however that might happen).

You can view "int x = 123;" as three things - one is the scope-related 
declaration of the identifier "x", one is the lifetime-related 
definition of the "int" object, and the third is the initial assignment 
"x = 123;".


You can view the code a bit like this :


     int storage_for_x_1;
#define x storage_for_x_1

     void bar(void) {
         int storage_for_x_2;
         goto c;

     a:  x1 = 99999;
         goto d;

     b:
         // int x = 12
#undef x
#define x storage_for_x_2
         x = 12;
         printf("%d\n", x);

     c:  x = 42;
         goto a;

     d:  printf("%d\n", x);
#undef x
#define x storage_for_x_1
     }

[toc] | [prev] | [next] | [standalone]

#402637

David Brown <david.brown@hesbynett.no> writes:
[...]
> "lifetime" is a run-time concept.  Lifetime of a local variable starts
> when the enclosing block is entered by the execution, and ends when
> the enclosing block is exited (however that might happen).
[...]

Right -- except (and I think you've mentioned this) that the lifetime of
a VLA begins when its declaration is reached, not on entry to the
containing block.  That's because it can't be allocated until the
expression that determines its length is evaluated.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#402638

On 02/10/2026 13:03, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> "lifetime" is a run-time concept.  Lifetime of a local variable starts
>> when the enclosing block is entered by the execution, and ends when
>> the enclosing block is exited (however that might happen).
> [...]
> 
> Right -- except (and I think you've mentioned this) that the lifetime of
> a VLA begins when its declaration is reached, not on entry to the
> containing block.  That's because it can't be allocated until the
> expression that determines its length is evaluated.
> 

Exactly.  And then, I believe, goto'ing around across its declaration 
and scope or lifetime is not allowed, though I can't remember the exact 
details.  (It is also disallowed in C++, because it would be very hard 
to get good semantics for constructors and destructors if it were allowed.)

[toc] | [prev] | [next] | [standalone]

#402640

David Brown <david.brown@hesbynett.no> writes:
> On 02/10/2026 13:03, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> "lifetime" is a run-time concept.  Lifetime of a local variable starts
>>> when the enclosing block is entered by the execution, and ends when
>>> the enclosing block is exited (however that might happen).
>> [...]
>> Right -- except (and I think you've mentioned this) that the
>> lifetime of
>> a VLA begins when its declaration is reached, not on entry to the
>> containing block.  That's because it can't be allocated until the
>> expression that determines its length is evaluated.
>
> Exactly.  And then, I believe, goto'ing around across its declaration
> and scope or lifetime is not allowed, though I can't remember the
> exact details.  (It is also disallowed in C++, because it would be
> very hard to get good semantics for constructors and destructors if it
> were allowed.)

In C, "A goto statement shall not jump from outside the scope of an
identifier having a variably modified type to inside the scope of that
identifier."  There's a similar rule for switch statements.

(In C++, jumping across any declaration that initializes the object is
forbidden.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web