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

#403812

In article <86o6cckttt.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>> On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
>>
>>> Let me put it another way.  What benefit do you think there is from
>>> these parentheses?  Why does the FreeBSD style guide recommend them?
>>> I can see benefits in consistency of style once that usage has been
>>> established, but why have them in the first place?
>>
>> As we all know, FreeBSD is derived from software developed by
>> the CSRG at UC Berkeley during the 70's.  FreeBSD adopted the
>> Kernel Normal Format (KNF) from CSRG.  You will need to contact
>> a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
>> etc.  and them why KNF requires ().
>>
>> Perhaps, the C compiler from 40 or so years ago required
>> parentheses in a return statement.  Or, just maybe, members of
>> CSRG read K&R and noticed the authors of the book consistently
>> use paretheses in their examples.  Ah yes, let's look at
>> the documentation:
>>
>> % man 9 style
>>
>> HISTORY
>>     This manual page was originally based on the src/admin/style/style
>>     file from the 4.4BSD-Lite2 release, with frequent updates to
>>     reflect the current practice and desire of the FreeBSD project.
>>     src/admin/style/style is a codification by the CSRG of the
>>     programming style of Ken Thompson and Dennis Ritchie in Version6
>>     AT&T UNIX.
>>
>> So, it seems to be a preference of Ritchie.
>
>It may have been simply long-standing habit rather than preference.
>In the early days of C parentheses around return expressions were
>required, not optional.  I've been programming in C long enough to
>have been influenced by that requirement (and later learned to undo
>it).

When?  They were not required in typesetter C on 7th Edition
Unix, which is more or less what K&R described, and the grammar
in K&R1 just says `return _expression_;`:

```
$ ed paren.c
?paren.c
a
#include <stdio.h>

int
foo()
{
        return 2;
}

int
main()
{
        printf("foo() = %d\n", foo());
        return 0;
}
.
w
104
q
$ cc -o paren paren.c
$ ./paren
foo() = 2
$
```

Nor were they required in the rather different dialect used in
6th Edition Unix:

```
RESTRICTED RIGHTS

Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.

login: root
# cat >paren.c
foo()
{
        return 2;
}

int
main()
{
        printf("foo() = %d\n", foo());
        return 0;
}
# cc paren.c
# ./a.out
foo() = 2
#
```

Neither the parser in the 5th Edition compiler nor the 4th Ed
compiler (the latter from the recently recovered tape found at
Utah) requires parentheses in that position, either.

They _are_ required in the earliest extant compiler sources from
roughly 1972 (the `last1120c` and `prestruct-c` compilers
recovered from DECtape and published by Dennis Ritchie on his
web page), and it is true that the, "C Reference Manual" from
6th Ed shows parentheses around the expression in a `return`
statement; as mentioned, the 6th Ed compiler did not enforce
this, however.

It looks like parentheses were grammatically required around the
expression in a `return` statement for a brief period ca. 1972,
perhaps into early 1973, and never after that.  Certainly, I do
not believe that anyone posting here ever used one of the early
compilers that required this, unless it was an ersatz
implementation.

	- Dan C.

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

#403808

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
>> 
>> Let me put it another way.  What benefit do you think there is from 
>> these parentheses?  Why does the FreeBSD style guide recommend them?  I 
>> can see benefits in consistency of style once that usage has been 
>> established, but why have them in the first place?
>
> As we all know, FreeBSD is derived from software developed by
> the CSRG at UC Berkeley during the 70's.  FreeBSD adopted the
> Kernel Normal Format (KNF) from CSRG.  You will need to contact
> a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
> etc. and them why KNF requires ().
>
> Perhaps, the C compiler from 40 or so years ago required
> parentheses in a return statement.  Or, just maybe, members of
> CSRG read K&R and noticed the authors of the book consistently
> use paretheses in their examples.  Ah yes, let's look at
> the documentation:
>
> % man 9 style
>
> HISTORY
>      This manual page was originally based on the src/admin/style/style file
>      from the 4.4BSD-Lite2 release, with frequent updates to reflect the
>      current practice and desire of the FreeBSD project.
>      src/admin/style/style is a codification by the CSRG of the programming
>      style of Ken Thompson and Dennis Ritchie in Version 6 AT&T UNIX.
>
> So, it seems to be a preference of Ritchie.

A former preference.

In the 1975 C reference manual, the syntax for a return statement was:

    return ;
    return ( expression ) ;

In K&R1, 1978, the syntax was changed to:

    return ;
    return expression ;

but parentheses were used in the examples.

