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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-08-19 22:13 +0000 |
| Message-ID | <slrnrjr90e.1pog.grahn+nntp@frailea.sa.invalid> |
| In reply to | #153772 |
On Wed, 2020-08-19, Malcolm McLean wrote: > 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. We'd have to update the standard, assuming this change doesn't have unintended consequences elsewhere in the language (my gut feeling is that it has). Then a number of compilers would have to be updated, then those compilers would have to reach actual programmers and software projects. These programmers would then have to relearn rules established around 50 years ago. And /then/ actual code can be written. And then we'd discover that the Matlab programmer had misunderstood some other part of the C language too. Or, more likely, that she had retired years earlier. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-19 15:49 -0700 |
| Message-ID | <b8745108-a708-400f-9bde-990fbb0fa354n@googlegroups.com> |
| In reply to | #153775 |
On Wednesday, 19 August 2020 at 23:13:43 UTC+1, Jorgen Grahn wrote: > > > 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. > > We'd have to update the standard, assuming this change doesn't have > unintended consequences elsewhere in the language (my gut feeling is > that it has). Then a number of compilers would have to be updated, > then those compilers would have to reach actual programmers and > software projects. These programmers would then have to relearn rules > established around 50 years ago. And /then/ actual code can be > written. > You'd have to update the standard. So an assignment statement like c = a * b would calculate the value with an intermediate width of the widest of a, b, or c, assuming signed integers. That behaviour is already allowed, but it is not mandated. The old form c = (long long) a * b; would still be accepted and work in the same way. > > And then we'd discover that the Matlab programmer had misunderstood > some other part of the C language too. Or, more likely, that she had > retired > Most programming languages work in more or less the same way, and if you know one you can follow along another. And you often have to do that. We don't all live in a world of closely-defined responsibilities with qualified professionals on tap at demand. However there are some gotchas. Ideally, you keep these gotchas to a bare minimum, only the things so deeply rooted tat you can't eliminate them from the language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-20 11:31 +0200 |
| Message-ID | <rhlftv$9uc$1@dont-email.me> |
| In reply to | #153777 |
On 20/08/2020 00:49, Malcolm McLean wrote: > On Wednesday, 19 August 2020 at 23:13:43 UTC+1, Jorgen Grahn wrote: >> >>> 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. >> >> We'd have to update the standard, assuming this change doesn't have >> unintended consequences elsewhere in the language (my gut feeling is >> that it has). Then a number of compilers would have to be updated, >> then those compilers would have to reach actual programmers and >> software projects. These programmers would then have to relearn rules >> established around 50 years ago. And /then/ actual code can be >> written. >> > You'd have to update the standard. > So an assignment statement like c = a * b would calculate the value with an > intermediate width of the widest of a, b, or c, assuming signed integers. That > behaviour is already allowed, but it is not mandated. > The old form > c = (long long) a * b; > would still be accepted and work in the same way. >> >> And then we'd discover that the Matlab programmer had misunderstood >> some other part of the C language too. Or, more likely, that she had >> retired >> > Most programming languages work in more or less the same way, Can you give any examples? There are plenty of languages where integer types expand as needed (such as Python), but the type used for calculations is completely independent of the type used to store the result. I can't think of any programming languages where the type used to store or handle the result of an expression affects the meaning, types or calculation of the expression.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-20 03:47 -0700 |
| Message-ID | <dbfe58bf-20c8-404a-ad42-04f7684ebe17n@googlegroups.com> |
| In reply to | #153788 |
On Thursday, 20 August 2020 at 10:31:53 UTC+1, David Brown wrote: > On 20/08/2020 00:49, Malcolm McLean wrote: > > > Most programming languages work in more or less the same way, > Can you give any examples? There are plenty of languages where integer > types expand as needed (such as Python), but the type used for > calculations is completely independent of the type used to store the result. > > I can't think of any programming languages where the type used to store > or handle the result of an expression affects the meaning, types or > calculation of the expression. > Restore the snip and you'll see that's not wha I am saying.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-20 13:21 +0200 |
| Message-ID | <rhlmcl$nir$1@dont-email.me> |
| In reply to | #153790 |
On 20/08/2020 12:47, Malcolm McLean wrote: > On Thursday, 20 August 2020 at 10:31:53 UTC+1, David Brown wrote: >> On 20/08/2020 00:49, Malcolm McLean wrote: >> >>> Most programming languages work in more or less the same way, >> Can you give any examples? There are plenty of languages where integer >> types expand as needed (such as Python), but the type used for >> calculations is completely independent of the type used to store the result. >> >> I can't think of any programming languages where the type used to store >> or handle the result of an expression affects the meaning, types or >> calculation of the expression. >> > Restore the snip and you'll see that's not wha I am saying. > I've read it again. You said that in the assignment statement (a nonsensical term in the context of C, but relevant to some other languages) "c = a * b", the way the expression "a * b" is evaluated depends on the type of "c". Is that a misunderstanding of what you have been writing? If so, please try to explain again. But if that /is/ what you are saying, then please give some examples of a programming language that works the way you want. After all, you claim it applies to "most programming languages". Certainly if you give some examples of other languages, we will be closer to understanding what you are trying to say.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-20 08:20 -0400 |
| Message-ID | <1Ut%G.293556$RF4.155976@fx43.iad> |
| In reply to | #153791 |
On 8/20/20 7:21 AM, David Brown wrote: > On 20/08/2020 12:47, Malcolm McLean wrote: >> On Thursday, 20 August 2020 at 10:31:53 UTC+1, David Brown wrote: >>> On 20/08/2020 00:49, Malcolm McLean wrote: >>> >>>> Most programming languages work in more or less the same way, >>> Can you give any examples? There are plenty of languages where integer >>> types expand as needed (such as Python), but the type used for >>> calculations is completely independent of the type used to store the result. >>> >>> I can't think of any programming languages where the type used to store >>> or handle the result of an expression affects the meaning, types or >>> calculation of the expression. >>> >> Restore the snip and you'll see that's not wha I am saying. >> > > I've read it again. > > You said that in the assignment statement (a nonsensical term in the > context of C, but relevant to some other languages) "c = a * b", the way > the expression "a * b" is evaluated depends on the type of "c". > > Is that a misunderstanding of what you have been writing? > > If so, please try to explain again. > > But if that /is/ what you are saying, then please give some examples of > a programming language that works the way you want. After all, you > claim it applies to "most programming languages". Certainly if you give > some examples of other languages, we will be closer to understanding > what you are trying to say. > One 'programming' language which works sort of like this is Verilog, where an expression is examined for the widest element, and the whole expression is evaluated to that precision. It makes a lot more sense in this environment, as it isn't uncommon to do things like add an 7-bit number to another 7-bit number and want to put it into an 8-bit result, and thus do the addition in 8-bits.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-21 09:51 +0200 |
| Message-ID | <rhnues$m6b$1@dont-email.me> |
| In reply to | #153794 |
On 20/08/2020 14:20, Richard Damon wrote: > On 8/20/20 7:21 AM, David Brown wrote: >> On 20/08/2020 12:47, Malcolm McLean wrote: >>> On Thursday, 20 August 2020 at 10:31:53 UTC+1, David Brown wrote: >>>> On 20/08/2020 00:49, Malcolm McLean wrote: >>>> >>>>> Most programming languages work in more or less the same way, >>>> Can you give any examples? There are plenty of languages where integer >>>> types expand as needed (such as Python), but the type used for >>>> calculations is completely independent of the type used to store the result. >>>> >>>> I can't think of any programming languages where the type used to store >>>> or handle the result of an expression affects the meaning, types or >>>> calculation of the expression. >>>> >>> Restore the snip and you'll see that's not wha I am saying. >>> >> >> I've read it again. >> >> You said that in the assignment statement (a nonsensical term in the >> context of C, but relevant to some other languages) "c = a * b", the way >> the expression "a * b" is evaluated depends on the type of "c". >> >> Is that a misunderstanding of what you have been writing? >> >> If so, please try to explain again. >> >> But if that /is/ what you are saying, then please give some examples of >> a programming language that works the way you want. After all, you >> claim it applies to "most programming languages". Certainly if you give >> some examples of other languages, we will be closer to understanding >> what you are trying to say. >> > > One 'programming' language which works sort of like this is Verilog, > where an expression is examined for the widest element, and the whole > expression is evaluated to that precision. > I've done some Verilog programming, but it was limited and a long time ago, so I can't remember the details. And usually I had the sizes specified explicitly anyway. > It makes a lot more sense in this environment, as it isn't uncommon to > do things like add an 7-bit number to another 7-bit number and want to > put it into an 8-bit result, and thus do the addition in 8-bits. > Fair enough. (I have nothing against this concept in itself - I merely disagree that it would be a good idea to squeeze it into C, and I want Malcolm to justify claiming it applies to "most programming languages".)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-21 02:51 -0700 |
| Message-ID | <6bd1b70e-e118-4570-91dd-01cbceb8fb15n@googlegroups.com> |
| In reply to | #153799 |
On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: > > (I have nothing against this concept in itself - I merely disagree that > it would be a good idea to squeeze it into C, and I want Malcolm to > justify claiming it applies to "most programming languages".) > Restore the snip and you'll see that that's not quite what I was saying.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-21 11:44 +0100 |
| Message-ID | <87k0xs6zy7.fsf@bsb.me.uk> |
| In reply to | #153804 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >> >> (I have nothing against this concept in itself - I merely disagree that >> it would be a good idea to squeeze it into C, and I want Malcolm to >> justify claiming it applies to "most programming languages".) I've restored the quote because the various edits have not done any favours to the discussion. > Restore the snip and you'll see that that's not quite what I was > saying. What you said was this: "Most programming languages work in more or less the same way, and if you know one you can follow along another. And you often have to do that. [...] Ideally, you keep these gotchas to a bare minimum, only the things so deeply rooted [that] you can't eliminate them from the language." And (barring the usual trouble of about talking about "most" of anything as diverse as programming languages) you are essentially correct. But your words argue against the point you made about the code -- namely that not using a wide multiplication will be a "gotcha", tripping up programmers who know other languages but not C. A totally unscientific survey of the inside of my head suggests that most languages determine the result of arithmetic expressions from the types for their operands and not from any wider context. So, despite some snipping, David Brown still has a point. What is the evidence (specifically in terms of other programming languages) that an experienced programmer would not immediately suspect a problem in the code being discussed? Presumably you where surprised by what C does because your experience differs from mine. What are the languages that formed your expectations of that code? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-08-21 12:17 +0100 |
| Message-ID | <93O%G.1158422$QC4.953247@fx19.am4> |
| In reply to | #153805 |
On 21/08/2020 11:44, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote:
>>>
>>> (I have nothing against this concept in itself - I merely disagree that
>>> it would be a good idea to squeeze it into C, and I want Malcolm to
>>> justify claiming it applies to "most programming languages".)
>
> I've restored the quote because the various edits have not done any
> favours to the discussion.
>
>> Restore the snip and you'll see that that's not quite what I was
>> saying.
>
> What you said was this:
>
> "Most programming languages work in more or less the same way, and if
> you know one you can follow along another. And you often have to do
> that. [...] Ideally, you keep these gotchas to a bare minimum, only
> the things so deeply rooted [that] you can't eliminate them from the
> language."
>
> And (barring the usual trouble of about talking about "most" of anything
> as diverse as programming languages) you are essentially correct. But
> your words argue against the point you made about the code -- namely
> that not using a wide multiplication will be a "gotcha", tripping up
> programmers who know other languages but not C. A totally unscientific
> survey of the inside of my head suggests that most languages determine
> the result of arithmetic expressions from the types for their operands
> and not from any wider context.
In my dynamic language, I cannot use a wider context, because either the
types are not known, or there is no type such as in z:=x*y, because z
has not yet been assigned anything. In:
....(x*y)....
the types of x and y are only looked at when it is about to do the
multiplication, and then it is purely based on those two types, nothing
else.
Treating such terms in isolation is the easiest way to do it, and it
makes things compatible with a static language as you usually want
expressions to work the same way.
(My language does not auto-widen results as some do, such as Python
where numbers become bigints; i64*i64 yields i64, not i128 or a bigint.
So static/dynamic are more compatible than most.
They also use the x64 multiply that does i64*i64->i64, not the less
flexible and less efficient i64*64->i128, so that conflict, trying not
to waste the extra precision, doesn't arise.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-21 13:36 +0200 |
| Message-ID | <rhobk2$2np$1@dont-email.me> |
| In reply to | #153807 |
On 21/08/2020 13:17, Bart wrote: > On 21/08/2020 11:44, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >>>> >>>> (I have nothing against this concept in itself - I merely disagree that >>>> it would be a good idea to squeeze it into C, and I want Malcolm to >>>> justify claiming it applies to "most programming languages".) >> >> I've restored the quote because the various edits have not done any >> favours to the discussion. >> >>> Restore the snip and you'll see that that's not quite what I was >>> saying. >> >> What you said was this: >> >> "Most programming languages work in more or less the same way, and if >> you know one you can follow along another. And you often have to do >> that. [...] Ideally, you keep these gotchas to a bare minimum, only >> the things so deeply rooted [that] you can't eliminate them from the >> language." >> >> And (barring the usual trouble of about talking about "most" of anything >> as diverse as programming languages) you are essentially correct. But >> your words argue against the point you made about the code -- namely >> that not using a wide multiplication will be a "gotcha", tripping up >> programmers who know other languages but not C. A totally unscientific >> survey of the inside of my head suggests that most languages determine >> the result of arithmetic expressions from the types for their operands >> and not from any wider context. > > In my dynamic language, I cannot use a wider context, because either the > types are not known, or there is no type such as in z:=x*y, because z > has not yet been assigned anything. In: > > ....(x*y).... > > the types of x and y are only looked at when it is about to do the > multiplication, and then it is purely based on those two types, nothing > else. > That's common in many languages (IME), especially in dynamic languages. > Treating such terms in isolation is the easiest way to do it, and it > makes things compatible with a static language as you usually want > expressions to work the same way. Yes. > > (My language does not auto-widen results as some do, such as Python > where numbers become bigints; i64*i64 yields i64, not i128 or a bigint. > So static/dynamic are more compatible than most. > > They also use the x64 multiply that does i64*i64->i64, not the less > flexible and less efficient i64*64->i128, so that conflict, trying not > to waste the extra precision, doesn't arise.) Fair enough. For many purposes on modern systems, there are advantages in simply saying "all integers for calculations are 64-bit". You might want smaller types for efficient storage in arrays, or for foreign function interfaces. Of course, it is exactly that kind of thinking that got us all the oddities of "int" in C...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-08-21 13:15 +0100 |
| Message-ID | <aWO%G.1104153$e15.483411@fx24.am4> |
| In reply to | #153809 |
On 21/08/2020 12:36, David Brown wrote: > On 21/08/2020 13:17, Bart wrote: >> They also use the x64 multiply that does i64*i64->i64, not the less >> flexible and less efficient i64*64->i128, so that conflict, trying not >> to waste the extra precision, doesn't arise.) > > Fair enough. For many purposes on modern systems, there are advantages > in simply saying "all integers for calculations are 64-bit". You might > want smaller types for efficient storage in arrays, or for foreign > function interfaces. There's no conflict here. You can have a default int type of 64 bits, and specify that all terms are widened to at least 64 bits for calculations, and yet still have 8, 16 and 32-bit types for use inside arrays, structs and as pointer targets. (Or, if you want, as standalone variables or parameter types.) Pretty much as C does, except it uses 32 bits as the base width (ignoring the arcane rules on mixing signed and unsigned).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-21 11:04 -0700 |
| Message-ID | <87blj398p6.fsf@nosuchdomain.example.com> |
| In reply to | #153812 |
Bart <bc@freeuk.com> writes:
> On 21/08/2020 12:36, David Brown wrote:
>> On 21/08/2020 13:17, Bart wrote:
>>> They also use the x64 multiply that does i64*i64->i64, not the less
>>> flexible and less efficient i64*64->i128, so that conflict, trying not
>>> to waste the extra precision, doesn't arise.)
>>
>> Fair enough. For many purposes on modern systems, there are advantages
>> in simply saying "all integers for calculations are 64-bit". You might
>> want smaller types for efficient storage in arrays, or for foreign
>> function interfaces.
>
> There's no conflict here.
>
> You can have a default int type of 64 bits, and specify that all terms
> are widened to at least 64 bits for calculations, and yet still have
> 8, 16 and 32-bit types for use inside arrays, structs and as pointer
> targets. (Or, if you want, as standalone variables or parameter
> types.)
>
> Pretty much as C does, except it uses 32 bits as the base width
> (ignoring the arcane rules on mixing signed and unsigned).
Or whatever size int happens to be for a given implementation.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-21 08:30 -0400 |
| Message-ID | <Z7P%G.103386$bQ4.78056@fx04.iad> |
| In reply to | #153809 |
On 8/21/20 7:36 AM, David Brown wrote: > Fair enough. For many purposes on modern systems, there are advantages > in simply saying "all integers for calculations are 64-bit". You might > want smaller types for efficient storage in arrays, or for foreign > function interfaces. > > Of course, it is exactly that kind of thinking that got us all the > oddities of "int" in C... Yes, that is basically the sort of rule that got us to where we are, but rather than choosing the 'biggest' size available, it was just A big size that was efficient, int. Automatically promote everything to int, so we don't get unexpected overflow from arithmetic on values squeezed into smaller boxes, but also don't force overly slow operations by using bigger types without being told. It was assumed that by the definition of int, operations on smaller types would be no faster, but bigger types likely would be slower. This fits well into the C paradigm of trust the programmer, give him tools to make fairly efficient code by default, and the ability to use extra power where needed. Note also, that this paradigm harks back to days when computational power was expensive, and asking to spend asking the programmer to spend a bit of effort to get a more efficient program made sense. This is opposed to the more current concept that you make a language designed to make it easier to write a program that will be correct, but maybe a bit slow, but that doesn't matter as computers are fast (and the details about what makes a program slow get more complicated).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-21 13:32 +0200 |
| Message-ID | <rhobcs$1f1$1@dont-email.me> |
| In reply to | #153805 |
On 21/08/2020 12:44, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >>> >>> (I have nothing against this concept in itself - I merely disagree that >>> it would be a good idea to squeeze it into C, and I want Malcolm to >>> justify claiming it applies to "most programming languages".) > > I've restored the quote because the various edits have not done any > favours to the discussion. > >> Restore the snip and you'll see that that's not quite what I was >> saying. > > What you said was this: > > "Most programming languages work in more or less the same way, and if > you know one you can follow along another. And you often have to do > that. [...] Ideally, you keep these gotchas to a bare minimum, only > the things so deeply rooted [that] you can't eliminate them from the > language." > > And (barring the usual trouble of about talking about "most" of anything > as diverse as programming languages) you are essentially correct. But > your words argue against the point you made about the code -- namely > that not using a wide multiplication will be a "gotcha", tripping up > programmers who know other languages but not C. A totally unscientific > survey of the inside of my head suggests that most languages determine > the result of arithmetic expressions from the types for their operands > and not from any wider context. You mean that what Malcolm had been trying (poorly, IMHO) to say was that most programming languages work the way C works here, and that this is a good thing because it reduces the gotcha's and makes it easier to transfer knowledge from one language to another? If so, then I too agree (with the same proviso about "most languages"). But it is at odds with what he was promoting earlier, namely that "c = a * b;" should take the type of "c" into account. I must admit that it didn't occur to me that he would be countering his own proposal in this way. I'll leave it to Malcolm to try to give a better explanation of what he actually meant, or to make it clear that he has changed his mind (there's nothing wrong with doing that!). > > So, despite some snipping, David Brown still has a point. What is the > evidence (specifically in terms of other programming languages) that an > experienced programmer would not immediately suspect a problem in the > code being discussed? Presumably you where surprised by what C does > because your experience differs from mine. What are the languages that > formed your expectations of that code? >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-21 12:46 +0100 |
| Message-ID | <87blj46x2c.fsf@bsb.me.uk> |
| In reply to | #153808 |
David Brown <david.brown@hesbynett.no> writes: > On 21/08/2020 12:44, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >>>> >>>> (I have nothing against this concept in itself - I merely disagree that >>>> it would be a good idea to squeeze it into C, and I want Malcolm to >>>> justify claiming it applies to "most programming languages".) >> >> I've restored the quote because the various edits have not done any >> favours to the discussion. >> >>> Restore the snip and you'll see that that's not quite what I was >>> saying. >> >> What you said was this: >> >> "Most programming languages work in more or less the same way, and if >> you know one you can follow along another. And you often have to do >> that. [...] Ideally, you keep these gotchas to a bare minimum, only >> the things so deeply rooted [that] you can't eliminate them from the >> language." >> >> And (barring the usual trouble of about talking about "most" of anything >> as diverse as programming languages) you are essentially correct. But >> your words argue against the point you made about the code -- namely >> that not using a wide multiplication will be a "gotcha", tripping up >> programmers who know other languages but not C. A totally unscientific >> survey of the inside of my head suggests that most languages determine >> the result of arithmetic expressions from the types for their operands >> and not from any wider context. > > You mean that what Malcolm had been trying (poorly, IMHO) to say was > that most programming languages work the way C works here, and that this > is a good thing because it reduces the gotcha's and makes it easier to > transfer knowledge from one language to another? Not quite. I think he was saying that assuming an unknown language is roughly like the others one has come across is both common and reasonable. But I don't think he intended to include C's common arithmetic type rule in that assessment, but, as you say, let's wait and see. > If so, then I too > agree (with the same proviso about "most languages"). But it is at odds > with what he was promoting earlier, namely that "c = a * b;" should take > the type of "c" into account. I must admit that it didn't occur to me > that he would be countering his own proposal in this way. It may be that his specific experience has given a different impression of what is the norm. > I'll leave it to Malcolm to try to give a better explanation of what he > actually meant, or to make it clear that he has changed his mind > (there's nothing wrong with doing that!). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-21 07:43 -0700 |
| Message-ID | <f8ac5eff-a68f-498d-a983-992c880f201fn@googlegroups.com> |
| In reply to | #153805 |
On Friday, 21 August 2020 at 11:45:31 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: > >> > >> (I have nothing against this concept in itself - I merely disagree that > >> it would be a good idea to squeeze it into C, and I want Malcolm to > >> justify claiming it applies to "most programming languages".) > I've restored the quote because the various edits have not done any > favours to the discussion. > > Restore the snip and you'll see that that's not quite what I was > > saying. > What you said was this: > "Most programming languages work in more or less the same way, and if > you know one you can follow along another. And you often have to do > that. [...] Ideally, you keep these gotchas to a bare minimum, only > the things so deeply rooted [that] you can't eliminate them from the > language." > > And (barring the usual trouble of about talking about "most" of anything > as diverse as programming languages) you are essentially correct. But > your words argue against the point you made about the code -- namely > that not using a wide multiplication will be a "gotcha", tripping up > programmers who know other languages but not C. A totally unscientific > survey of the inside of my head suggests that most languages determine > the result of arithmetic expressions from the types for their operands > and not from any wider context. > > So, despite some snipping, David Brown still has a point. What is the > evidence (specifically in terms of other programming languages) that an > experienced programmer would not immediately suspect a problem in the > code being discussed? Presumably you where surprised by what C does > because your experience differs from mine. What are the languages that > formed your expectations of that code? > The line index = y * width + x could appear in almost any procedural programming language with essentially the same meaning. C has a "gotcha" that, if y and width are ints, and "y * width" overflows the value of an int, the result has undefined behaviour, even if index is wide enough to hold the result. Now most languages don't have this gotcha. y * width might overflow the maximum size of an integer, but likely there is only one integer type, so the problem is insoluble (and it's probably impossible to create an array that can't be indexed by an integer). Other languages just have "scalar" types where integers are represented by what in C are "doubles", and others have dynamic typing so it's impossible to overflow an integer without exceeding the capacity of the computer's memory. A few might have a rule that a whole expression is always evaluated according to its widest component type. The fix index = (long long) y * width + x; is not intuitive, and you wouldn't realise that this was the problem unless you knew C or a relative with the same behaviour pretty well.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-08-21 16:13 +0100 |
| Message-ID | <HwR%G.1072461$j95.975713@fx14.am4> |
| In reply to | #153815 |
On 21/08/2020 15:43, Malcolm McLean wrote:
> On Friday, 21 August 2020 at 11:45:31 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote:
>>>>
>>>> (I have nothing against this concept in itself - I merely disagree that
>>>> it would be a good idea to squeeze it into C, and I want Malcolm to
>>>> justify claiming it applies to "most programming languages".)
>> I've restored the quote because the various edits have not done any
>> favours to the discussion.
>>> Restore the snip and you'll see that that's not quite what I was
>>> saying.
>> What you said was this:
>> "Most programming languages work in more or less the same way, and if
>> you know one you can follow along another. And you often have to do
>> that. [...] Ideally, you keep these gotchas to a bare minimum, only
>> the things so deeply rooted [that] you can't eliminate them from the
>> language."
>>
>> And (barring the usual trouble of about talking about "most" of anything
>> as diverse as programming languages) you are essentially correct. But
>> your words argue against the point you made about the code -- namely
>> that not using a wide multiplication will be a "gotcha", tripping up
>> programmers who know other languages but not C. A totally unscientific
>> survey of the inside of my head suggests that most languages determine
>> the result of arithmetic expressions from the types for their operands
>> and not from any wider context.
>>
>> So, despite some snipping, David Brown still has a point. What is the
>> evidence (specifically in terms of other programming languages) that an
>> experienced programmer would not immediately suspect a problem in the
>> code being discussed? Presumably you where surprised by what C does
>> because your experience differs from mine. What are the languages that
>> formed your expectations of that code?
>>
> The line
>
> index = y * width + x
>
> could appear in almost any procedural programming language with
> essentially the same meaning. C has a "gotcha" that, if y and width are ints,
> and "y * width" overflows the value of an int, the result has undefined behaviour,
> even if index is wide enough to hold the result.
>
> Now most languages don't have this gotcha. y * width might overflow the
> maximum size of an integer, but likely there is only one integer type, so
> the problem is insoluble (and it's probably impossible to create an array
> that can't be indexed by an integer). Other languages just have "scalar" types
> where integers are represented by what in C are "doubles", and others
> have dynamic typing so it's impossible to overflow an integer without
> exceeding the capacity of the computer's memory. A few might have a rule
> that a whole expression is always evaluated according to its widest
> component type.
Rust doesn't allow mixed widths. You have to write index = x*y, where
index is i64 and x,y are i32, as:
index = (x as i64)*(y as i64)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-21 20:15 +0200 |
| Message-ID | <rhp2vs$mi0$2@dont-email.me> |
| In reply to | #153816 |
On 21/08/2020 17:13, Bart wrote: > Rust doesn't allow mixed widths. You have to write index = x*y, where > index is i64 and x,y are i32, as: > > index = (x as i64)*(y as i64) That's a little wordy for some people's tastes, but being forced to be explicit can reduce the risk of some kinds of mistakes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-21 20:14 +0200 |
| Message-ID | <rhp2td$mi0$1@dont-email.me> |
| In reply to | #153815 |
On 21/08/2020 16:43, Malcolm McLean wrote: > On Friday, 21 August 2020 at 11:45:31 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >>>> >>>> (I have nothing against this concept in itself - I merely disagree that >>>> it would be a good idea to squeeze it into C, and I want Malcolm to >>>> justify claiming it applies to "most programming languages".) >> I've restored the quote because the various edits have not done any >> favours to the discussion. >>> Restore the snip and you'll see that that's not quite what I was >>> saying. >> What you said was this: >> "Most programming languages work in more or less the same way, and if >> you know one you can follow along another. And you often have to do >> that. [...] Ideally, you keep these gotchas to a bare minimum, only >> the things so deeply rooted [that] you can't eliminate them from the >> language." >> >> And (barring the usual trouble of about talking about "most" of anything >> as diverse as programming languages) you are essentially correct. But >> your words argue against the point you made about the code -- namely >> that not using a wide multiplication will be a "gotcha", tripping up >> programmers who know other languages but not C. A totally unscientific >> survey of the inside of my head suggests that most languages determine >> the result of arithmetic expressions from the types for their operands >> and not from any wider context. >> >> So, despite some snipping, David Brown still has a point. What is the >> evidence (specifically in terms of other programming languages) that an >> experienced programmer would not immediately suspect a problem in the >> code being discussed? Presumably you where surprised by what C does >> because your experience differs from mine. What are the languages that >> formed your expectations of that code? >> > The line > > index = y * width + x > > could appear in almost any procedural programming language with > essentially the same meaning. C has a "gotcha" that, if y and width are ints, > and "y * width" overflows the value of an int, the result has undefined behaviour, > even if index is wide enough to hold the result. Programming languages fall into, I would say, five categories here. 1. Languages like Python have automatically expanding integer types that never overflow. No overflow, no problem. You might also put languages with all integer arithmetic done as 64-bit in this group, on the basis that overflows are highly unrealistic. 2. Languages like C, Pascal, Fortran, unchecked Ada, etc., have undefined behaviour - they assume overflow doesn't happen. (This can allow some optimisation.) Clearly, things go horribly wrong if overflow happens. 3. Languages like Java, gcc -fwrapv, etc., have defined wrapping behaviour for their integers. If overflow happens, things go horribly wrong - and the compiler and tools can't even help you with run-time checks (unlike for C). 4. Languages like checked (default) Ada, gcc -ftrapv, etc., throw an error on overflow. Things still go horribly wrong and your program doesn't work, but at least you /know/ things have gone wrong and where it happened. 5. Languages like Verilog (thanks to Richard for giving an example that you failed to provide) where the type for the calculation is affected by the type of the result. /If/ you've made sure that type is big enough, there's no overflow and no problem. (Otherwise you get wrapping and disaster.) I fail to see how C has a particular "gotcha" here. > > Now most languages don't have this gotcha. I beg to differ. But maybe you can provide a list of languages to back up your "most languages" claim. > y * width might overflow the > maximum size of an integer, but likely there is only one integer type, so > the problem is insoluble (and it's probably impossible to create an array > that can't be indexed by an integer). Other languages just have "scalar" types > where integers are represented by what in C are "doubles", and others > have dynamic typing so it's impossible to overflow an integer without > exceeding the capacity of the computer's memory. A few might have a rule > that a whole expression is always evaluated according to its widest > component type. > > The fix > index = (long long) y * width + x; > > is not intuitive, and you wouldn't realise that this was the problem unless you > knew C or a relative with the same behaviour pretty well. > Whoever suggested that C was "intuitive" ? A few people describe their own favourite language as "intuitive", but generally they are wrong. C has its rules - they are fairly straight-forward and consistent here (though like most C programmers, I don't find them perfect - different C programmers will of course disagree about what they'd have preferred). If you want to program in C, learn those rules. If you don't learn them, don't be surprised if you make mistakes.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web