Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #153691 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2020-08-17 22:11 +0200 |
| Last post | 2020-08-23 08:03 -0700 |
| Articles | 20 on this page of 154 — 23 participants |
Back to article view | Back to comp.lang.c
widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-17 22:11 +0200
Re: widening multiplication Eric Sosman <esosman@comcast-dot-net.invalid> - 2020-08-17 16:30 -0400
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:27 +0200
Re: widening multiplication Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-08-17 13:33 -0700
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:24 +0200
Re: widening multiplication Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-08-21 14:47 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-17 21:52 +0100
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:22 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-17 14:10 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-17 22:33 +0100
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-17 15:13 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 11:33 +0200
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:20 +0200
Re: widening multiplication scott@slp53.sl.home (Scott Lurndal) - 2020-08-17 21:38 +0000
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:19 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 11:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-18 05:00 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 15:10 +0200
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-18 12:31 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 15:15 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 06:53 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 16:14 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 07:24 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 22:41 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-18 14:24 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-18 22:54 +0100
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 15:18 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-18 15:54 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-18 15:38 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 07:03 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 09:24 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 02:13 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 10:43 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 12:50 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 07:30 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 07:44 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 17:35 +0200
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 10:13 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 14:30 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 15:07 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 22:13 +0000
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 15:49 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 11:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-20 03:47 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 13:21 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-20 08:20 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 09:51 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 02:51 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-21 11:44 +0100
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 12:17 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 13:36 +0200
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 13:15 +0100
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-21 11:04 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-21 08:30 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 13:32 +0200
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-21 12:46 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 07:43 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 16:13 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 20:15 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 20:14 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 16:37 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 15:38 +0200
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 01:02 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 04:57 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 16:11 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 08:46 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 18:33 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 13:44 -0400
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 12:48 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 21:45 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 05:20 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 10:16 -0400
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 08:59 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:04 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 13:59 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 23:01 +0200
Re: widening multiplication Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-08-23 07:42 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 22:12 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 13:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 04:53 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 14:22 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 06:47 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 16:25 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 07:42 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-24 09:10 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-24 02:06 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-23 13:10 -0400
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 16:16 +0100
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 22:02 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 18:14 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 14:27 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-21 05:58 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 19:15 -0400
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 16:48 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-19 23:39 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 15:51 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 15:56 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 16:04 -0700
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-19 18:04 -0700
Re: widening multiplication antispam@math.uni.wroc.pl - 2020-08-20 00:13 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 10:06 +0200
Re: widening multiplication Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-08-20 11:26 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 13:25 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 07:41 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 15:08 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 10:29 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 17:41 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 13:34 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 20:21 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 15:16 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 09:32 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-18 11:11 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 22:45 +0200
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-19 20:17 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-19 15:20 -0400
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 20:59 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-19 17:28 -0400
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-19 22:43 +0100
Re: widening multiplication Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-08-19 21:38 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 21:47 +0200
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-20 12:24 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-20 08:14 -0400
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-20 14:20 +0200
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-20 10:39 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 15:55 -0400
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-22 12:30 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-22 05:09 -0700
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-22 17:15 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:06 +0200
Re: widening multiplication Richard Harnden <richard.nospam@gmail.com> - 2020-08-22 19:06 +0100
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-22 20:28 +0200
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-23 01:36 +0200
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-22 18:15 -0700
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-23 11:16 +0200
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-23 21:05 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 12:45 -0700
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-22 11:47 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 10:21 -0400
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-22 16:18 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:16 +0200
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-23 04:38 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-23 08:22 -0400
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-24 03:00 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-23 23:54 -0400
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-24 06:19 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-24 09:45 -0400
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-24 14:47 +0000
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-24 12:14 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-24 08:40 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-26 18:06 +0000
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-23 17:55 +0200
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-23 17:38 +0100
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 13:15 -0700
Re: widening multiplication rick.c.hodgin@gmail.com - 2020-08-23 08:03 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2020-08-18 06:53 -0700 |
| Message-ID | <chine.bleu-62B5B2.06534218082020@reader.eternal-september.org> |
| In reply to | #153712 |
In article <rhgk8p$p2n$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: > Data isn't lost here - in cases like this "a * b" is clearly defined to > be handled as "int * int -> int". And the conversion from "int" to > "long long" is lossless. Wrong. What matters is the precision the programmer expects. If the programmer is depending on the multiplication to be truncated, suddenly having the compiler throwing that away loses intended functionality. What was the intent of the example? Apparently it wasn't clear. You know something that really pisses of weather modellers? A compiler revision that changes the lowest bit of a computation. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-18 16:14 +0200 |
| Message-ID | <rhgnne$fs3$1@dont-email.me> |
| In reply to | #153717 |
On 18/08/2020 15:53, Siri Cruise wrote: > In article <rhgk8p$p2n$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: > >> Data isn't lost here - in cases like this "a * b" is clearly defined to >> be handled as "int * int -> int". And the conversion from "int" to >> "long long" is lossless. > > Wrong. > > What matters is the precision the programmer expects. No, when implementing the code what matters is what the language (C standards document plus any other relevant documentation) says you get for the source code you wrote. If those documents don't say what the code means (for particular values), it's UB (for those values) - and the compiler can interpret it any way it finds convenient. If a compiler can see that there is likely to be a conflict between what the language says, and what the programmer might /think/ it says, then it can give a warning. > If the > programmer is depending on the multiplication to be truncated, > suddenly having the compiler throwing that away loses intended > functionality. In C, signed overflow is undefined behaviour. If the programmer is depending on the multiplication to be truncated in any given way, they are relying on overflow behaviour - they are not writing C correct portable C code. They might be writing non-portable code that relies on extensions, features or options of a specific compiler - and that's fine, if that is what they are doing. But even in a compiler that guarantees truncation - two's complement wrapping - in signed arithmetic, the code as written asks the compiler to throw away the high half of the result and then sign-extend from 32-bit to 64-bit. > > What was the intent of the example? Apparently it wasn't clear. > Indeed. > > You know something that really pisses of weather modellers? A > compiler revision that changes the lowest bit of a computation. > No one has been talking about anything like that.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2020-08-18 07:24 -0700 |
| Message-ID | <chine.bleu-372279.07240718082020@reader.eternal-september.org> |
| In reply to | #153718 |
In article <rhgnne$fs3$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: > for the source code you wrote. If those documents don't say what the > code means (for particular values), it's UB (for those values) - and the > compiler can interpret it any way it finds convenient. Knowing is better than guessing. Add some functions, int32 imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't provide optimised multiplies can implement the function in vanilla C. The intent is clear, the compiler doesn't have to guess. > > You know something that really pisses of weather modellers? A > > compiler revision that changes the lowest bit of a computation. > > > > No one has been talking about anything like that. You hope. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-18 22:41 +0200 |
| Message-ID | <rhhee3$5r5$1@dont-email.me> |
| In reply to | #153719 |
On 18/08/2020 16:24, Siri Cruise wrote: > In article <rhgnne$fs3$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: > >> for the source code you wrote. If those documents don't say what the >> code means (for particular values), it's UB (for those values) - and the >> compiler can interpret it any way it finds convenient. > > Knowing is better than guessing. Add some functions, int32 > imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and > int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't > provide optimised multiplies can implement the function in > vanilla C. The intent is clear, the compiler doesn't have to > guess. Compilers don't have to guess - plain C has clear rules about how calculations are carried out based on their types. I agree that knowing is better than guessing - it is the programmer that needs to know and not guess. > >>> You know something that really pisses of weather modellers? A >>> compiler revision that changes the lowest bit of a computation. >>> >> >> No one has been talking about anything like that. > > You hope. > I mean no one in this thread. I'm sure weather modellers do so - keeping tight control of all precisions is vital when trying to model a chaotic system. But that is totally and completely unrelated to the point discussed in this thread.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-18 14:24 -0700 |
| Message-ID | <67169d57-8738-406a-b5ad-b6e8265dfcacn@googlegroups.com> |
| In reply to | #153726 |
On Tuesday, 18 August 2020 at 21:41:54 UTC+1, David Brown wrote: > > > Knowing is better than guessing. Add some functions, int32 > > imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and > > int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't > > provide optimised multiplies can implement the function in > > vanilla C. The intent is clear, the compiler doesn't have to > > guess. > Compilers don't have to guess - plain C has clear rules about how > calculations are carried out based on their types. I agree that knowing > is better than guessing - it is the programmer that needs to know and > not guess. > So we have int32_t a, b; int64_t c; c = a * b; The intention is pretty obvious. The programmer shouldn't have to know that behaviour is in fact undefined if the calculation overflows 32 bits, though it likely works as expected on his platform. The language shouldn't insist on that sort of familiarity with the standard for such a basic operation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-08-18 22:54 +0100 |
| Message-ID | <66Y_G.1299121$rLg.691671@fx49.ams4> |
| In reply to | #153728 |
On 18/08/2020 22:24, Malcolm McLean wrote: > On Tuesday, 18 August 2020 at 21:41:54 UTC+1, David Brown wrote: >> >>> Knowing is better than guessing. Add some functions, int32 >>> imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and >>> int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't >>> provide optimised multiplies can implement the function in >>> vanilla C. The intent is clear, the compiler doesn't have to >>> guess. >> Compilers don't have to guess - plain C has clear rules about how >> calculations are carried out based on their types. I agree that knowing >> is better than guessing - it is the programmer that needs to know and >> not guess. >> > So we have > > int32_t a, b; > int64_t c; > > c = a * b; > > The intention is pretty obvious. The programmer shouldn't have to know that > behaviour is in fact undefined if the calculation overflows 32 bits, though it > likely works as expected on his platform. The language shouldn't insist on > that sort of familiarity with the standard for such a basic operation. > It's not that obvious. What /is/ the intention? What should c end up as when a is 2,000,000,000 and b is 1,000,000,000? Should it be 2,000,000,000,000,000,000 or 1321730048? It that's an easy one, then what about these: c = (a+b); c = a+(a*(a*b)); c = a*b + a*b; c = (a ? a+b : (b ? (a*b) : (a-b))); Should those innermost a*b yield a 32- or 64-bit result? What is clear is that in a complex nested expression, the 64-bit-ness of the eventual target, the assignment's LHS, may or may not propagate down into the lowest levels of the expression. It also means that you can take an expression from elsewhere, the a*b here: int32_t d = a*b; and put it somewhere where it will give a different result for the same values of a and b. It means the meaning of a*b depends on context. Far simpler for the person reading or writing the code for a*b to always have a consistent meaning. Namely, int32 * int32 -> int32.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2020-08-18 15:18 -0700 |
| Message-ID | <chine.bleu-C06DD1.15183018082020@reader.eternal-september.org> |
| In reply to | #153728 |
In article <67169d57-8738-406a-b5ad-b6e8265dfcacn@googlegroups.com>, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > So we have > > int32_t a, b; > int64_t c; > > c = a * b; > > The intention is pretty obvious. Then why do two different compilers reportedly have different interpretations? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-18 15:54 -0700 |
| Message-ID | <877dtva7lc.fsf@nosuchdomain.example.com> |
| In reply to | #153732 |
Siri Cruise <chine.bleu@yahoo.com> writes:
> In article
> <67169d57-8738-406a-b5ad-b6e8265dfcacn@googlegroups.com>,
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
>> So we have
>>
>> int32_t a, b;
>> int64_t c;
>>
>> c = a * b;
>>
>> The intention is pretty obvious.
>
> Then why do two different compilers reportedly have different
> interpretations?
As far as I can tell, they don't. With a small test program (whose
behavior is undefined), gcc and lcc-win produce the same result.
The 32-by-32 multiplication yields a 32-bit result which is then
zero-filled (or sign-extended, I suppose) to 64 bits. That's with
lcc-win version 4.1.
But since the behavior is undefined (assuming 32-bit int), it would
be valid for them to yield different results. Strictly speaking
a * b
doesn't express any intent about what to do in case of overflow.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-18 15:38 -0700 |
| Message-ID | <87blj7a8bb.fsf@nosuchdomain.example.com> |
| In reply to | #153728 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 18 August 2020 at 21:41:54 UTC+1, David Brown wrote:
>> > Knowing is better than guessing. Add some functions, int32
>> > imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and
>> > int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't
>> > provide optimised multiplies can implement the function in
>> > vanilla C. The intent is clear, the compiler doesn't have to
>> > guess.
>> Compilers don't have to guess - plain C has clear rules about how
>> calculations are carried out based on their types. I agree that knowing
>> is better than guessing - it is the programmer that needs to know and
>> not guess.
>>
> So we have
>
> int32_t a, b;
> int64_t c;
>
> c = a * b;
>
> The intention is pretty obvious. The programmer shouldn't have to know that
> behaviour is in fact undefined if the calculation overflows 32 bits, though it
> likely works as expected on his platform. The language shouldn't insist on
> that sort of familiarity with the standard for such a basic operation.
Uh huh. So how would you modify the standard to ensure that people who
haven't read it are guaranteed to have their code behave the way the
expect it to? #pragma STDC DWIM, perhaps?
c = a * b doesn't express any intent, as far as the language is
concerned, other than multiplying two int32_t values and storing the
result in an int64_t object. (And the ranks of those types relative to
int can affect the behavior.) And if we replace int by uint, the value
is *required* to be truncated.
If you want to express the intent of a 32-by-32-to-64 multiplication,
you can write:
c = (int64_t)a * b;
or
c = (int64_t)a * (uint64_t)b;
if you want to be a little more explicit.
It is perhaps unfortunate that C doesn't define a 32-by-32-to-64
multiplication operator. It might make sense to define it in a
language that assumes specific sizes, but C doesn't.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-08-19 07:03 +0000 |
| Message-ID | <slrnrjpjll.1pog.grahn+nntp@frailea.sa.invalid> |
| In reply to | #153733 |
On Tue, 2020-08-18, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On Tuesday, 18 August 2020 at 21:41:54 UTC+1, David Brown wrote: >>> > Knowing is better than guessing. Add some functions, int32 >>> > imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and >>> > int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't >>> > provide optimised multiplies can implement the function in >>> > vanilla C. The intent is clear, the compiler doesn't have to >>> > guess. >>> Compilers don't have to guess - plain C has clear rules about how >>> calculations are carried out based on their types. I agree that knowing >>> is better than guessing - it is the programmer that needs to know and >>> not guess. >>> >> So we have >> >> int32_t a, b; >> int64_t c; >> >> c = a * b; >> >> The intention is pretty obvious. The programmer shouldn't have to know that >> behaviour is in fact undefined if the calculation overflows 32 bits, though it >> likely works as expected on his platform. The language shouldn't insist on >> that sort of familiarity with the standard for such a basic operation. > > Uh huh. So how would you modify the standard to ensure that people who > haven't read it are guaranteed to have their code behave the way the > expect it to? #pragma STDC DWIM, perhaps? Exactly. In reality, you /do/ have to know enough at least to /avoid/ this situation. I think the very first books on C that I read in the early 1990s explained it. Personally, what I remember and what is sufficient here is: - The type of c doesn't affect the evaluation of a*b; a*b is evaluated in isolation. - C doesn't go out of its way to widen signed arithmetic beyond int. - The standard solution is to cast a or b. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-19 09:24 +0200 |
| Message-ID | <rhik33$v1l$1@dont-email.me> |
| In reply to | #153728 |
On 18/08/2020 23:24, Malcolm McLean wrote: > On Tuesday, 18 August 2020 at 21:41:54 UTC+1, David Brown wrote: >> >>> Knowing is better than guessing. Add some functions, int32 >>> imul3232 (int32_t,int32), int64_t imul3264 (int32,int32), and >>> int64_t imul6464 (int64_t,int64_t). Compilers that don't or can't >>> provide optimised multiplies can implement the function in >>> vanilla C. The intent is clear, the compiler doesn't have to >>> guess. >> Compilers don't have to guess - plain C has clear rules about how >> calculations are carried out based on their types. I agree that knowing >> is better than guessing - it is the programmer that needs to know and >> not guess. >> > So we have > > int32_t a, b; > int64_t c; > > c = a * b; > > The intention is pretty obvious. No, it is not. If the programmer is well-versed in C, and writing portable C, it means "Multiply a and b as 32-bit signed values giving a signed 32-bit result. I promise the values of a and b will be such that the result does not overflow and fits correctly in the 32-bit result. Then extend the result to a 64-bit signed type, preserving the value." If they are writing C for a compiler that they /know/ has specific defined treatment for signed integer overflow, such as "gcc -fwrapv" (but not, for example, MSVC), then they could mean "Multiply a and b as 32-bit signed values, wrapping if necessary to give signed 32-bit result. Then extend the result to a 64-bit signed type, preserving the value." If the programmer is not proficient in the language, it could mean many things - including (but not necessarily) "Multiply these two 32-bit values. Since the result might not fit in a 32-bit type, put it in a 64-bit type". But it could also be that they want wrapping, or don't expect any overflow. In general, they could simply have made "c" 64-bit because they want to use 64-bit arithmetic later on. Compilers should assume the first meaning (or second, if they define integer overflow behaviour) - they act on what the programmer has actually written, and can't work by guessing what they think the programmer might have meant to write! (But they /can/ issue warnings, if the programmer chooses, based on such guesses.) > The programmer shouldn't have to know that > behaviour is in fact undefined if the calculation overflows 32 bits, though it > likely works as expected on his platform. The language shouldn't insist on > that sort of familiarity with the standard for such a basic operation. > Then the programmer should not be using C. There are other languages where arithmetic and types work in other ways - in C programming, expressions work the way the C language defines them.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-19 02:13 -0700 |
| Message-ID | <1507c5b9-7531-4c59-937a-299c799b9e04n@googlegroups.com> |
| In reply to | #153738 |
On Wednesday, 19 August 2020 at 08:24:28 UTC+1, David Brown wrote: > On 18/08/2020 23:24, Malcolm McLean wrote: > > > The programmer shouldn't have to know that > > behaviour is in fact undefined if the calculation overflows 32 bits, though it > > likely works as expected on his platform. The language shouldn't insist on > > that sort of familiarity with the standard for such a basic operation. > > > Then the programmer should not be using C. There are other languages > where arithmetic and types work in other ways - in C programming, > expressions work the way the C language defines them. > What if the programmer is a Matlab programmer, but he just needs to edit one function written in C, for some reason? What if the reason for writing that Matlab function in C is that it operates on very large matrices and the Matlab code is too slow?
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-08-19 10:43 +0000 |
| Message-ID | <slrnrjq0j0.1pog.grahn+nntp@frailea.sa.invalid> |
| In reply to | #153740 |
On Wed, 2020-08-19, Malcolm McLean wrote: > On Wednesday, 19 August 2020 at 08:24:28 UTC+1, David Brown wrote: >> On 18/08/2020 23:24, Malcolm McLean wrote: >> >> > The programmer shouldn't have to know that behaviour is in fact >> > undefined if the calculation overflows 32 bits, though it likely >> > works as expected on his platform. The language shouldn't insist >> > on that sort of familiarity with the standard for such a basic >> > operation. >> > >> Then the programmer should not be using C. There are other languages >> where arithmetic and types work in other ways - in C programming, >> expressions work the way the C language defines them. >> > What if the programmer is a Matlab programmer, but he just needs to edit > one function written in C, for some reason? Then he or she has to learn enough C to do it properly. Or fail; it's entirely up to the programmer. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-19 12:50 +0200 |
| Message-ID | <rhj066$3ca$1@dont-email.me> |
| In reply to | #153740 |
On 19/08/2020 11:13, Malcolm McLean wrote: > On Wednesday, 19 August 2020 at 08:24:28 UTC+1, David Brown wrote: >> On 18/08/2020 23:24, Malcolm McLean wrote: >> >>> The programmer shouldn't have to know that >>> behaviour is in fact undefined if the calculation overflows 32 bits, though it >>> likely works as expected on his platform. The language shouldn't insist on >>> that sort of familiarity with the standard for such a basic operation. >>> >> Then the programmer should not be using C. There are other languages >> where arithmetic and types work in other ways - in C programming, >> expressions work the way the C language defines them. >> > What if the programmer is a Matlab programmer, but he just needs to edit > one function written in C, for some reason? What if the reason for writing > that Matlab function in C is that it operates on very large matrices and the > Matlab code is too slow? > If the programmer knows how to write C code, that's fine. If not, then he/she should not be messing around with it. It is /that/ simple. If he/she only knows Matlab, then fix the Matlab code and let Matlab generate correct C code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-19 07:30 -0700 |
| Message-ID | <1e9f6e4b-16b9-47a3-9a93-15491731c686n@googlegroups.com> |
| In reply to | #153744 |
On Wednesday, 19 August 2020 at 11:50:58 UTC+1, David Brown wrote: > On 19/08/2020 11:13, Malcolm McLean wrote: > > On Wednesday, 19 August 2020 at 08:24:28 UTC+1, David Brown wrote: > >> On 18/08/2020 23:24, Malcolm McLean wrote: > >> > >>> The programmer shouldn't have to know that > >>> behaviour is in fact undefined if the calculation overflows 32 bits, though it > >>> likely works as expected on his platform. The language shouldn't insist on > >>> that sort of familiarity with the standard for such a basic operation. > >>> > >> Then the programmer should not be using C. There are other languages > >> where arithmetic and types work in other ways - in C programming, > >> expressions work the way the C language defines them. > >> > > What if the programmer is a Matlab programmer, but he just needs to edit > > one function written in C, for some reason? What if the reason for writing > > that Matlab function in C is that it operates on very large matrices and the > > Matlab code is too slow? > > > If the programmer knows how to write C code, that's fine. If not, then > he/she should not be messing around with it. It is /that/ simple. If > he/she only knows Matlab, then fix the Matlab code and let Matlab > generate correct C code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-19 07:44 -0700 |
| Message-ID | <805c6977-d951-4c25-86d6-6539b2716a22n@googlegroups.com> |
| In reply to | #153744 |
On Wednesday, 19 August 2020 at 11:50:58 UTC+1, David Brown wrote: > > If the programmer knows how to write C code, that's fine. If not, then > he/she should not be messing around with it. It is /that/ simple. If > he/she only knows Matlab, then fix the Matlab code and let Matlab > generate correct C code. > No it's not /that/ simple. A Matlab programmer has likely had some exposure to C, but often hardly uses it. Matlab provides an interface for calling functions written in C. Typically very processor-intensive functions that are slow on Matlab, these situations are rare and represent a failure on the part of Matlab, but they occur, which is one reason why the C interface is provided. Now there's a need for such function, or one needs fixing. Who's going to do it?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-19 17:35 +0200 |
| Message-ID | <rhjgrr$d08$1@dont-email.me> |
| In reply to | #153754 |
On 19/08/2020 16:44, Malcolm McLean wrote: > On Wednesday, 19 August 2020 at 11:50:58 UTC+1, David Brown wrote: >> >> If the programmer knows how to write C code, that's fine. If not, then >> he/she should not be messing around with it. It is /that/ simple. If >> he/she only knows Matlab, then fix the Matlab code and let Matlab >> generate correct C code. >> > No it's not /that/ simple. Yes, it /is/. A C compiler is written to cater for C programmers. If people can't program in C but want to try using it, that's fine - but neither the language nor (most) compilers are designed for people who don't know what they are doing. Nor should they be. There are plenty of languages designed to be suitable for people who are relatively new to programming or to the language. C is not one of those languages. > A Matlab programmer has likely had some > exposure to C, but often hardly uses it. Matlab provides an interface for > calling functions written in C. Typically very processor-intensive > functions that are slow on Matlab, these situations are rare and represent > a failure on the part of Matlab, but they occur, which is one reason why > the C interface is provided. > I don't care. The C language is designed for C programmers. C compilers are designed for C programmers. Do you think the language and/or major compilers should change to be worse (inconsistent, unpredictable, and less efficient) to the detriment of the vast majority of users, just to suit a few numpties who can do a little bit of maths programming in a high level tool, and think that makes them qualified to do high-efficiency C programming? > Now there's a need for such function, or one needs fixing. Who's going to do it? > If this is in a professional context, let professional /C/ programmers handle it. There is no shortage of qualified talent. If it is for amateurs, let them try things out - and ask questions here, or on Stack Overflow, or whatever, to get help. Making weird and inconsistent changes to the language in one or two compilers is certainly /not/ the answer, no matter what the question.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-19 10:13 -0700 |
| Message-ID | <87364ia79o.fsf@nosuchdomain.example.com> |
| In reply to | #153740 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 19 August 2020 at 08:24:28 UTC+1, David Brown wrote:
>> On 18/08/2020 23:24, Malcolm McLean wrote:
>>
>> > The programmer shouldn't have to know that
>> > behaviour is in fact undefined if the calculation overflows 32 bits, though it
>> > likely works as expected on his platform. The language shouldn't insist on
>> > that sort of familiarity with the standard for such a basic operation.
>> >
>> Then the programmer should not be using C. There are other languages
>> where arithmetic and types work in other ways - in C programming,
>> expressions work the way the C language defines them.
>>
> What if the programmer is a Matlab programmer, but he just needs to edit
> one function written in C, for some reason? What if the reason for writing
> that Matlab function in C is that it operates on very large matrices and the
> Matlab code is too slow?
What if? Why don't you tell us? What changes would you make to the
C language to accomodate Matlab programmers?
My answer: A Matlab programmer who doesn't know C is likely to make
mistakes while writing C. Yes, it can be a problem. What's your
solution?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-19 14:30 -0700 |
| Message-ID | <8f076f92-55bc-4c19-b504-7e80c8878cb2n@googlegroups.com> |
| In reply to | #153760 |
On Wednesday, 19 August 2020 at 18:13:43 UTC+1, Keith Thompson wrote: > > What if? Why don't you tell us? What changes would you make to the > C language to accomodate Matlab programmers? > > My answer: A Matlab programmer who doesn't know C is likely to make > mistakes while writing C. Yes, it can be a problem. What's your > solution? > In this case, it's quite simple. Where we have an assignment statement, arithmetic is carried out in the widest type that appears in that statement. So the Matlab programmer knows that he might be dealing with big matrices, but dimensions can't go above 32 bits. So, int x, y, width; long long index; index = y * width + x; If he's using Jacob's compiler, this will work as expected if the matrix has more than 2 billion entries. If he moves his Matlab platform to use another compiler, the code will compile without warning, it will appear to work when he tests it with small matrices, then it will fail when the matrix gets very large. Terrible, terrible.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-19 15:07 -0700 |
| Message-ID | <87o8n68f37.fsf@nosuchdomain.example.com> |
| In reply to | #153772 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 19 August 2020 at 18:13:43 UTC+1, Keith Thompson wrote:
>> What if? Why don't you tell us? What changes would you make to the
>> C language to accomodate Matlab programmers?
>>
>> My answer: A Matlab programmer who doesn't know C is likely to make
>> mistakes while writing C. Yes, it can be a problem. What's your
>> solution?
>>
> In this case, it's quite simple. Where we have an assignment statement,
> arithmetic is carried out in the widest type that appears in that statement.
That definitely has the potential to break existing code. A contrived
example:
#include <stdio.h>
#include <stdint.h>
int main(void) {
uint32_t a = UINT32_MAX;
uint32_t b = 1;
uint64_t c = a + b;
printf("c = %llu\n", (unsigned long long)c);
}
This has well defined behavior and prints "c = 0". With your proposed
change, it would print "c = 4294967296".
The current rules, once you learn them, are straightforward: the type of
an expression is determined by the expression itself, not by the context
in which it appears. (The special status of int is admittedly a
complication.) You propose to make the rules more complicated so that
certain cases are more intuitive *for non-C programmers*.
You'd also have to describe the new rules more precisely. (C doesn't
have an "assignment statement".)
Now if I were designing a new language, I'd certainly consider this kind
of thing -- or just requiring conversions to be explicit (I know some
people would hate that). But I wouldn't call it "C".
> So the Matlab programmer knows that he might be dealing with big matrices,
> but dimensions can't go above 32 bits.
>
> So, int x, y, width;
> long long index;
>
> index = y * width + x;
>
> If he's using Jacob's compiler, this will work as expected if the matrix has more
> than 2 billion entries. If he moves his Matlab platform to use another compiler,
> the code will compile without warning, it will appear to work when he tests it
> with small matrices, then it will fail when the matrix gets very large.
>
> Terrible, terrible.
And yet it's already perfectly feasible to write code that works:
index = (long long)y * width + x;
Or maybe define x, y, and width as size_t rather than int.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web