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

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

.5 against 0.5f

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

Contents

  .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 11:53 +0100
    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 17:45 +0000
      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 18:50 +0100
        Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:01 +0000
          Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 20:15 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:54 +0000
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:10 -0700
                Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:20 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-27 21:35 +0100
              Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:00 -0400
                Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 22:15 +0000
                Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 06:54 -0700
            Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 21:57 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:18 -0700
            Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:19 -0400
              Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 21:54 +0000
                Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:58 -0700
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:11 -0400
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 23:21 -0700
      Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 18:40 +0000
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-27 12:29 -0700
          Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:11 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:25 -0700
        Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 21:43 +0200
          Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:05 +0200
            Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:51 +0200
        Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 20:05 +0000
          Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-27 21:03 +0000
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:41 -0700
            Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-28 16:23 +0000
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:25 -0400
        Re: .5 against 0.5f makendo <makendo@makendo.invalid> - 2026-10-29 18:04 +0800
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 05:01 -0700
            Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 13:55 +0100
              Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-29 14:32 +0000
            Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 23:19 +0100
          Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 00:50 +0000
            Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 05:01 +0100
              Re: .5 against 0.5f "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-30 02:39 -0700
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 11:06 +0100
                Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 14:07 +0100
              Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-30 13:55 +0000
                Re: .5 against 0.5f "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-30 07:45 -0700
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 21:17 -0700
      Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 19:58 +0000
      Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 17:43 -0400
        Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:06 -0400
          Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 00:49 +0000
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 18:23 -0700
              Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 16:38 +0100
                Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:27 -0700
                  Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:08 +0100
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:56 -0700
                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 18:55 +0100
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 09:30 +0100
                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 04:54 -0700
                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 19:57 +0100
                        Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 20:56 +0100
                          Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 23:06 +0100
                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 13:39 -0700
                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:56 -0700
                        Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 04:38 +0100
                          Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 09:11 +0100
                            Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 14:54 +0100
                              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 15:25 +0100
                                Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 14:45 +0000
            Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:41 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:45 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 01:50 +0000
              Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:32 +0100
                Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:51 +0100
                  Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:55 +0100
                    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:27 +0000
                      Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 17:44 +0100
                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:22 +0000
                    Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:15 +0100
                      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:47 +0100
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 19:10 +0000
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:31 -0700
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 22:44 +0000
                        Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:27 +0100
                        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:39 -0700
                          Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 00:22 +0000
                            Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 17:59 -0700
                              Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 01:50 +0000
                                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:45 +0100
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 14:56 +0000
                                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 16:34 +0000
                                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:47 -0700
                                      Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:17 +0000
                                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:46 -0700
                                Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-29 11:56 -0400
                                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 17:57 +0000
                                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:06 -0700
                                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 00:21 +0000
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 19:49 +0000
                                    Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 22:55 +0100
                                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:29 -0700
                                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 03:57 +0100
                                        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 20:53 -0700
                                          Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 05:06 +0100
                                      Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 09:33 +0100
                                      Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 10:58 +0000
                                  Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-29 23:46 +0000
                                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 18:37 -0700
                                    Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 04:22 +0100
                                Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 17:58 +0100
                                Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:42 -0700
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:27 +0000
                                    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 02:08 +0000
                                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 19:37 -0700
            Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:39 +0100
              Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-28 22:25 +0200
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:48 +0100
                  Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 04:59 -0700
              Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 14:26 -0700
                Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-29 00:12 +0200
                  Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-28 22:33 +0000
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:01 +0100
                  Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:05 -0700
                    Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-30 11:58 +0200
                  Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:59 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:34 -0700
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:06 +0100
            Re: .5 against 0.5f tTh <tth@none.invalid> - 2026-10-28 15:08 +0100
              Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 07:49 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:36 -0700
        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:53 -0700
          Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:55 -0400
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:02 -0700
          Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:56 +0100
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 08:01 -0700
    Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:08 -0700

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

#403822

On 2026-10-30 04:53, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> In my personal coding style there's usually always a space.
> 
> Then you're objectively wrong.
> 
> (I kid, I kid!)

