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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#402641

In article <119osob$2beij$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
...
>(In C++, jumping across any declaration that initializes the object is
>forbidden.)

What about in Python?

I ask because that is a computer programming language that is also
frequently discussed (and has code frequently posted) in this newsgroup.

-- 
Trump has normalized hate.

The media has normalized Trump.

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

#402651

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>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.)

Sort of.   This is perfectly legal, however:

#include <stdio.h>
int x(int y)
{

   if (y == 0) goto done;
   {
       int b = 0;
       printf("%d\n", b);
   }
done:
   return y;
}

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

#402666

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>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.)
>
> Sort of.   This is perfectly legal, however:
>
> #include <stdio.h>
> int x(int y)
> {
>
>    if (y == 0) goto done;
>    {
>        int b = 0;
>        printf("%d\n", b);
>    }
> done:
>    return y;
> }

Right.  (I didn't want to go into too much detail about the C++ rules,
because this isn't comp.lang.c++.)

I think the C++ rule forbids jumping into the scope of an initialized
object.  Jumping around the scope isn't a problem in either language.
Jumping into the scope of an object with no explicit or implicit
initialization appears to be permitted.  All this is based on
experiments with g++; I haven't found the relevant rule in the C++
standard.

Of course jumping into the scope of an initialized object is bad
practice even in C.

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

#402615

On 01/10/2026 11:42, bart wrote:
> 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.)
> 

OK.  These kind of details make it easier to know what you are thinking 
about.

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

No, that is not necessarily true - though of course a compiler /can/ do 
that.  Optimising compilers do all kinds of different things.  In a case 
like this, there's not much scope for complex re-arrangements (though 
the compiler could eliminate x altogether and generate two puts() 
calls).  In more advanced loops, the compiler could do some unrolling 
and have different "virtual x's" hanging around in different places. 
Even without unrolling, the variable "x" could be in a register for a 
while, a stack slot later, then a different register, and perhaps merged 
with something else.  There are no limitations beyond observable behaviour.

On the other hand, the lifetime rules do mean that it's fine for a 
simple compiler to make a stack frame at the start of the block with 
slots for all the variables it will need in the block.

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

I appreciate why you think "reinitialising" is an appropriate term - and 
I understand what you mean by it.  But even if you want to use it, it is 
helpful if you know that it is not accurate - each "x" here is 
initialised exactly once.  When you are fully aware of what is actually 
happening in the C code, we can then use the shortcut of referring to 
"x" as though it were just one object rather than one object per 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.
> 
> 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?

That's how the lifetime of local objects works in C (except for VLAs). 
The lifetime starts at the start of the block.  The compiler does not 
necessarily need to do anything at this point - but if it is using a 
stack frame, it could add a new slot here.

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

No - when a new identifier enters scope, any existing identifiers with 
the same name are hidden.  Lifetimes can overlap, but not scopes.

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

Ok.  That's a different thing - it's a way to refer to the outer scope y 
using qualification, and is not specific to initialisation.

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

No, there is just one x in "bar".  The other "x" you see is a parameter 
to the extern function "foo", which is just there as a way of saying "do 
something with x" that is easy to read on godbolt.org.  I should 
probably have picked a different identifier for the parameter in "foo", 
as it was easy to misread.  I won't comment on your lines below until 
you have re-read the code.

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

To be clear here - the outer "abc" is in scope in the first "printf", 
and it is not in scope for the second "printf" since it has been hidden 
by the inner "abc".  You have two different objects with the same 
identifier in the same block, but only one of them is in scope at a time.