In K&R2, 1988, the examples did not use parentheses on return
statements.  (I don't know whether that was Ritchie's decision or
Kernighan's.)

It appears that the FreeBSD style rule is a relic of an earlier
version of C that required the parentheses.  AT&T V6 Unix was
released in 1975.

You can still use parentheses on return statements if you want to,
and you should do so if you're operating under a coding standard
that requires them.  They're part of the syntax of the expression,
not part of the syntax of the return statement.  I probably wouldn't
have said anything if you hadn't mocked the use of 25.0 or 25.0f
rather than 25 as "fluff".

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

#403788

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 would you think of

	return (a=b).retval;

You might never write such code, and might never read it either, but you
should have no trouble parsing it. Do you?

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

#403792

On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper 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 would you think of
> 
> 	return (a=b).retval;
> 
> You might never write such code, and might never read it either, but you
> should have no trouble parsing it. Do you?

Never written nor seen such a line of code.  Of course, a random
line of code taken out of context may have many interpretations
or no interpretation at all.  I likely know less than 25% of
what C can do as I am primarily interested in only C23 7.12 and
Annex F and G.

I do find it interesting that in a newgroup purportedly concerned
with discussions about the C programming language, I seem to have
been the only person in this thread to show a complete self-contained
piece of code so fir can see the consequences of not understanding
floating point arithmetic.

-- 
steve

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

#403805

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
>> On 2026-10-28 21:50, Steven G. Kargl wrote:
[...]
>>> 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 would you think of
>> 
>> 	return (a=b).retval;
>> 
>> You might never write such code, and might never read it either, but you
>> should have no trouble parsing it. Do you?
>
> Never written nor seen such a line of code.  Of course, a random
> line of code taken out of context may have many interpretations
> or no interpretation at all.  I likely know less than 25% of
> what C can do as I am primarily interested in only C23 7.12 and
> Annex F and G.

(7.12 is <math.h>; Annexes F and G are ISO/IEC 60559 arithmetic.)

The question isn't whether you've ever seen such code (which I'm
guessing James made up as an example).  The question is whether
you can easily understand it.  Someone who had a mental model that
return requires parentheses would likely have trouble with it.  (And
in fact very early versions of C did require parentheses on return
statements with an expression.)

> I do find it interesting that in a newgroup purportedly concerned
> with discussions about the C programming language, I seem to have
> been the only person in this thread to show a complete self-contained
> piece of code so fir can see the consequences of not understanding
> floating point arithmetic.

You may be one of the few people who's willing to engage with fir.
I didn't reply to him because I don't read his posts.

Are you the same person as steve g <Sgonedes1977@gmail.com>?

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

#403810

On Thu, 29 Oct 2026 16:06:03 -0700, Keith Thompson wrote:

> You may be one of the few people who's willing to engage with fir.
> I didn't reply to him because I don't read his posts.

I usually skip fir's post, but this one caught my eye
as it was a question about floating point.

> Are you the same person as steve g <Sgonedes1977@gmail.com>?

No.

-- 
steve

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

#403795

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?

>What would you think of
>
>	return (a=b).retval;
>
>You might never write such code, and might never read it either, but you
>should have no trouble parsing it. Do you?

I would think that code is bad, and unnecessarily obscure, but
perhaps someone _would_ write this code.

	struct v {
		int retval;
	};

	struct v a;

	int
	something(void)
	{
		struct v b;
		b.retval = 1;
		return (a=b).retval;
	}

Of course, it would make no difference if the `return` statement
were written as,

	return ((a=b).retval);

But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.

	- Dan C.

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

#403799

On 2026-10-29 20:49, Dan Cross wrote:
> [...]
> 
> But again, the whole premise (that a programmer familiar with C
> would ever think that `return` is a function) is silly.

Yes, that's hard to believe.

I've heard the argument somehow reversed, alike "You don't need
the parenthesis since 'return' is a statement (and no function)."
IOW, it was not about mistaking 'return' for a function, more to
make its _character as statement_ clear (and by that, en passant,
invalidate K&R's paragon which had been widely followed back then).

Janis

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

#403806

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)

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

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

[...]
> But again, the whole premise (that a programmer familiar with C
> would ever think that `return` is a function) is silly.

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.

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

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

#403817

On 2026-10-30 00:29, Keith Thompson wrote:
>> [...]
> [...]
> 
> 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 suppose we should read the second sentence also as your "personal
coding style". In my personal coding style there's usually always a
space. (Exception to that habit is in user-defined functions' calls
in Awk where it is required by the syntax, a is space disallowed.)

> [...]
> 
> 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 was funny. :-)

Janis

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

#403820

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-30 00:29, Keith Thompson wrote:
>>> [...]
>> [...]
>> 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 suppose we should read the second sentence also as your "personal
> coding style".

Yes, of course.

>                In my personal coding style there's usually always a
> space.

Then you're objectively wrong.

(I kid, I kid!)

[...]

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

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

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

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

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

csiph-web