*phew!*

Oh, please, mind my heart - for a moment it stopped beating!

Janis

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

#403828

On 30/10/2026 00:29, Keith Thompson wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <11bvqbn$3g0tj$1@dont-email.me>,
>> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>>> On 2026-10-28 21:50, Steven G. Kargl wrote:
>>>> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>>>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>>>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>>>>> return statement, particularly if you dislike fluff.)
>>>>>>
>>>>>> Yeah, I was laugh too hard while typing ;-)
>>>>>>
>>>>>> Parentheses is a habit from BSD kernel source file style guide.
>>>>>
>>>>> Now is a good time to start unlearning that habit.
>>>>
>>>> Why?  What harm do the parentheses cause?
>>>
>>> They can lead to people thinking that return is a function, even if they
>>> nominally know better.
>>
>> What?  This is an incredibly weak argument.
>>
>> If someone thought that `return` was a function, then why
>> wouldn't they think that `if` or `while` were also functions?
>> Or `sizeof`, and so on?
> 
> I agree that it's a bit of a weak argument, but I wouldn't call it
> incredibly weak.
> 
> In my personal coding style, I try to avoid making things that are not
> function calls look like function calls.  In a function call, there's no
> space between the function name and the left parenthesis.  I don't use
> that style for anything other than function calls (or invocations of
> function-like macros).  Not because I don't know return and sizeof are
> keywords, but because it's just a little bit easier to read the code
> if distinctions like that are clear.
> 
> Examples:
> 
>      func(42);    // function call, or maybe a macro invocation
>      return 42;   // not return(42); or even "return (42);
>      if (cond)    // not if(cond)
>      sizeof (int) // not sizeof(int)
>      sizeof obj   // not sizeof(obj) or sizeof (obj)
> 

My preferences are similar, except that rather than distinguishing 
between functions and non-functions, I distinguish between statements 
and non-statements.  So I write "sizeof(int)", rather than having a 
space - I see the operator as being more akin to a function call or 
macro invocation than to a statement.

(I also write "sizeof(obj)", as that appears more natural to me than 
"sizeof obj", and more consistent - I do not like having the parentheses 
depend on whether the operand is a type or an expression.)

> The idea is to make the code just a little bit clearer and easier to
> read.  If I see something that looks it would be a function call except
> that the prefix is a keyword, it's *very slightly* annoying.
> Parentheses on a return statement are allowed, but they're part of the
> expression, not part of the syntax of the return statement, and they're
> superfluous.  I don't write `return (42);` for the same reason I don't
> write `x = (42);`.

When you have a coding style that you have used consistently for a long 
time, code written in a different style always looks a bit clumsy and 
ugly, and is inevitably at least marginally harder to read.  Some people 
do put spaces in weird places in their code, such as "if( x ){ ... }", 
or they don't use spaces at all, or apparently randomly add long runs of 
spaces.  There's no accounting for taste!

> 
> And of course *all* of these rules can be overridden by a coding
> standard or by the existing style of the surrounding code.

Indeed.

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

#403833

In article <11c0kst$3pmvb$2@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <11bvqbn$3g0tj$1@dont-email.me>,
>> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>>>[snip]
>>>They can lead to people thinking that return is a function, even if they
>>>nominally know better.
>>
>> What?  This is an incredibly weak argument.
>>
>> If someone thought that `return` was a function, then why
>> wouldn't they think that `if` or `while` were also functions?
>> Or `sizeof`, and so on?
>
>I agree that it's a bit of a weak argument, but I wouldn't call it
>incredibly weak.
>
>In my personal coding style, I try to avoid making things that are not
>function calls look like function calls.  In a function call, there's no
>space between the function name and the left parenthesis.  I don't use
>that style for anything other than function calls (or invocations of
>function-like macros).  Not because I don't know return and sizeof are
>keywords, but because it's just a little bit easier to read the code
>if distinctions like that are clear.
>[snip examples]