It is not a peculiarity of C.  Rather, it is the norm for languages with 
scoped identifiers unless identifier scope covers a full block rather 
than just from its declaration onwards.  And your language is the only 
one I have heard of with that feature.  (That does not mean it is the 
only such language - I just don't know of any others.)

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

You can view it that way, yes.  Scopes start at their declarations, and 
continue to the end of their block.  This is normal in structured 
programming languages.

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

C++ is a large and complex language, and you have long protested that 
even its simplest features are too difficult for you to understand.  So 
no, it is no surprise that I don't recommend you try to understand C++ 
modules.

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

Sounds fine to me - that's a good way for a language to work.

The alternative - where the second "using" statement caused "bill::a" to 
be a better candidate in name lookup than "fred::a" for unqualified "a", 
could be more convenient in some circumstances.  But the risk of 
unintentional mistakes would be a lot higher, and so an error from the 
ambiguity is safer.

(Note that stylistically, such "using namespace foo;" statements at file 
or namespace scope are frowned upon unless you have very clear control 
of exactly what is in the namespace.  Using them within a function 
definition is often better - though of course you'd get the same 
ambiguity here if you did that.)

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

"Ultra simplicity" is fine until you need something more advanced, or 
until things go wrong.

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

#402621

David Brown <david.brown@hesbynett.no> writes:
>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:

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

Conceptually, sure.  In reality, it's highly likely that
the actual storage location for 'x' will be the same location
on the stack for each iteration (although the compiler could
simply keep it in a register for such a small loop instead
of allocating space on the stack).

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

#402627

On 10/1/2026 12:44 AM, David Brown wrote:
[...]

scope it?

{
     {
         int x = 1;
     }

     {
         int x = 2;
     }

     {
         int x = 3;
     }

     {
         int x = 4;
     }
}

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

#402632

On 02/10/2026 00:37, Chris M. Thomasson wrote:
> On 10/1/2026 12:44 AM, David Brown wrote:
> [...]
> 

Snipping is good - but if you think snipping /everything/ is a good 
idea, then think carefully about whether the post is actually relevant 
to the thread.  Good reasons for snipping everything include admonishing 
someone for spam, insults, abuse, etc., that you want to take a stand 
against, but do not want to repeat.

> scope it?

If you have a question, or a comment, or an answer to a question, try 
writing it, rather than just a random fragment of thought.  The scoping 
in the code you posted is so simple and obvious that it is surely not 
what you are asking about.

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

#402635

On 10/1/2026 11:57 PM, David Brown wrote:
> On 02/10/2026 00:37, Chris M. Thomasson wrote:
>> On 10/1/2026 12:44 AM, David Brown wrote:
>> [...]
>>
> 
> Snipping is good - but if you think snipping /everything/ is a good 
> idea, then think carefully about whether the post is actually relevant 
> to the thread.  Good reasons for snipping everything include admonishing 
> someone for spam, insults, abuse, etc., that you want to take a stand 
> against, but do not want to repeat.
> 
>> scope it?
> 
> If you have a question, or a comment, or an answer to a question, try 
> writing it, rather than just a random fragment of thought.  The scoping 
> in the code you posted is so simple and obvious that it is surely not 
> what you are asking about.
> 

{
     {
         int x = 1;
     }

     {
         int x = 2;
     }

     {
         int x = 3;
     }
}


vs say

{
     int x = 0;

     x = 1;
     //...

     x = 2
     //...

     x = 3
    // ....
}

?

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

#402575

On 30/09/2026 13:14, Janis Papanagnou wrote:
> 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.

Python doesn't have block scopes either. I believe they are (or were) 
missing from JavaScript too.

Those are both one-man languages but perhaps you've heard of them.

> I wonder that you still think the Sun is
> rotating around the Earth.
Why don't you ask the creators of the two languages I mentioned?

Some people are just sheep and follow the crowd without any ideas or 
opinions of their own. But some of them like to attack those who do.

<Braces for another onslaught of abuse.>

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

#402551

On Tue, 29 Sep 2026 09:03:37 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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"? 

There exist coding standard/style guides that prohibit it. Not just
MISRA, which I hold at low regard, but some well-thought guids too.
There are popular compilers that warn about it. 

>- I've always seen it as a useful feature.
> And never heard anyone complaining about it.

It just means that you didn't get out much.

> In decades I also
> don't recall that subtile (or obvious) errors had been reported
> because of that.

I had seen one yesterday. This particular time it was in context of C++
member variables and of inheritance. But I certainly had seen similar
bugs in C. Even made them myself.

> (Are you, yet again, just making things up for
> the argument or have you any different observations from your
> personal coding practice?)
> 
> Janis
> 

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

#402556

On 30/09/2026 13:09, Michael S wrote:
> On Tue, 29 Sep 2026 09:03:37 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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"?
> 
> There exist coding standard/style guides that prohibit it. Not just
> MISRA, which I hold at low regard, but some well-thought guids too.
> There are popular compilers that warn about it.
> 
>> - I've always seen it as a useful feature.
>> And never heard anyone complaining about it.
> 
> It just means that you didn't get out much.
> 

Poorly considered or unintentional shadowing can certainly lead to bugs 
or programmer confusion.

Equally, however, it is an essential feature to long-term programming. 
Otherwise you have to make sure you pick names for all your local 
identifiers that could never be included in any of the headers 
(application, third-party library, standard library, whatever) used by 
your code.  That means avoiding any names that might be used in /future/ 
versions of these headers, or in headers from other platforms or toolchains.

Clearly that is infeasible - it would place unreasonable restraints on 
how you could write your own code, and unreasonable restraints on how 
libraries and other code could write their headers.

Just as clearly, you should not knowingly shadow an existing name unless 
that's the choice that is clearest in the code.

Long ago, I used "-Wshadow" in gcc but stopped due to too many false 
positives.  (Many <math.h> libraries include Bessel functions like "y0" 
and "y1" when not used in strict standards modes, though these are 
popular identifiers for local variables or parameters.)  Current gcc has 
more nuanced versions like "-Wshadow=local" and 
"-Wshadow=compatible-local" which are often a better choice.

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

#402561

On 2026-09-30 13:09, Michael S wrote:
> On Tue, 29 Sep 2026 09:03:37 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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"?
> 
> There exist coding standard/style guides that prohibit it. Not just
> MISRA, which I hold at low regard, but some well-thought guids too.

Interesting. (The ones I've seen certainly didn't have such an IMO
absolutely stupid rule.) - Were there any rationales for the rules?
(I mean if you take away a sensible concept from a language there
should at least be some severe problems we want to prevent. Which?)

> There are popular compilers that warn about it.

That is fair, IMO, if you can control and deactivate that behavior.

But I've also seen compilers that were annoyingly persisting in
those "warnings". In one case I was able to convince the maintainer
to remove that annoying warning, though.

> 
>> - I've always seen it as a useful feature.
>> And never heard anyone complaining about it.
> 
> It just means that you didn't get out much.

LOL - maybe. :-)

