Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #403612 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-10-27 11:53 +0100 |
| Last post | 2026-10-27 13:08 -0700 |
| Articles | 20 on this page of 116 — 17 participants |
Back to article view | Back to comp.lang.c
.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 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 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 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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 16:27 +0000 |
| Message-ID | <11bt7p9$2i0ag$2@dont-email.me> |
| In reply to | #403693 |
On Wed, 28 Oct 2026 07:55:11 +0100, fir wrote:
>> but i not tested/talked yet
> ai says even fast math not enebles that but there is a flag
>
>
> -fsingle-precision-constant.
It is a poor decision to depend on any specific compiler's
options unless you intend to never use any other compiler.
With clang, I see
% cc -o z.s -S -O3 -fsingle-precision-constant j8.c
cc: warning: optimization flag '-fsingle-precision-constant' is not
supported [-Wignored-optimization-argument]
HTH
--
steve
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-28 17:44 +0100 |
| Message-ID | <11bt8ph$2jb4n$1@dont-email.me> |
| In reply to | #403726 |
On 28/10/2026 17:27, Steven G. Kargl wrote: > On Wed, 28 Oct 2026 07:55:11 +0100, fir wrote: > > >>> but i not tested/talked yet >> ai says even fast math not enebles that but there is a flag >> >> >> -fsingle-precision-constant. > > It is a poor decision to depend on any specific compiler's > options unless you intend to never use any other compiler. It is fine to do so in non-portable code. Most of my work is specifically targeting gcc, and if the code is better (clearer, safer to maintain, more efficient) as a result of compiler-specific flags or compiler-specific extensions, that's fine. Of course, if the same results can be achieved without non-portable flags or extensions, that is better. The key use of flags like this is for microcontrollers with hardware support for single-precision floating point, but not for double precision - which then needs to be handled by software routines. The use of "-fsingle-precision-constant" is primarily for handling third-party code or other code that you don't want to change, but where you want to use single precision as much as possible. For your own code on such devices, you would use "f" suffixes. The "-Wdouble-promotion" flag is also very useful here - it will let you know if you have accidentally promoted a float (such as by using a double-precision constant in an expression).
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 16:22 +0000 |
| Message-ID | <11bt7ff$2i0ag$1@dont-email.me> |
| In reply to | #403692 |
On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
> (should i also write 0.0f insetad of 0 BTW?)
A lot of context removed. No. IMO, if you have
a numerical constant that can be written as an
integer and that integer is less than 2^P
where P is the precision of the floating point
type of interest (here, 2^P means 2 raised to
the Pth power), then simply write the numerical
constant as an integer. It's easier to read.
float foo(float a) {
float x = 25 * a;
return (x);
}
A compiler ought to convert 25 in the above to
25.f as 25 is exactly representable (at least in
IEEE-754 binary32 format) in float.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 19:15 +0100 |
| Message-ID | <11bte4h$2lmho$1@dont-email.me> |
| In reply to | #403724 |
Steven G. Kargl pisze:
> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>
>> (should i also write 0.0f insetad of 0 BTW?)
>
> A lot of context removed. No. IMO, if you have
> a numerical constant that can be written as an
> integer and that integer is less than 2^P
> where P is the precision of the floating point
> type of interest (here, 2^P means 2 raised to
> the Pth power), then simply write the numerical
> constant as an integer. It's easier to read.
>
> float foo(float a) {
> float x = 25 * a;
> return (x);
> }
>
> A compiler ought to convert 25 in the above to
> 25.f as 25 is exactly representable (at least in
> IEEE-754 binary32 format) in float.
>
there is something like integer*float multiplication , or not?
if so 25*a and 25.*a or 25.0f*a could make a difference
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 19:47 +0100 |
| Message-ID | <11btg0s$2mjpd$1@dont-email.me> |
| In reply to | #403730 |
fir pisze:
> Steven G. Kargl pisze:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>
>>> (should i also write 0.0f insetad of 0 BTW?)
>>
>> A lot of context removed. No. IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer. It's easier to read.
>>
>> float foo(float a) {
>> float x = 25 * a;
>> return (x);
>> }
>>
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.
>>
> there is something like integer*float multiplication , or not?
> if so 25*a and 25.*a or 25.0f*a could make a difference
and i would say it is good to be able to express what one wants
and write 25*a, 25.0d *a, 25.0f *a //if there would be version for double
but for me its really weird that compiler cant 25.*a resolve as floats
if optimisation is on and put those conversions
same as 25 imo shouldn be treated as int if in runtime faster it would
be if that would be short long or char
imo constant is constant so 25.1 imo even should not represent nor float
nor double but probably the 'ideal' value
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 19:10 +0000 |
| Message-ID | <11bthbd$2mfvi$1@dont-email.me> |
| In reply to | #403730 |
On Wed, 28 Oct 2026 19:15:45 +0100, fir wrote:
> Steven G. Kargl pisze:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>
>>> (should i also write 0.0f insetad of 0 BTW?)
>>
>> A lot of context removed. No. IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer. It's easier to read.
>>
>> float foo(float a) {
>> float x = 25 * a;
>> return (x);
>> }
>>
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.
>>
> there is something like integer*float multiplication , or not?
> if so 25*a and 25.*a or 25.0f*a could make a difference
For 25, 25., and 25.0f, the compiler ought to produce the
same assembly. Why? Because the integer 25 is exactly
representable in both float (IEEE-754 binary32) and double
(IEEE-754 binary64), and the float 25.0f is exactly
representable in double. A compiler can take advantage of
this to produce an optimal assembly listing. At least with
clang, one sees this.
float
foo(int n, float x)
{
// float a = x * 25;
// float a = x * 25.f;
float a = x * 25.;
return (a);
}
Selecting each declaration in order yields
% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s
% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s
% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s
Now, take x/10, x*0.1, and x*0.1f.
float
foo(int n, float x)
{
// float a = x * 0.1;
// float a = x * 0.1f;
float a = x / 10;
return (a);
}
The integer 10 is exactly representable, but a compiler will
likely produce a division, and that's what we see with clang
.LCPI0_0:
.long 0x41200000 # float 10
...
.cfi_def_cfa_register %rbp
divss .LCPI0_0(%rip), %xmm0
popq %rbp
.cfi_def_cfa %rsp, 8
retq
The real number 0.1 is not exactly representable in either
float or double. The compiler will chose the best available
floating point number nearest to 0.1 and 0.1f (and this
depends on the rounding mode). With 0.1f and clang, you get
.LCPI0_0:
.long 0x3dcccccd # float 0.100000001
...
.cfi_def_cfa_register %rbp
mulss .LCPI0_0(%rip), %xmm0
popq %rbp
.cfi_def_cfa %rsp, 8
retq
Finally, with 0.1, clang produces
.LCPI0_0:
.quad 0x3fb999999999999a # double 0.10000000000000001
...
.cfi_def_cfa_register %rbp
cvtss2sd %xmm0, %xmm0
mulsd .LCPI0_0(%rip), %xmm0
cvtsd2ss %xmm0, %xmm0
popq %rbp
.cfi_def_cfa %rsp, 8
retq
Notice, the conversions in this case. If numerical accuracy
is unimportant but speed is, then using 0.1f seems to be the
best choice. If numerical accuracy is important, one probably
use double from the get-go.
If you are going to work with floating point arithmetic,
then you should read Goldberg's paper. In fact, you
will likely want to read it multiple times.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-28 13:31 -0700 |
| Message-ID | <11btm2a$2ojn1$2@kst.eternal-september.org> |
| In reply to | #403724 |
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>> (should i also write 0.0f insetad of 0 BTW?)
>
> A lot of context removed. No. IMO, if you have
> a numerical constant that can be written as an
> integer and that integer is less than 2^P
> where P is the precision of the floating point
> type of interest (here, 2^P means 2 raised to
> the Pth power), then simply write the numerical
> constant as an integer. It's easier to read.
>
> float foo(float a) {
> float x = 25 * a;
> return (x);
> }
>
> A compiler ought to convert 25 in the above to
> 25.f as 25 is exactly representable (at least in
> IEEE-754 binary32 format) in float.
I disagree. Yes, the int constant 25 is implicitly converted to float
as part of the "usual arithmetic conversions". But I find
float x = 25.0 * a;
or even
float x = 25.0f * a;
clearer than
float x = 25 * a;
--
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]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 22:44 +0000 |
| Message-ID | <11bttrp$2qvg6$1@dont-email.me> |
| In reply to | #403741 |
On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>> (should i also write 0.0f insetad of 0 BTW?)
>>
>> A lot of context removed. No. IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer. It's easier to read.
>>
>> float foo(float a) {
>> float x = 25 * a;
>> return (x);
>> }
>>
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.
>
> I disagree. Yes, the int constant 25 is implicitly converted to float
> as part of the "usual arithmetic conversions". But I find
> float x = 25.0 * a;
> or even
> float x = 25.0f * a;
> clearer than
> float x = 25 * a;
ROTL. You find '25 * a' too difficult to realize
that it is twenty-five times a. The 2 or 3 extra
digits (i.e., '.', '0', and 'f') are nothing but
fluff.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-29 00:27 +0100 |
| Message-ID | <11bu0ds$139ta$13@dont-email.me> |
| In reply to | #403756 |
On 2026-10-28 23:44, Steven G. Kargl wrote:
> On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>> [...]
>>>
>>> float foo(float a) {
>>> float x = 25 * a;
>>> return (x);
>>> }
>>>
>>> A compiler ought to convert 25 in the above to
>>> 25.f as 25 is exactly representable (at least in
>>> IEEE-754 binary32 format) in float.
>>
>> I disagree. Yes, the int constant 25 is implicitly converted to float
>> as part of the "usual arithmetic conversions". But I find
>> float x = 25.0 * a;
>> or even
>> float x = 25.0f * a;
>> clearer than
>> float x = 25 * a;
>
> ROTL. You find '25 * a' too difficult to realize
> that it is twenty-five times a. The 2 or 3 extra
> digits (i.e., '.', '0', and 'f') are nothing but
> fluff.
I basically agree with Keith here.
It's not about "realizing" the _mathematical_ meaning of "25 * a",
or about having a clearer/terser (less "fluffy") expression.
I'm sure the compiler would be able to create the correct internal
representation based on the program context; in that respect the
"25" should suffice, and not even impose any additional conversion
operation. IMO. (There might be some hindrance based on C's design
that I'm not aware of, though.)
From a programmers' perspective it always appeared useful to see
the type of the involved components in expressions. That's way I
write in every language "25.0" if I want to express a Real value.
(In some language it can even be functionally important, or even
be mandated.)
Where I disagree is that the 'f' would be meaningful as "concept"
(even if in "C" there's two "sorts" of floats, and two literals
for the same abstract numeric domain of real numbers). (But see
my disclaimer above about possible home-brewed hindrances in "C".)
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-28 16:39 -0700 |
| Message-ID | <11bu12l$2rgo2$4@kst.eternal-september.org> |
| In reply to | #403756 |
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>>> (should i also write 0.0f insetad of 0 BTW?)
>>>
>>> A lot of context removed. No. IMO, if you have
>>> a numerical constant that can be written as an
>>> integer and that integer is less than 2^P
>>> where P is the precision of the floating point
>>> type of interest (here, 2^P means 2 raised to
>>> the Pth power), then simply write the numerical
>>> constant as an integer. It's easier to read.
>>>
>>> float foo(float a) {
>>> float x = 25 * a;
>>> return (x);
>>> }
>>>
>>> A compiler ought to convert 25 in the above to
>>> 25.f as 25 is exactly representable (at least in
>>> IEEE-754 binary32 format) in float.
>>
>> I disagree. Yes, the int constant 25 is implicitly converted to float
>> as part of the "usual arithmetic conversions". But I find
>> float x = 25.0 * a;
>> or even
>> float x = 25.0f * a;
>> clearer than
>> float x = 25 * a;
>
> ROTL. You find '25 * a' too difficult to realize
> that it is twenty-five times a. The 2 or 3 extra
> digits (i.e., '.', '0', and 'f') are nothing but
> fluff.
I didn't say that I find `25 * a` difficult to understand. I said
that I find `25.0 * a` clearer. Even if it's only very slightly
easier to understand, that's well worth the cost of typing two
extra characters.
In this particular case, the type "float" appears on the same line as
the constant. In other cases, you might have an isolated assignment
like `x = 25.0 * a;`. In such a case, I find the floating-point
constant helpful as a reminder that this is a floating-point
operation, not an integer operation.
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike 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]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-29 00:22 +0000 |
| Message-ID | <11bu3kk$2svh8$1@dont-email.me> |
| In reply to | #403761 |
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.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-28 17:59 -0700 |
| Message-ID | <868q3hmie0.fsf@linuxsc.com> |
| In reply to | #403763 |
"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. > % 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. Otherwise someone might wonder if there had been a #define return(x) return ...something involving x...
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-29 01:50 +0000 |
| Message-ID | <11bu8oi$2up7m$1@dont-email.me> |
| In reply to | #403764 |
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? 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? -- steve
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-29 10:45 +0100 |
| Message-ID | <11bv4jd$37ch9$1@dont-email.me> |
| In reply to | #403765 |
On 29/10/2026 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: >>> >>>> (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? I can't see that parentheses here cause any actual harm - but they are certainly unnecessary fluff, and do no good. Every extra level of parentheses adds to the cognitive effort required to understand and interpret an expression. It takes longer to read, and has a higher chance of misinterpretation. If the parenthesis are necessary - "(a + b) * c" - then this is clearly a cost worth paying. Sometimes parentheses are not necessary, but /reduce/ the cognitive effort, such as "(a > 2) && (a < 5)". Again, the parentheses are then a good thing (albeit subjectively). But in "return (x);", they add nothing but cognitive effort. The C programmer's brain has to consider and reject the possibility that this is a function call or a macro invocation. The effort is small, but nonetheless wasted. 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? > > 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? > When working on code with particular style requirements, it makes sense to follow those style requirements - even if you disagree with the requirements. When working on other code, you are then freed from following rules that are unnecessary or counter-productive. If I were contributing code to FreeBSD and it /requires/ parentheses in return statements for the code to be accepted, I'd put parentheses in return statements. If it merely /recommends/ them, I would not do so - but would change my mind if other FreeBSD contributors made a fuss about it. In no other code would I use them, and in code reviews I would ask for them to be removed. But I would not bother about them in throw-away Usenet code, except if the post was complaining about other unnecessary "fluff" :-)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-29 14:56 +0000 |
| Message-ID | <11bvmqg$7ip$1@reader2.panix.com> |
| In reply to | #403774 |
In article <11bv4jd$37ch9$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >> [snip] >> Why? What harm do the parentheses cause? > >I can't see that parentheses here cause any actual harm - but they are >certainly unnecessary fluff, and do no good. I agree; in my own code, I do not generally use parentheses around the expression I give in a `return` statement. But often our code is not our own, in the sense that we're constrained by working on a much larger project and there are externally imposed constraints that we must honor. I don't have to like them but, but I do have to abide by them. >Every extra level of parentheses adds to the cognitive effort required >to understand and interpret an expression. It takes longer to read, and >has a higher chance of misinterpretation. If the parenthesis are >necessary - "(a + b) * c" - then this is clearly a cost worth paying. >Sometimes parentheses are not necessary, but /reduce/ the cognitive >effort, such as "(a > 2) && (a < 5)". Again, the parentheses are then a >good thing (albeit subjectively). > >But in "return (x);", they add nothing but cognitive effort. The C >programmer's brain has to consider and reject the possibility that this >is a function call or a macro invocation. The effort is small, but >nonetheless wasted. > >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? I mostly agree with you. But when working on a large project, that spans many decades, with many different contributers, having uniformity is good. You mention cogitive load, but I submit that it is strictly worse in that regard to have to deal with multiple stylistic differences based on individual preference. My example is the Google monorepo. When I left Google, it contained about 2BLOC of code. All of which more or less conformed to Google's mandatory style "guides" (which were only "guides" insofar as allowing people to get explicit exemptions for very specific reasons from a small group of extremely senior engineers: like, Sanjay Ghemawat and Jeff Dean type of senior). Personally, I despised the style rules for almost all languages Google used; I thought the code was ugly. *But*, after a few weeks working in the codebase, they became all but invisible; I had to consciously think about them to remember my aesthetic objections. Furthermore, I claim that rigid adherence to _a_ set of rules, no matter how ugly I thought they were, was a big factor in allowing Google to scale to tends of thousands of engineers working concurrently in a multi-billion line codebase. Put another way, it is more important to have _a_ style that is used uniformly, while it is relatively less important what rules that style imposes. >>>> [snip] >>>> % 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. A metanote, not to David, but of course, reference to the `style(9)` man page _strengthens_ the argument for parenthesizing return'ed expressions when working with FreeBSD code. In fairness, it wasn't clear that that was the original context. >> Do you ignore the style requirements of all the projects >> that you may have worked on, and simply use whatever >> your personal preferences are? > >When working on code with particular style requirements, it makes sense >to follow those style requirements - even if you disagree with the >requirements. When working on other code, you are then freed from >following rules that are unnecessary or counter-productive. > >If I were contributing code to FreeBSD and it /requires/ parentheses in >return statements for the code to be accepted, I'd put parentheses in >return statements. If it merely /recommends/ them, I would not do so - >but would change my mind if other FreeBSD contributors made a fuss about >it. In no other code would I use them, and in code reviews I would ask >for them to be removed. > >But I would not bother about them in throw-away Usenet code, except if >the post was complaining about other unnecessary "fluff" :-) I do not find the amount of heat this has generated particularly useful. The parentheses may be superfluous, but they're not wrong, and if OP prefers to include them, it does no harm; in this case, there's a very good reason: OP works with FreeBSD code often, which mandates them; maintaining two separate styles to appease the USENET crowd is probably more cognitive effort than mentally blocking them out for a `return`. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-29 16:34 +0000 |
| Message-ID | <11bvsj4$3g32k$1@dont-email.me> |
| In reply to | #403774 |
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.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-29 15:47 -0700 |
| Message-ID | <86o6cckttt.fsf@linuxsc.com> |
| In reply to | #403789 |
"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).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-30 01:17 +0000 |
| Message-ID | <11c0r7j$89a$1@reader2.panix.com> |
| In reply to | #403804 |
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-29 16:46 -0700 |
| Message-ID | <11c0lsu$3pmvb$3@kst.eternal-september.org> |
| In reply to | #403789 |
"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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-10-29 11:56 -0400 |
| Message-ID | <11bvqbn$3g0tj$1@dont-email.me> |
| In reply to | #403765 |
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]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web