If I may paraphrase your argument, it's that you like to omit
parentheses where unnecessary, or otherwise make operators
visually distinct from function calls, so that while scanning
code they stand out.

But that is qualitatively different than what Kuyper said: "They
can lead to people thinking that return is a function", which is
ridiculous.  Anyone even passingly familiar with the language
knows that `return` in C is not a function, parentheses or no.

>[snip]
>The premise (at least for me) is not that someone would *think*
>that return is a function, but that making a return statement not
>look too much like a function call makes the code just a little
>bit easier to read.

Perhaps; perhaps not.  My day job involes working on a variant
of System V Unix, which has a very strict style guide similar to
(but different from...) FreeBSD's.  That guide is descended from
a document Bill Shannon put together at Sun for code in the
older, BSD-derived SunOS 4.x operating system; a few years ago,
another engineer and I took that document, cleaned it up,
updated it to reflect existing practice, reorganized it a bit
to logically flow better, and published it as a man page:
https://illumos.org/man/7/style

There are many things in there that I do not personally like;
mandatory parentheses around the expression in a `return` are
among them, but also the outright ban on `//` comments, macros
over inline functions, and so on.  I hold my nose and follow it
because that's a requirement of the job.  *Shrug*

But sometimes I am very surprised at what my colleagues find
unreadable; recently I wrote a rather large driver for an IP in
our SoC complexes, and among the things that driver does are
allocating physical address space to MMIO.  The internal
function one calls to do such things takes a number of
arguments, including a pointer to an attributes structure, an
address, a size, flags, and so on.  I had neatly grouped the
arguments onto lines so that, for example, the pointer to the
attributes structure was on one line, then a line break and then
the address and size together by themselves on the next line,
etc.  The reviewer (who's been working in this source base for
several decades) found that very difficult to read and asked me
to fill the lines as much as I could, up to the 80-column
maximum (another limit I find silly); ironically, I found that
much more difficult to read.

The point is, "readability" can be subjective.  What one person
finds easy to read may not be so for another.

>And in the example that started this subthread, I probably wouldn't
>have mentioned the parentheses if the poster hadn't been complaining
>about "fluff".

Yeah, that's fair.  The poster seems unnecessarily combative in
a weird way.

	- Dan C.

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

#403807

On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:

> They can lead to people thinking that return is a function ...

There shouldn’t be a return statement at all. Smashing together the
assignment of the function result with termination of function
execution seems to me a code smell.

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

#403814

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
>
>> They can lead to people thinking that return is a function ...
>
> There shouldn't be a return statement at all.  Smashing together
> the assignment of the function result with termination of function
> execution seems to me a code smell.

It must be terrible to have such a highly sensitive nose in a world
with so many heathen programming language designers.

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

#403818

On 2026-10-30 00:46, Lawrence D’Oliveiro wrote:
> On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
> 
>> They can lead to people thinking that return is a function ...
> 
> There shouldn’t be a return statement at all. Smashing together the
> assignment of the function result with termination of function
> execution seems to me a code smell.

I sense you may have the Algol 68 structure in mind (where all
clauses just return the value that is _plainly stated_ without
keyword); which is indeed very elegant for "normal" exits from
functions. But we have to remember how "hard" (= ugly) it is
to _early exit_ from functions there, needing an extra keyword,
a special syntax rule, and a jump/label.

Janis

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

#403790

On 2026-10-29 02:50, Steven G. Kargl wrote:
> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>
>>>> [...], and you don't need parentheses on the
>>>> return statement, particularly if you dislike fluff.)
>>>
>>> [...]
>>>
>>> Parentheses is a habit from BSD kernel source file style guide.
>>
>> Now is a good time to start unlearning that habit.
> 
> Why?  What harm do the parentheses cause?
> 
> Unlearning is not likely to happen. [...]