But given that I have a comparably wide-ranging experience in a lot
of different business-areas, IT-areas, IT-companies, and IT-projects
over many decades, I'm indeed wondering about that.

Seriously, I've seen folks complain about everything. We should have
a clear view on who complains and how substantiated the complaints are.

> 
>> In decades I also
>> don't recall that subtile (or obvious) errors had been reported
>> because of that.
> 
> I had seen one yesterday. This particular time it was in context of C++
> member variables and of inheritance. But I certainly had seen similar
> bugs in C. Even made them myself.

Well, inheritance is not as shadowing; you can explicitly qualify the
access to inherited attributes!

Or how did these problems look like? - And how do you solve it? - By
renaming, say, hierarchical index variables 'i' to 'i1', 'i2', etc.?

Janis

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

#402565

On Wed, 30 Sep 2026 14:31:40 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> 
> Well, inheritance is not as shadowing; you can explicitly qualify the
> access to inherited attributes!

It's not an *absolute* shadowing, yes. Which makes matters worse,
because compiler is less likely to warn you.

> 
> Or how did these problems look like? - And how do you solve it? - By
> renaming, say, hierarchical index variables 'i' to 'i1', 'i2', etc.?
> 
> Janis
> 

There was a member variable in the base class and member variable with
the same name in derived class.
The programmer accessed (wrote to) a member of derived when his actual
intention was to access the one of base. Then he wondered why the value
in the base instance is wrong.
Since it was just a mistake, a fix was easy - removing the offending
member from declaration of derived class. But finding the bug was not
easy.

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

#402582

On 2026-09-30 15:12, Michael S wrote:
> On Wed, 30 Sep 2026 14:31:40 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>> Or how did these problems look like? - And how do you solve it? - By
>> renaming, say, hierarchical index variables 'i' to 'i1', 'i2', etc.?
> 
> There was a member variable in the base class and member variable with
> the same name in derived class.

Yes, I figured as much so far, I assumed so.

I fear we could dispute well about (mis-)designs with attributes of the
same name in hierarchical class definitions, what one wants to model by
that. (I refer, just for one example, to Barton/Nackman: Scientific and
Engineering C++. And add a quick note that polymorphism by inheritance
in C++ is supported by [virtual] _functions_. And usually there's rules
to have the attributes hidden and accessed by functions. Some problems
can be tackled by standards and organizational and/or QA means.)

> The programmer accessed (wrote to) a member of derived when his actual
> intention was to access the one of base. Then he wondered why the value
> in the base instance is wrong.

A beginner, I suppose? (Usually if one uses some class he'd be looking
into the derived classes, and from there upward, if he's unfamiliar
with it. But as mentioned, the problem here might be the "OO"-design.)

