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

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

Why is this happening?

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

Contents

  Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 00:12 -0400
    Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 05:46 +0100
      Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 06:01 +0100
        Re: Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 02:31 -0400
      Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-27 10:15 +0100
        Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-27 16:02 +0000
          Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-28 21:58 +0100
            Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-29 14:30 +0200
              Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:56 +0000
                Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 02:00 +0200
              Re: Why is this happening? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-03-30 00:41 +0100
                Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 09:25 +0200
                  Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 11:23 +0300
                    Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 11:16 +0200
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 13:06 +0300
        Re: Why is this happening? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-28 01:46 +0000
          Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 20:41 -0700
            Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-28 05:17 +0100
              Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 10:09 +0100
                Re: Why is this happening? Bart <bc@freeuk.com> - 2026-03-28 11:33 +0000
                  Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 16:35 +0100
                    Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:56 +0000
                    Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:58 +0000
                      Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-28 19:24 -0400
                      Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-29 11:33 +0200
                        Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-29 16:30 +0100
                          Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 10:37 -0700
                            Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:20 +0200
                              Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-31 17:19 +0100
                        Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:19 -0700
                          Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:26 -0700
                          Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 14:14 -0700
                            Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 20:47 -0400
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:57 -0700
                          Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:26 +0200
            Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-28 15:14 +0000
              Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 10:18 -0700
                Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:50 +0000
              Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-28 19:12 -0700
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 22:31 -0700
                  Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:11 -0700
                    Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 14:20 -0700
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-04-07 02:05 +0300
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 17:42 -0700
                      Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-27 20:36 -0700
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-27 20:58 -0700
                Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 14:43 -0700
              Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-29 11:50 +0300
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:54 -0700
                  Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 02:05 +0300
                    Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 16:22 -0700
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 10:57 +0300
                  Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-30 20:37 -0400
                    Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-31 11:48 +0300
                      Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-31 10:51 -0400
                    Re: Why is this happening? candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-03-31 19:00 +0000
          Re: Why is this happening? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-04-03 02:41 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#397388

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
>>>>>
>>>>>>      diffns += 1000000000UL;
>>>>>
>>>>> Can you write
>>>>>
>>>>>       diffns += 1_000_000_000UL;
>>>>>
>>>>> yet?
>>>>
>>>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>>> from C++:
>>>>
>>>>      diffns += 1'000'000'000UL;
>>>
>>> Or diffns += 1000ul * 1000ul * 1000ul;
>>>
>>> or diffns += 1 * NS_PER_SEC;
>>>
>>> with
>>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>>>
>>>> (I would have preferred underscores, but that would have conflicted
>>>> with C++'s user-defined literals.)
>>>
>>> Likewise, I'd prefer the underscore.
>>
>> Ditto.  And there is no reason C could have allowed both,
>> and C++ be damned.
>
> (I think you omitted a "not".)

Yes, as I explained in a followup to myself.

> Using apostrophes is IMHO far better than either allowing two
> arbitrarily distinct syntaxes or a gratuitous incompatibility
> with C++.

One, it is not an incompatibility.  It's an upward compatible
extension.

Two, it's not gratuitous.  The extension is proposed because it
provides a positive value, and I'm not the only one who thinks
so.

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

#397392

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
>>>>>>>      diffns += 1000000000UL;
>>>>>>
>>>>>> Can you write
>>>>>>
>>>>>>       diffns += 1_000_000_000UL;
>>>>>>
>>>>>> yet?
>>>>>
>>>>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>>>> from C++:
>>>>>
>>>>>      diffns += 1'000'000'000UL;
>>>>
>>>> Or diffns += 1000ul * 1000ul * 1000ul;
>>>>
>>>> or diffns += 1 * NS_PER_SEC;
>>>>
>>>> with
>>>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>>>>
>>>>> (I would have preferred underscores, but that would have conflicted
>>>>> with C++'s user-defined literals.)
>>>>
>>>> Likewise, I'd prefer the underscore.
>>>
>>> Ditto.  And there is no reason C could have allowed both,
>>> and C++ be damned.
>>
>> (I think you omitted a "not".)
>
> Yes, as I explained in a followup to myself.
>
>> Using apostrophes is IMHO far better than either allowing two
>> arbitrarily distinct syntaxes or a gratuitous incompatibility
>> with C++.
>
> One, it is not an incompatibility.  It's an upward compatible
> extension.

Your proposal, I think, is for C to permit both apostrophes and
underscores as digit separators.  I suppose that's not strictly an
"incompatibility", but it would mean that any code intended to be
compiled as either C or C++ cannot use underscores.

Your "C++ be damned" attitude is not shared by either language
committee (fortunately, IMHO).

> Two, it's not gratuitous.  The extension is proposed because it
> provides a positive value, and I'm not the only one who thinks
> so.

I disagree.  I've already said that I would have preferred
underscores over apostrophes, but both languages now use apostrophes.
If C allowed both, there would be no firm basis for deciding which
to use.  It would make the language slightly more complicated,
with no real benefit than I can see.  The only thing I can think of
that might be a "positive value" is that *some* programmers would
be able to use a symbol that they think looks better.

It would be similar to allowing programmers to use "begin" and "end"
rather than "{" and "}".  I'm sure some programmers would like that,
but the result would be a mess.

What positive value do you think permitting underscores would add?

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

#397398

On Mon, 06 Apr 2026 14:20:26 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:  
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:  
> >>> scott@slp53.sl.home (Scott Lurndal) writes:  
> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:  
> >>>>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:  
> >>>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
> >>>>>>  
> >>>>>>>      diffns += 1000000000UL;  
> >>>>>>
> >>>>>> Can you write
> >>>>>>
> >>>>>>       diffns += 1_000_000_000UL;
> >>>>>>
> >>>>>> yet?  
> >>>>>
> >>>>> Not in C.  C23 introduces the apostrophe as a digit separator,
> >>>>> copied from C++:
> >>>>>
> >>>>>      diffns += 1'000'000'000UL;  
> >>>>
> >>>> Or diffns += 1000ul * 1000ul * 1000ul;
> >>>>
> >>>> or diffns += 1 * NS_PER_SEC;
> >>>>
> >>>> with
> >>>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
> >>>>  
> >>>>> (I would have preferred underscores, but that would have
> >>>>> conflicted with C++'s user-defined literals.)  
> >>>>
> >>>> Likewise, I'd prefer the underscore.  
> >>>
> >>> Ditto.  And there is no reason C could have allowed both,
> >>> and C++ be damned.  
> >>
> >> (I think you omitted a "not".)  
> >
> > Yes, as I explained in a followup to myself.
> >  
> >> Using apostrophes is IMHO far better than either allowing two
> >> arbitrarily distinct syntaxes or a gratuitous incompatibility
> >> with C++.  
> >
> > One, it is not an incompatibility.  It's an upward compatible
> > extension.  
> 
> Your proposal, I think, is for C to permit both apostrophes and
> underscores as digit separators.  I suppose that's not strictly an
> "incompatibility", but it would mean that any code intended to be
> compiled as either C or C++ cannot use underscores.
> 
> Your "C++ be damned" attitude is not shared by either language
> committee (fortunately, IMHO).
> 

For C11 and C17 it was true.
But C23 has at least two new (or old new) incompatibilities with C++:
- VMT are again mandatory, like in C99
- _BitInt(N)
It sounds to me as a change of the attitude. Or may be a return to
pre-C11 attitude.

> > Two, it's not gratuitous.  The extension is proposed because it
> > provides a positive value, and I'm not the only one who thinks
> > so.  
> 
> I disagree.  I've already said that I would have preferred
> underscores over apostrophes, but both languages now use apostrophes.
> If C allowed both, there would be no firm basis for deciding which
> to use.  It would make the language slightly more complicated,
> with no real benefit than I can see.  The only thing I can think of
> that might be a "positive value" is that *some* programmers would
> be able to use a symbol that they think looks better.
> 
> It would be similar to allowing programmers to use "begin" and "end"
> rather than "{" and "}".  I'm sure some programmers would like that,
> but the result would be a mess.
> 
> What positive value do you think permitting underscores would add?
> 

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

#397402

Michael S <already5chosen@yahoo.com> writes:
> On Mon, 06 Apr 2026 14:20:26 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Your "C++ be damned" attitude is not shared by either language
>> committee (fortunately, IMHO).
>
> For C11 and C17 it was true.
> But C23 has at least two new (or old new) incompatibilities with C++:
> - VMT are again mandatory, like in C99
> - _BitInt(N)
> It sounds to me as a change of the attitude. Or may be a return to
> pre-C11 attitude.

It's always been true that C has some features that C++ doesn't.
In some cases, it's because some features are better implemented
in C++ as container classes, while C needs them to be implemented
in the core language.  Variably modified types are a good example;
for most cases where I'd use one in C, I'd probably use std::vector
in C++.  Complex types are another example.

There is a proposal to add _BitInt to a new edition of C++:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3666r2.html

That hardly indicates a "C++ be damned" attitude.  The two committees
still coordinate fairly closely, and try to keep the two languages as
compatible as reasonably possible.

C23 uses apostrophes as digit separators because C++ does so.
I don't know why Tim thinks requiring support for both apostrophes
and underscores would be an improvement.

[...]

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

#398047

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[..discussing allowing underscores as separators in integer constants..]

>> The extension is proposed because it provides a positive value, and
>> I'm not the only one who thinks so.
>
> I disagree. [...]

You disagree that there is more than one person who thinks allowing
underscores in integer constants provides a positive value?  That is
a remarkably bold assertion.

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

#398048

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [..discussing allowing underscores as separators in integer constants..]
>>> The extension is proposed because it provides a positive value, and
>>> I'm not the only one who thinks so.
>>
>> I disagree. [...]
>
> You disagree that there is more than one person who thinks allowing
> underscores in integer constants provides a positive value?

No.

>                                                              That is
> a remarkably bold assertion.

Yes, it would have been.

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

#397284

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
>>>>
>>>>>      diffns += 1000000000UL;
>>>>
>>>> Can you write
>>>>
>>>>       diffns += 1_000_000_000UL;
>>>>
>>>> yet?
>>>
>>> Not in C.  C23 introduces the apostrophe as a digit separator,
>>> copied from C++:
>>>
>>>      diffns += 1'000'000'000UL;
>>
>> Or diffns += 1000ul * 1000ul * 1000ul;
>>
>> or diffns += 1 * NS_PER_SEC;
>>
>> with
>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>>
>>> (I would have preferred underscores, but that would have
>>> conflicted with C++'s user-defined literals.)
>>
>> Likewise, I'd prefer the underscore.
>
> Ditto.  And there is no reason C could have allowed both,
> and C++ be damned.

Of course I meant there is no reason C couldn't have allowed
both.  Sorry for any confusion.

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

#397265

On Sat, 28 Mar 2026 15:14:42 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >Lawrence Dג€™Oliveiro <ldo@nz.invalid> writes:  
> >> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M_¶llers wrote:
> >>  
> >>>      diffns += 1000000000UL;  
> >>
> >> Can you write
> >>
> >>       diffns += 1_000_000_000UL;
> >>
> >> yet?  
> >
> >Not in C.  C23 introduces the apostrophe as a digit separator, copied
> >from C++:
> >
> >      diffns += 1'000'000'000UL;  
> 
> Or diffns += 1000ul * 1000ul * 1000ul;
> 
> or diffns += 1 * NS_PER_SEC;
> 
> with
> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))

Why not (int)1e9 ?

> 
> >
> >(I would have preferred underscores, but that would have conflicted
> >with C++'s user-defined literals.)  
> 
> Likewise, I'd prefer the underscore.   IIRC, that's what is used
> in Verilog.
> 

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

#397280

Michael S <already5chosen@yahoo.com> writes:
> On Sat, 28 Mar 2026 15:14:42 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> >Lawrence Dג€™Oliveiro <ldo@nz.invalid> writes:  
>> >> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M_¶llers wrote:
>> >>  
>> >>>      diffns += 1000000000UL;  
>> >>
>> >> Can you write
>> >>
>> >>       diffns += 1_000_000_000UL;
>> >>
>> >> yet?  
>> >
>> >Not in C.  C23 introduces the apostrophe as a digit separator, copied
>> >from C++:
>> >
>> >      diffns += 1'000'000'000UL;  
>> 
>> Or diffns += 1000ul * 1000ul * 1000ul;
>> 
>> or diffns += 1 * NS_PER_SEC;
>> 
>> with
>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>
> Why not (int)1e9 ?
[...]

Because int is not guaranteed to be wider than 16 bits (though if
you're already relying on Windows or POSIX, you can assume it's at
least 32 bits).  The original expression was of type unsigned long,
so (unsigned long)1e9 would be more nearly correct.

And because it's a floating-point to integer conversion in a
context that doesn't need floating-point.  I'm not sure whether
(unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
than 999999999.  Maybe it is, but I don't want to waste brain cells
proving it.

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

#397285

On Sun, 29 Mar 2026 13:54:47 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> > On Sat, 28 Mar 2026 15:14:42 GMT
> > scott@slp53.sl.home (Scott Lurndal) wrote:
> >  
> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:  
> >> >Lawrence Dג€™Oliveiro <ldo@nz.invalid> writes:    
> >> >> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M_¶llers wrote:
> >> >>    
> >> >>>      diffns += 1000000000UL;    
> >> >>
> >> >> Can you write
> >> >>
> >> >>       diffns += 1_000_000_000UL;
> >> >>
> >> >> yet?    
> >> >
> >> >Not in C.  C23 introduces the apostrophe as a digit separator,
> >> >copied from C++:
> >> >
> >> >      diffns += 1'000'000'000UL;    
> >> 
> >> Or diffns += 1000ul * 1000ul * 1000ul;
> >> 
> >> or diffns += 1 * NS_PER_SEC;
> >> 
> >> with
> >> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))  
> >
> > Why not (int)1e9 ?  
> [...]
> 
> Because int is not guaranteed to be wider than 16 bits (though if
> you're already relying on Windows or POSIX, you can assume it's at
> least 32 bits).  The original expression was of type unsigned long,
> so (unsigned long)1e9 would be more nearly correct.
> 
> And because it's a floating-point to integer conversion in a
> context that doesn't need floating-point.  I'm not sure whether
> (unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
> than 999999999.  Maybe it is, but I don't want to waste brain cells
> proving it.
> 

IEEE binary64 has precise representations for all powers of 10 from 1e0
to 1e22. I.e it covers all powers of 10 that fit within 64-bit unsigned
integer with 3 values to spare.

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

#397287

Michael S <already5chosen@yahoo.com> writes:
> On Sun, 29 Mar 2026 13:54:47 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> > On Sat, 28 Mar 2026 15:14:42 GMT
>> > scott@slp53.sl.home (Scott Lurndal) wrote:
>> >  
>> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:  
>> >> >Lawrence Dג€™Oliveiro <ldo@nz.invalid> writes:    
>> >> >> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M_¶llers wrote:
>> >> >>    
>> >> >>>      diffns += 1000000000UL;    
>> >> >>
>> >> >> Can you write
>> >> >>
>> >> >>       diffns += 1_000_000_000UL;
>> >> >>
>> >> >> yet?    
>> >> >
>> >> >Not in C.  C23 introduces the apostrophe as a digit separator,
>> >> >copied from C++:
>> >> >
>> >> >      diffns += 1'000'000'000UL;    
>> >> 
>> >> Or diffns += 1000ul * 1000ul * 1000ul;
>> >> 
>> >> or diffns += 1 * NS_PER_SEC;
>> >> 
>> >> with
>> >> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))  
>> >
>> > Why not (int)1e9 ?  
>> [...]
>> 
>> Because int is not guaranteed to be wider than 16 bits (though if
>> you're already relying on Windows or POSIX, you can assume it's at
>> least 32 bits).  The original expression was of type unsigned long,
>> so (unsigned long)1e9 would be more nearly correct.
>> 
>> And because it's a floating-point to integer conversion in a
>> context that doesn't need floating-point.  I'm not sure whether
>> (unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
>> than 999999999.  Maybe it is, but I don't want to waste brain cells
>> proving it.
>
> IEEE binary64 has precise representations for all powers of 10 from 1e0
> to 1e22. I.e it covers all powers of 10 that fit within 64-bit unsigned
> integer with 3 values to spare.

Sure, but the C standard doesn't guarantee IEEE-compatible
floating-point.

I'd be very surprised if any C implementation had (unsigned long)1e9
unequal to 1000000000.  If I ran across one, I'd seriously consider
submitting a bug report.  I'd have to study the C standard's
floating-point requirements to be sure (I haven't done that yet).

My point is that writing (unsigned long)1e9 rather than 1000000000 or
(1000ul * 1000ul * 1000ul) introduces complications I'd rather avoid.
It *might* be perfectly safe, but I'm uncomfortable relying on it.
If nothing else, if the program misbehaves, it's one less thing to
worry about while tracking down the bug.

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

#397296

On Sun, 29 Mar 2026 16:22:10 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> > On Sun, 29 Mar 2026 13:54:47 -0700
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:  
> >> Michael S <already5chosen@yahoo.com> writes:  
> >> > On Sat, 28 Mar 2026 15:14:42 GMT
> >> > scott@slp53.sl.home (Scott Lurndal) wrote:
> >> >    
> >> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:    
> >> >> >Lawrence Dג€™Oliveiro <ldo@nz.invalid> writes:      
> >> >> >> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M_¶llers wrote:
> >> >> >>      
> >> >> >>>      diffns += 1000000000UL;      
> >> >> >>
> >> >> >> Can you write
> >> >> >>
> >> >> >>       diffns += 1_000_000_000UL;
> >> >> >>
> >> >> >> yet?      
> >> >> >
> >> >> >Not in C.  C23 introduces the apostrophe as a digit separator,
> >> >> >copied from C++:
> >> >> >
> >> >> >      diffns += 1'000'000'000UL;      
> >> >> 
> >> >> Or diffns += 1000ul * 1000ul * 1000ul;
> >> >> 
> >> >> or diffns += 1 * NS_PER_SEC;
> >> >> 
> >> >> with
> >> >> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))    
> >> >
> >> > Why not (int)1e9 ?    
> >> [...]
> >> 
> >> Because int is not guaranteed to be wider than 16 bits (though if
> >> you're already relying on Windows or POSIX, you can assume it's at
> >> least 32 bits).  The original expression was of type unsigned long,
> >> so (unsigned long)1e9 would be more nearly correct.
> >> 
> >> And because it's a floating-point to integer conversion in a
> >> context that doesn't need floating-point.  I'm not sure whether
> >> (unsigned long)1e9 is actually guaranteed to yield 1000000000
> >> rather than 999999999.  Maybe it is, but I don't want to waste
> >> brain cells proving it.  
> >
> > IEEE binary64 has precise representations for all powers of 10 from
> > 1e0 to 1e22. I.e it covers all powers of 10 that fit within 64-bit
> > unsigned integer with 3 values to spare.  
> 
> Sure, but the C standard doesn't guarantee IEEE-compatible
> floating-point.
> 

I am not in the racket of uber-portable. Don't want to be accused of
trespassing into pasture of James K.

> I'd be very surprised if any C implementation had (unsigned long)1e9
> unequal to 1000000000.  If I ran across one, I'd seriously consider
> submitting a bug report.  I'd have to study the C standard's
> floating-point requirements to be sure (I haven't done that yet).
> 

I know one environment where bug of that sort could happen, but not for
1e9. It could happen for 1e19, which is a border-line case (it fits in
uint64_t, but does not fit in int64_t).
However environment in question is not C. C compiler from the same
vendor (MS, if  you wonder) handles (uint64_t)1e19 just fine.

> My point is that writing (unsigned long)1e9 rather than 1000000000 or
> (1000ul * 1000ul * 1000ul) introduces complications I'd rather avoid.
> It *might* be perfectly safe, but I'm uncomfortable relying on it.
> If nothing else, if the program misbehaves, it's one less thing to
> worry about while tracking down the bug.
> 

IMHO, improvement that 1e9 brings in readability and in elimination of
possibilities of mis-typing is worth all extremely unlikely troubles
that you mentioned above. YMMV.

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

#397316

On 2026-03-29 16:54, Keith Thompson wrote:
...
> context that doesn't need floating-point.  I'm not sure whether
> (unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
> than 999999999.  Maybe it is, but I don't want to waste brain cells
> proving it.

I'll waste my brain cells.

"When a finite value of decimal floating type is converted to an integer
type other than bool, the fractional part is discarded (i.e. the value
is truncated toward zero)." (6.3.2.4p2)

"For decimal floating literals ... the result is either the nearest
representable value, or the larger or smaller representable value
immediately adjacent to the nearest representable value, chosen in an
implementation-defined manner." (6.4.5.3p4)

This allows for 1e9 to have a value of exactly 1000000000.0, or slightly
higher, which converts to unsigned long as 1000000000, or a value
slightly less than 1000000000.0, which will convert to 999999999.

So you were right - don't use floating point to do what integer types
are sufficient to do.

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

#397324

On Mon, 30 Mar 2026 20:37:06 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 2026-03-29 16:54, Keith Thompson wrote:
> ...
> > context that doesn't need floating-point.  I'm not sure whether
> > (unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
> > than 999999999.  Maybe it is, but I don't want to waste brain cells
> > proving it.  
> 
> I'll waste my brain cells.
> 
> "When a finite value of decimal floating type is converted to an
> integer type other than bool, the fractional part is discarded (i.e.
> the value is truncated toward zero)." (6.3.2.4p2)
> 
> "For decimal floating literals ... the result is either the nearest
> representable value, or the larger or smaller representable value
> immediately adjacent to the nearest representable value, chosen in an
> implementation-defined manner." (6.4.5.3p4)
> 
> This allows for 1e9 to have a value of exactly 1000000000.0, or
> slightly higher, which converts to unsigned long as 1000000000, or a
> value slightly less than 1000000000.0, which will convert to
> 999999999.
> 

Not when compiler declares itself compliant with IEEE-754 (or IEC
559). By 754, if value is representable exactly then it shall be
chosen, unconditionally. No "adjacent" allowed.

> So you were right - don't use floating point to do what integer types
> are sufficient to do.
> 

You can do what you feel right. And I would do what I feel right.
And I am going to continue to suggest what I think is right to other
people that, like me, care very little about what weird things are
permitted to implementer according to C Standard as long as all
implementations that they are likely to encounter in practice provide
much stronger guarantees.

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

#397332

On 2026-03-31 04:48, Michael S wrote:
> On Mon, 30 Mar 2026 20:37:06 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> "When a finite value of decimal floating type is converted to an
>> integer type other than bool, the fractional part is discarded (i.e.
>> the value is truncated toward zero)." (6.3.2.4p2)
>>
>> "For decimal floating literals ... the result is either the nearest
>> representable value, or the larger or smaller representable value
>> immediately adjacent to the nearest representable value, chosen in an
>> implementation-defined manner." (6.4.5.3p4)
>>
>> This allows for 1e9 to have a value of exactly 1000000000.0, or
>> slightly higher, which converts to unsigned long as 1000000000, or a
>> value slightly less than 1000000000.0, which will convert to
>> 999999999.
>>
> 
> Not when compiler declares itself compliant with IEEE-754 (or IEC
> 559). By 754, if value is representable exactly then it shall be
> chosen, unconditionally. No "adjacent" allowed.

I was talking about what the C standard requires. While the standard
allows your code to determine whether or not it is being translated by
an implementation which supports IEEE/IEC 60559, it doesn't mandate such
support.

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

#397336

James Kuyper <jameskuyper@alumni.caltech.edu> wrote at 00:37 this Tuesday (GMT):
> On 2026-03-29 16:54, Keith Thompson wrote:
> ...
>> context that doesn't need floating-point.  I'm not sure whether
>> (unsigned long)1e9 is actually guaranteed to yield 1000000000 rather
>> than 999999999.  Maybe it is, but I don't want to waste brain cells
>> proving it.
>
> I'll waste my brain cells.
>
> "When a finite value of decimal floating type is converted to an integer
> type other than bool, the fractional part is discarded (i.e. the value
> is truncated toward zero)." (6.3.2.4p2)
>
> "For decimal floating literals ... the result is either the nearest
> representable value, or the larger or smaller representable value
> immediately adjacent to the nearest representable value, chosen in an
> implementation-defined manner." (6.4.5.3p4)
>
> This allows for 1e9 to have a value of exactly 1000000000.0, or slightly
> higher, which converts to unsigned long as 1000000000, or a value
> slightly less than 1000000000.0, which will convert to 999999999.
>
> So you were right - don't use floating point to do what integer types
> are sufficient to do.


Floats should not be used for any kinda comparisons besides basic
greater than/less than checks or flooring it beforehand, its just too
unreliable.

also languages that make no distinguishment are very frustrating
sometimes
-- 
user <candycane> is generated from /dev/urandom

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

#397368

On 28/03/2026 01:46, Lawrence D’Oliveiro wrote:
> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
> 
>>      diffns += 1000000000UL;
> 
> Can you write
> 
>       diffns += 1_000_000_000UL;
> 
> yet?

#define NUMg(a,...) a
#define NUMf(a,...) NUMg(a##__VA_ARGS__)
#define NUMe(a,...) NUMf(a##__VA_ARGS__)
#define NUMd(a,...) NUMe(a##__VA_ARGS__)
#define NUMc(a,...) NUMd(a##__VA_ARGS__)
#define NUMb(a,...) NUMc(a##__VA_ARGS__)
#define NUMa(a,...) NUMb(a##__VA_ARGS__)
#define NUM9(a,...) NUMa(a##__VA_ARGS__)
#define NUM8(a,...) NUM9(a##__VA_ARGS__)
#define NUM7(a,...) NUM8(a##__VA_ARGS__)
#define NUM6(a,...) NUM7(a##__VA_ARGS__)
#define NUM5(a,...) NUM6(a##__VA_ARGS__)
#define NUM4(a,...) NUM5(a##__VA_ARGS__)
#define NUM3(a,...) NUM4(a##__VA_ARGS__)
#define NUM2(a,...) NUM3(a##__VA_ARGS__)
#define NUM1(a,...) NUM2(a##__VA_ARGS__)
#define NUM(a,...)  NUM1(a##__VA_ARGS__)

NUM(1,000,000,UL)


-- 
Tristan Wibberley

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web