I understand that long fostered habits are hard to change, so I
certainly wouldn't criticize that; and especially since they do
no harm as you say. (They're only "unnecessary fluff".)

>>> [BSD style]
>>> % man 9 style
>>> ...
>>>       Values in return statements should be enclosed in parentheses.
>>> [...]
>> [...]
> 
> Do you ignore the style requirements of all the projects
> that you may have worked on, and simply use whatever
> your personal preferences are?

Following some projects' style requirements is certainly the most
important argument here!


Myself I started with "C" using parenthesis - and I wondered why!
The reason (in my case) was obviously that this had been the style
that was regularly used in the _K&R book_ (where I learned the "C"
language from).

But at some point (meanwhile decades ago) when I got aware that the
parenthesis are unnecessary I immediately switched to the (IMO)
much cleaner form without the spurious parenthesis. (There's already
far too many [mandatory] parenthesis in the language, to my taste.)

Janis

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

#403802

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:

> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>
>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>
>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>> return statement, particularly if you dislike fluff.)
>>>
>>> Yeah, I was laugh too hard while typing ;-)
>>>
>>> Parentheses is a habit from BSD kernel source file style guide.
>>
>> Now is a good time to start unlearning that habit.
>
> Why?  What harm do the parentheses cause?

Wrong question.  The important question is what benefit do they
give?  Granted, there may be circumstances where there is some
benefit.  But what benefit justifies using parentheses in *all*
circumstances?

> Unlearning is not likely to happen.  I've been a long-time
> contributor to FreeBSD, and have no plans to stop.  Feel
> free to check the git history on FreeBSD libm sources.
> My finger prints are all over the code.  So, yeah, I know
> a enough about floating point arithmetic and C standard
> requirements to be dangerous.
>
>>> % man 9 style
>>> ...
>>>
>>>      Values in return statements should be enclosed in parentheses.
>>>
>>>
>>> I also have debugging macros RETURNI() that require parens.
>>
>> That strengthens the motivation not to use parentheses with
>> return statements, to emphasize that they are different from
>> the macros.
>
> Do you ignore the style requirements of all the projects
> that you may have worked on, and simply use whatever
> your personal preferences are?

Please note what I said.  I did not say never to use parentheses.
What I did say is that now is a good time to start unlearning the
habit of (always) using parentheses.  If you're writing code
destined for FreeBSD, by all means put in the extra parentheses.
On the other hand, if you're writing code to put in a posting for
comp.lang.c, it's more common not to use extra parentheses.  When
in Rome, do as the Romans do.  If you have a compelling reason to
use such redundant parentheses here in the newsgroup, please tell
us what it is.  Otherwise, is it you who is ignoring the style
norms of the group who will be reading your code?

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

#403813

In article <86se1oku25.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>
>> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>>
>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>>
>>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>>
>>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>>> return statement, particularly if you dislike fluff.)
>>>>
>>>> Yeah, I was laugh too hard while typing ;-)
>>>>
>>>> Parentheses is a habit from BSD kernel source file style guide.
>>>
>>> Now is a good time to start unlearning that habit.
>>
>> Why?  What harm do the parentheses cause?
>
>Wrong question.  The important question is what benefit do they
>give?  Granted, there may be circumstances where there is some
>benefit.  But what benefit justifies using parentheses in *all*
>circumstances?

Consistency with existing code and conformance with an
externally mandated style guide, obviously.