> Since it was just a mistake, a fix was easy - removing the offending
> member from declaration of derived class. But finding the bug was not
> easy.

Install reviews into your company's design and development processes.
(Just a suggestion.)

Janis

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

#402583

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 2026-09-30 15:12, Michael S wrote:
>> On Wed, 30 Sep 2026 14:31:40 +0200
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>> Or how did these problems look like? - And how do you solve it? - By
>>> renaming, say, hierarchical index variables 'i' to 'i1', 'i2', etc.?
>> 
>> There was a member variable in the base class and member variable with
>> the same name in derived class.
>
>Yes, I figured as much so far, I assumed so.
>
>I fear we could dispute well about (mis-)designs with attributes of the
>same name in hierarchical class definitions, what one wants to model by
>that. 

I've been in the habit (inspired by early Unix C) to always use
a class-specific prefix for all class member variables (even those
behind getters/setters).   Granted the early C compilers required
that since MoS were top-level symbol table entries, but it's always
been a useful convention to prevent inadvertent clashes with the
subclass members.   An example would be struct stat.
 

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

#402617

On 2026-09-30 07:09, Michael S wrote:
> On Tue, 29 Sep 2026 09:03:37 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...>> Since when is shadowing (or "overriding" in its various forms)
>> "perceived as bad"? 
> 
> There exist coding standard/style guides that prohibit it. Not just
> MISRA, which I hold at low regard, but some well-thought guids too.
> There are popular compilers that warn about it. 
> 
>> - I've always seen it as a useful feature.
>> And never heard anyone complaining about it.
> 
> It just means that you didn't get out much.
The ability to use a given identifier in one place, without having to
worry about it breaking code using that identifier in a different
location, is very useful. But in general, if you know that the same
identifier is being used in two different interacting pieces of code,
you should consider changing one of the identifiers to avoid potential
confusion. I say "consider", because often the identifier in question
is, by far, the most reasonable one to use in that context, so as long
as shadowing prevents them from conflicting, you shouldn't bother
changing one. This is particularly true for short identifiers, and
identifiers that have the same meaning in both contexts.

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

#402494

On Mon, 28 Sep 2026 14:38:09 +0100, bart wrote:

> On 28/09/2026 12:56, David Brown wrote:
>>
>> "hypot" - short for "hypotenuse" but easier to spell - is not
>> obscure. It is a common name and part of the IEEE 754 standard.  It
>> makes a lot of sense for a language that is often used with code
>> that requires conformance to that standard, to have support for the
>> standard's required and recommended functions in its standard
>> library.  As Lawrence showed, proper implementations of such
>> functions is not just a matter of copying the pure mathematical
>> formula.
>
> He showed a way to avoid overflowing (with inputs above 10**19) if
> you can't be bothered to use a more appropriate type.

I knew somewhat would try to make this claim, sooner or later. So
here’s a long-double version -- I don’t think GCC supports any
floating-point formats with greater range or precision than this!

    /*
        Comparison of the naïve calculation of a triangle
        hypotenuse with the standard-library hypot(3) function.
    */

        #include <math.h>
        #include <values.h>
        #include <stdio.h>

        static long double len2(long double x,long double y) {  return sqrtl(x*x+y*y);}

        static void compare_for
          (
            long double x
          )
          {
            fprintf
              (
                stdout,
                "for %.7Le: len2 = %.7Le, hypot = %.7Le\n",
                x, len2(x, x), hypotl(x, x)
              );
          } /*compare_for*/

        int main(void)
          {
            compare_for(LDBL_MAX / 2.0);
            compare_for(2.0 / LDBL_MAX);
            return
                0;
          } /*main*/

Output:

    ldo@theon:c_try> ./naive_hypot_long_double
    for 5.9486575e+4931: len2 = inf, hypot = 8.4126721e+4931
    for 1.6810516e-4932: len2 = 0.0000000e+00, hypot = 2.3773659e-4932

So the library routine is still capable of producing meaningful results,
while the naïve implementation still breaks down.

Any more nitpicks?

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

#402508