>> Unlearning is not likely to happen.  I've been a long-time
>> contributor to FreeBSD, and have no plans to stop.  Feel
>> free to check the git history on FreeBSD libm sources.
>> My finger prints are all over the code.  So, yeah, I know
>> a enough about floating point arithmetic and C standard
>> requirements to be dangerous.
>>
>>>> % man 9 style
>>>> ...
>>>>
>>>>      Values in return statements should be enclosed in parentheses.
>>>>
>>>>
>>>> I also have debugging macros RETURNI() that require parens.
>>>
>>> That strengthens the motivation not to use parentheses with
>>> return statements, to emphasize that they are different from
>>> the macros.
>>
>> Do you ignore the style requirements of all the projects
>> that you may have worked on, and simply use whatever
>> your personal preferences are?
>
>Please note what I said.  I did not say never to use parentheses.
>What I did say is that now is a good time to start unlearning the
>habit of (always) using parentheses.  If you're writing code
>destined for FreeBSD, by all means put in the extra parentheses.
>On the other hand, if you're writing code to put in a posting for
>comp.lang.c, it's more common not to use extra parentheses.  When
>in Rome, do as the Romans do.  If you have a compelling reason to
>use such redundant parentheses here in the newsgroup, please tell
>us what it is.  Otherwise, is it you who is ignoring the style
>norms of the group who will be reading your code?

This newsgroup has no "norms" for code style.  Period.

You are stating your preference as if it is some agreed upon, de
facto standard.  It is not, nor is it a requirement for posting
here.  No one posting here is obligated to omit the parentheses
to satisfy the whims of you, me, or anyone else.  Hell, they can
unironically use the GNU style if they really want.

OP: you want to parenthesize the expression in a `return`
statement because that's what you're used to from FreeBSD?  Go
for it.  Some folks may find it unnecessary; that's fine.  But
don't listen to someone trying to tell you that you're violating
some set of invisible mores by doing so; that nonsense.

	- Dan C.

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

#403815

On Fri, 30 Oct 2026 01:27:03 -0000 (UTC), Dan Cross wrote:

> In article <86se1oku25.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>
>>> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>>>
>>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>>>
>>>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>>>
>>>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>>>> return statement, particularly if you dislike fluff.)
>>>>>
>>>>> Yeah, I was laugh too hard while typing ;-)
>>>>>
>>>>> Parentheses is a habit from BSD kernel source file style guide.
>>>>
>>>> Now is a good time to start unlearning that habit.
>>>
>>> Why?  What harm do the parentheses cause?
>>
>>Wrong question.  The important question is what benefit do they
>>give?  Granted, there may be circumstances where there is some
>>benefit.  But what benefit justifies using parentheses in *all*
>>circumstances?
> 
> Consistency with existing code and conformance with an
> externally mandated style guide, obviously.
> 
>>> Unlearning is not likely to happen.  I've been a long-time
>>> contributor to FreeBSD, and have no plans to stop.  Feel
>>> free to check the git history on FreeBSD libm sources.
>>> My finger prints are all over the code.  So, yeah, I know
>>> a enough about floating point arithmetic and C standard
>>> requirements to be dangerous.
>>>
>>>>> % man 9 style
>>>>> ...
>>>>>
>>>>>      Values in return statements should be enclosed in parentheses.
>>>>>
>>>>>
>>>>> I also have debugging macros RETURNI() that require parens.
>>>>
>>>> That strengthens the motivation not to use parentheses with
>>>> return statements, to emphasize that they are different from
>>>> the macros.
>>>
>>> Do you ignore the style requirements of all the projects
>>> that you may have worked on, and simply use whatever
>>> your personal preferences are?
>>
>>Please note what I said.  I did not say never to use parentheses.
>>What I did say is that now is a good time to start unlearning the
>>habit of (always) using parentheses.  If you're writing code
>>destined for FreeBSD, by all means put in the extra parentheses.
>>On the other hand, if you're writing code to put in a posting for
>>comp.lang.c, it's more common not to use extra parentheses.  When
>>in Rome, do as the Romans do.  If you have a compelling reason to
>>use such redundant parentheses here in the newsgroup, please tell
>>us what it is.  Otherwise, is it you who is ignoring the style
>>norms of the group who will be reading your code?
> 
> This newsgroup has no "norms" for code style.  Period.
> 
> You are stating your preference as if it is some agreed upon, de
> facto standard.  It is not, nor is it a requirement for posting
> here.  No one posting here is obligated to omit the parentheses
> to satisfy the whims of you, me, or anyone else.  Hell, they can
> unironically use the GNU style if they really want.
> 
> OP: you want to parenthesize the expression in a `return`
> statement because that's what you're used to from FreeBSD?  Go
> for it.  Some folks may find it unnecessary; that's fine.  But
> don't listen to someone trying to tell you that you're violating
> some set of invisible mores by doing so; that nonsense.