On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
> On Mon, 28 Sep 2026 14:38:09 +0100, bart wrote:
> 
>> On 28/09/2026 12:56, David Brown wrote:
>>>
>>> "hypot" - short for "hypotenuse" but easier to spell - is not
>>> obscure. It is a common name and part of the IEEE 754 standard.  It
>>> makes a lot of sense for a language that is often used with code
>>> that requires conformance to that standard, to have support for the
>>> standard's required and recommended functions in its standard
>>> library.  As Lawrence showed, proper implementations of such
>>> functions is not just a matter of copying the pure mathematical
>>> formula.
>>
>> He showed a way to avoid overflowing (with inputs above 10**19) if
>> you can't be bothered to use a more appropriate type.
> 
> I knew somewhat would try to make this claim, sooner or later. So
> here’s a long-double version -- I don’t think GCC supports any
> floating-point formats with greater range or precision than this!
> 
>      /*
>          Comparison of the naïve calculation of a triangle
>          hypotenuse with the standard-library hypot(3) function.
>      */
> 
>          #include <math.h>
>          #include <values.h>
>          #include <stdio.h>
> 
>          static long double len2(long double x,long double y) {  return sqrtl(x*x+y*y);}
> 
>          static void compare_for
>            (
>              long double x
>            )
>            {
>              fprintf
>                (
>                  stdout,
>                  "for %.7Le: len2 = %.7Le, hypot = %.7Le\n",
>                  x, len2(x, x), hypotl(x, x)
>                );
>            } /*compare_for*/
> 
>          int main(void)
>            {
>              compare_for(LDBL_MAX / 2.0);
>              compare_for(2.0 / LDBL_MAX);
>              return
>                  0;
>            } /*main*/
> 
> Output:
> 
>      ldo@theon:c_try> ./naive_hypot_long_double
>      for 5.9486575e+4931: len2 = inf, hypot = 8.4126721e+4931
>      for 1.6810516e-4932: len2 = 0.0000000e+00, hypot = 2.3773659e-4932
> 
> So the library routine is still capable of producing meaningful results,
> while the naïve implementation still breaks down.
> 
> Any more nitpicks?

Yes: you're being incredibly pedantic and picky for no reason other than 
to be argumentative and superior.

These big numbers are ridiculous. If you want to play this game, then 
I've just got my bignum library to work out the hypotenuse given these 
two sides:

   A = 3e1'000'000'000'000'000'000
   B = 4e1'000'000'000'000'000'000

(The is, 3 and 4 each followed by a million million million zeros.)

So tell me again what is the upper limit when using hypotl()?

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

#402510

bart <bc@freeuk.com> writes:
>On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>> On Mon, 28 Sep 2026 14:38:09 +0100, bart wrote:
>> 
>>> On 28/09/2026 12:56, David Brown wrote:
>>>>
>>>> "hypot" - short for "hypotenuse" but easier to spell - is not
>>>> obscure. It is a common name and part of the IEEE 754 standard.  It
>>>> makes a lot of sense for a language that is often used with code
>>>> that requires conformance to that standard, to have support for the
>>>> standard's required and recommended functions in its standard
>>>> library.  As Lawrence showed, proper implementations of such
>>>> functions is not just a matter of copying the pure mathematical
>>>> formula.
>>>
>>> He showed a way to avoid overflowing (with inputs above 10**19) if
>>> you can't be bothered to use a more appropriate type.
>> 
>> I knew somewhat would try to make this claim, sooner or later. So
>> here’s a long-double version -- I don’t think GCC supports any
>> floating-point formats with greater range or precision than this!
>> 
>>      /*
>>          Comparison of the naïve calculation of a triangle
>>          hypotenuse with the standard-library hypot(3) function.
>>      */
>> 
>>          #include <math.h>
>>          #include <values.h>
>>          #include <stdio.h>
>> 
>>          static long double len2(long double x,long double y) {  return sqrtl(x*x+y*y);}
>> 
>>          static void compare_for
>>            (
>>              long double x
>>            )
>>            {
>>              fprintf
>>                (
>>                  stdout,
>>                  "for %.7Le: len2 = %.7Le, hypot = %.7Le\n",
>>                  x, len2(x, x), hypotl(x, x)
>>                );
>>            } /*compare_for*/
>> 
>>          int main(void)
>>            {
>>              compare_for(LDBL_MAX / 2.0);
>>              compare_for(2.0 / LDBL_MAX);
>>              return
>>                  0;
>>            } /*main*/
>> 
>> Output:
>> 
>>      ldo@theon:c_try> ./naive_hypot_long_double
>>      for 5.9486575e+4931: len2 = inf, hypot = 8.4126721e+4931
>>      for 1.6810516e-4932: len2 = 0.0000000e+00, hypot = 2.3773659e-4932
>> 
>> So the library routine is still capable of producing meaningful results,
>> while the naïve implementation still breaks down.
>> 
>> Any more nitpicks?
>
>Yes: you're being incredibly pedantic and picky for no reason other than 
>to be argumentative and superior.
>
>These big numbers are ridiculous. If you want to play this game, then 
>I've just got my bignum library to work out the hypotenuse given these 
>two sides:
>
>   A = 3e1'000'000'000'000'000'000
>   B = 4e1'000'000'000'000'000'000
>
>(The is, 3 and 4 each followed by a million million million zeros.)