I have been lurking in c.l.c for over 2 decades.  I know that
there is no coding style guide, here.  I have contributed code
to both FreeBSD and GCC, again, for over 2 decades.  I'm
well-aware of the requirements in both FreeBSD's style(9) and
the GNU coding standard.  Neither use my preferred 3-space
indentation at all indentation levels.  Oh well.

C23, Annex A shows the syntax rule: 'return expression_{opt}'
with _{opt} denoting a subscript.  Unsurprisingly, 6.5.2 shows

primary-expression:
   ...
   ( expression )
   ...

so, the code I posted with 'return (0)' is standard conforming.

-- 
steve

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

#403816

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
[...]
> C23, Annex A shows the syntax rule: 'return expression_{opt}'
> with _{opt} denoting a subscript.  Unsurprisingly, 6.5.2 shows
>
> primary-expression:
>    ...
>    ( expression )
>    ...
>
> so, the code I posted with 'return (0)' is standard conforming.

Of course, and nobody has suggested otherwise.

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

#403696

On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
> 
>> However, if you need double precision, you shouldn't be using the
>> "f" suffix.
> 
> Is there any situation where you *should* use the “f” suffix?
> 
> I am thinking: no.

Try thinking harder.

I use the "f" suffix all the time in my code, because I do not want 
double precision.  In many situations, single precision arithmetic is at 
least twice as fast as double precision - in some situations it can be 
two orders of magnitude faster.

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

#403739

On Wed, 28 Oct 2026 08:39:23 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
> > On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
> >   
> >> However, if you need double precision, you shouldn't be using the
> >> "f" suffix.  
> > 
> > Is there any situation where you *should* use the “f” suffix?
> > 
> > I am thinking: no.  
> 
> Try thinking harder.
> 
> I use the "f" suffix all the time in my code, because I do not want 
> double precision.  In many situations, single precision arithmetic is
> at least twice as fast as double precision - in some situations it
> can be two orders of magnitude faster.
> 
> 

I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.

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

#403775

On 28/10/2026 21:25, Michael S wrote:
> On Wed, 28 Oct 2026 08:39:23 +0100
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
>>> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
>>>    
>>>> However, if you need double precision, you shouldn't be using the
>>>> "f" suffix.
>>>
>>> Is there any situation where you *should* use the “f” suffix?
>>>
>>> I am thinking: no.
>>
>> Try thinking harder.
>>
>> I use the "f" suffix all the time in my code, because I do not want
>> double precision.  In many situations, single precision arithmetic is
>> at least twice as fast as double precision - in some situations it
>> can be two orders of magnitude faster.
>>
>>
> 
> I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
> It somewhat depends on my mood in specific day, but likelihood is
> certainly not in favor of 0.1f.
> 
That seems a bit excessive to me, but okay.  The principle is the same, 
making it clear to the reader and the compiler that no double-precision 
arithmetic is involved.

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

#403782

David Brown <david.brown@hesbynett.no> writes:
> On 28/10/2026 21:25, Michael S wrote:
[...]
>> I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
>> It somewhat depends on my mood in specific day, but likelihood is
>> certainly not in favor of 0.1f.
>> 
> That seems a bit excessive to me, but okay.  The principle is the
> same, making it clear to the reader and the compiler that no
> double-precision arithmetic is involved.

Except that, at least in the abstract machine, `(float)0.1` produces
a value of type double and converts it to float.  It's likely that
a compiler would generate the same code as for `0.1f`, but I'd want
to confirm that if it mattered.  (Actually, I'd just write `0.1f`.)

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

#403743

David Brown <david.brown@hesbynett.no> writes:
> On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
>> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
>>> However, if you need double precision, you shouldn't be using the
>>> "f" suffix.
>> Is there any situation where you *should* use the “f” suffix?
>> I am thinking: no.
>
> Try thinking harder.
>
> I use the "f" suffix all the time in my code, because I do not want
> double precision.  In many situations, single precision arithmetic is
> at least twice as fast as double precision - in some situations it can
> be two orders of magnitude faster.

If you define objects as type float rather than double, do you have
examples of code where using 0.1f rather than 0.1 makes a difference?

One simple example: These two declarations result in identical code
using gcc:

    float f = 0.1f;
    float f = 0.1;

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

#403752

On Wed, 28 Oct 2026 14:26:05 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> David Brown <david.brown@hesbynett.no> writes:
> > On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:  
> >> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:  
> >>> However, if you need double precision, you shouldn't be using the
> >>> "f" suffix.  
> >> Is there any situation where you *should* use the “f” suffix?
> >> I am thinking: no.  
> >
> > Try thinking harder.
> >
> > I use the "f" suffix all the time in my code, because I do not want
> > double precision.  In many situations, single precision arithmetic
> > is at least twice as fast as double precision - in some situations
> > it can be two orders of magnitude faster.  
> 
> If you define objects as type float rather than double, do you have
> examples of code where using 0.1f rather than 0.1 makes a difference?
> 
> One simple example: These two declarations result in identical code
> using gcc:
> 
>     float f = 0.1f;
>     float f = 0.1;
> 

David almost certainly was talking about use of 0.1f in arithmetic
expressions rather than in simple initialization.

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

#403755

On 28/10/2026 22:12, Michael S wrote:
> On Wed, 28 Oct 2026 14:26:05 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
>>>> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
>>>>> However, if you need double precision, you shouldn't be using the
>>>>> "f" suffix.
>>>> Is there any situation where you *should* use the “f” suffix?
>>>> I am thinking: no.
>>>
>>> Try thinking harder.
>>>
>>> I use the "f" suffix all the time in my code, because I do not want
>>> double precision.  In many situations, single precision arithmetic
>>> is at least twice as fast as double precision - in some situations
>>> it can be two orders of magnitude faster.
>>
>> If you define objects as type float rather than double, do you have
>> examples of code where using 0.1f rather than 0.1 makes a difference?
>>
>> One simple example: These two declarations result in identical code
>> using gcc:
>>
>>      float f = 0.1f;
>>      float f = 0.1;
>>
> 
> David almost certainly was talking about use of 0.1f in arithmetic
> expressions rather than in simple initialization.
> 
> 

Yeah, intermediate calculations using 64 bits can give a different and 
more precise result even after it has been converted to 32 bits.

For example this:

#include <stdio.h>

   int main(void) {
     float a = 0.1f * 0.1f;
     float b = 0.1 * 0.1;

     printf("%20.20f\n", a);
     printf("%20.20f\n", b);
     printf("%20.20f\n", 1 - a * 100);
     printf("%20.20f\n", 1 - b * 100);
   }


Displays:

   0.01000000070780515671
   0.00999999977648258209
  -0.00000011920928955078
   0.00000000000000000000

on gcc 9.x on x64.

It will need the compiler to do the reduction, but DB is likely using a 
cross-compiler so it is not being done within target device,

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

#403777

On 28/10/2026 23:33, bartc wrote:
> On 28/10/2026 22:12, Michael S wrote:
>> On Wed, 28 Oct 2026 14:26:05 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 28/10/2026 01:49, Lawrence D’Oliveiro wrote:
>>>>> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
>>>>>> However, if you need double precision, you shouldn't be using the
>>>>>> "f" suffix.
>>>>> Is there any situation where you *should* use the “f” suffix?
>>>>> I am thinking: no.
>>>>
>>>> Try thinking harder.
>>>>
>>>> I use the "f" suffix all the time in my code, because I do not want
>>>> double precision.  In many situations, single precision arithmetic
>>>> is at least twice as fast as double precision - in some situations
>>>> it can be two orders of magnitude faster.
>>>
>>> If you define objects as type float rather than double, do you have
>>> examples of code where using 0.1f rather than 0.1 makes a difference?
>>>
>>> One simple example: These two declarations result in identical code
>>> using gcc:
>>>
>>>      float f = 0.1f;
>>>      float f = 0.1;
>>>
>>
>> David almost certainly was talking about use of 0.1f in arithmetic
>> expressions rather than in simple initialization.
>>
>>
> 
> Yeah, intermediate calculations using 64 bits can give a different and 
> more precise result even after it has been converted to 32 bits.
> 
> For example this:
> 
> #include <stdio.h>
> 
>    int main(void) {
>      float a = 0.1f * 0.1f;
>      float b = 0.1 * 0.1;
> 
>      printf("%20.20f\n", a);
>      printf("%20.20f\n", b);
>      printf("%20.20f\n", 1 - a * 100);
>      printf("%20.20f\n", 1 - b * 100);
>    }
> 
> 
> Displays:
> 
>    0.01000000070780515671
>    0.00999999977648258209
>   -0.00000011920928955078
>    0.00000000000000000000
> 
> on gcc 9.x on x64.
> 
> It will need the compiler to do the reduction, but DB is likely using a 
> cross-compiler so it is not being done within target device,

Generally, yes.  (Though for this code, the compiler would pre-calculate 
the results at compile time.)  My calculations need to be as precise as 
required for their use - but anything beyond that is just a waste.  And 
if the microcontroller has hardware single-precision floating point but 
no double-precision, that wasted runtime is massive.

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

#403757

Michael S <already5chosen@yahoo.com> writes:
> On Wed, 28 Oct 2026 14:26:05 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>> > I use the "f" suffix all the time in my code, because I do not want
>> > double precision.  In many situations, single precision arithmetic
>> > is at least twice as fast as double precision - in some situations
>> > it can be two orders of magnitude faster.  
>> 
>> If you define objects as type float rather than double, do you have
>> examples of code where using 0.1f rather than 0.1 makes a difference?
>> 
>> One simple example: These two declarations result in identical code
>> using gcc:
>> 
>>     float f = 0.1f;
>>     float f = 0.1;
>
> David almost certainly was talking about use of 0.1f in arithmetic
> expressions rather than in simple initialization.

Agreed -- and I asked him for examples.  (And no, didn't mean to
suggest that there are no such examples.)

And now that I've thought about it a bit more, here's a possible
example:

    float f = rand(); // prevent optimization
    f *= 0.1;
//  f *= 0.1f;

With 0.1, f is promoted to double before being multiplied by 0.1, and
the result is converted to float.  With 0.1f, double is not involved.
And in the generated x86_64 assembly from gcc, I see cvtss2sd and
cvtsd2ss when I use 0.1 that don't appear when I use 0.1f.

Both expressions *might* yield the same result (and do in the small
handful of cases I've checked), but it would take more analysis
than I'm willing to perform to prove it in all cases.

I was too quick to assume that if a compiler sees 0.1 in an expression
involving float operands, it can safely treat it as 0.1f.  Since 0.1
causes the usual arithmetic conversions to convert the other operand
from float to double, I was very probably wrong.

I can still imagine a compiler optimizing `f *= 0.1;` to use
float arithmetic.  I wonder if there are more clear-cut examples.

I'm assuming that FLT_EVAL_METHOD==0, meaning that float expressions
are evaluated as float.  If FLT_EVAL_METHOD==1, float expressions
are evaluated to the range and precision of type double.

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

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

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

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

csiph-web