The nice thing about computing the hypotenuse, is that you
can simply scale the values of A&B down before computing C
to get the correct answer.

I believe many implementations already do that internally
to avoid over/underflow cases.

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

#402511

On 29/09/2026 15:43, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>>> On Mon, 28 Sep 2026 14:38:09 +0100, bart wrote:
>>>
>>>> On 28/09/2026 12:56, David Brown wrote:
>>>>>
>>>>> "hypot" - short for "hypotenuse" but easier to spell - is not
>>>>> obscure. It is a common name and part of the IEEE 754 standard.  It
>>>>> makes a lot of sense for a language that is often used with code
>>>>> that requires conformance to that standard, to have support for the
>>>>> standard's required and recommended functions in its standard
>>>>> library.  As Lawrence showed, proper implementations of such
>>>>> functions is not just a matter of copying the pure mathematical
>>>>> formula.
>>>>
>>>> He showed a way to avoid overflowing (with inputs above 10**19) if
>>>> you can't be bothered to use a more appropriate type.
>>>
>>> I knew somewhat would try to make this claim, sooner or later. So
>>> here’s a long-double version -- I don’t think GCC supports any
>>> floating-point formats with greater range or precision than this!
>>>
>>>       /*
>>>           Comparison of the naïve calculation of a triangle
>>>           hypotenuse with the standard-library hypot(3) function.
>>>       */
>>>
>>>           #include <math.h>
>>>           #include <values.h>
>>>           #include <stdio.h>
>>>
>>>           static long double len2(long double x,long double y) {  return sqrtl(x*x+y*y);}
>>>
>>>           static void compare_for
>>>             (
>>>               long double x
>>>             )
>>>             {
>>>               fprintf
>>>                 (
>>>                   stdout,
>>>                   "for %.7Le: len2 = %.7Le, hypot = %.7Le\n",
>>>                   x, len2(x, x), hypotl(x, x)
>>>                 );
>>>             } /*compare_for*/
>>>
>>>           int main(void)
>>>             {
>>>               compare_for(LDBL_MAX / 2.0);
>>>               compare_for(2.0 / LDBL_MAX);
>>>               return
>>>                   0;
>>>             } /*main*/
>>>
>>> Output:
>>>
>>>       ldo@theon:c_try> ./naive_hypot_long_double
>>>       for 5.9486575e+4931: len2 = inf, hypot = 8.4126721e+4931
>>>       for 1.6810516e-4932: len2 = 0.0000000e+00, hypot = 2.3773659e-4932
>>>
>>> So the library routine is still capable of producing meaningful results,
>>> while the naïve implementation still breaks down.
>>>
>>> Any more nitpicks?
>>
>> Yes: you're being incredibly pedantic and picky for no reason other than
>> to be argumentative and superior.
>>
>> These big numbers are ridiculous. If you want to play this game, then
>> I've just got my bignum library to work out the hypotenuse given these
>> two sides:
>>
>>    A = 3e1'000'000'000'000'000'000
>>    B = 4e1'000'000'000'000'000'000
>>
>> (The is, 3 and 4 each followed by a million million million zeros.)
> 
> The nice thing about computing the hypotenuse, is that you
> can simply scale the values of A&B down before computing C
> to get the correct answer.
> 
> I believe many implementations already do that internally
> to avoid over/underflow cases.

You can probably do that in any number of examples, if you think might 
you might run out of range, even though f64 is generous.

So what's special about the sqrt(x*x + y*y) expression that defines how 
hypot works, compared with a million others across codebases?

I can understand if the types involved are f8 or f16, but usually even 
f32 is not a problem.

Note that my bignum example did it without scaling,

It's also worth noting that if using the x87, it calculates internally 
using higher precision and range than 64 bits (I think 15-bit exponents 
rather than 11).

So it should be able to do a naive hypot() that takes 64-bit floats up 
to almost the full range, without overflow and without any tricks.

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

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

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

csiph-web