Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98113 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2016-12-05 19:57 -0600 |
| Last post | 2016-12-06 12:06 +0800 |
| Articles | 20 on this page of 131 — 25 participants |
Back to article view | Back to comp.lang.c
"Let’s Stop Bashing C" Lynn McGuire <lynnmcguire5@gmail.com> - 2016-12-05 19:57 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 02:34 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 00:13 -0600
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 23:15 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 21:16 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 11:54 +0000
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 12:07 +0000
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 12:25 +0000
Re: "Let’s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-06 14:07 +0100
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 13:40 +0000
Re: "Let’s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 19:40 +0100
Re: "Lete2��s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 13:55 -0500
Re: "Lete2��s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:13 +0000
Re: "Lete2��s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 11:51 -0800
Re: "Lete2��s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 12:22 -0800
Re: "Lete2��s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 20:16 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 11:20 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 22:15 +0100
Re: "Lete2�™s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 16:49 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:24 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:07 +0100
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-07 22:04 +0100
Re: micro-architectural details jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 23:44 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-07 23:02 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-07 15:28 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 21:36 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 12:56 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:03 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:21 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:36 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-08 21:59 +0000
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:25 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:34 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:59 +0100
Re: micro-architectural details Melzzzzz <mel@zzzzz.com> - 2016-12-09 00:18 +0100
Re: micro-architectural details fir <profesor.fir@gmail.com> - 2016-12-09 00:06 -0800
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 11:35 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-09 12:12 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 13:33 +0100
Re: micro-architectural details Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-09 15:41 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:28 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-10 09:58 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:53 -0800
Re: micro-architectural details Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 03:10 -0600
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-11 13:48 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-11 14:43 +0000
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 16:23 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-11 12:53 -0800
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:27 +0000
Re: micro-architectural details supercat@casperkitty.com - 2016-12-11 08:46 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:14 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-15 08:25 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:11 -0800
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-15 14:28 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-11 18:38 +0100
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 00:25 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-09 07:42 -0800
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-09 11:54 -0800
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 10:27 +0100
Re: other missing features (no-brainers) Noob <root@127.0.0.1> - 2016-12-09 17:05 +0100
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 09:51 +0000
Re: "Lete2�™s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:42 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:16 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:31 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 15:55 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:01 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 16:42 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:55 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:11 -0800
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-06 23:05 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:43 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 03:06 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:47 +0100
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:10 -0800
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:13 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 11:47 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 12:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-07 23:45 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 00:22 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 15:32 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 01:25 +0100
Re: "Let's Stop Bashing C" supercat@casperkitty.com - 2016-12-07 16:36 -0800
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 17:09 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 10:28 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-08 08:34 -0800
Re: "Let's Stop Bashing C" Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 10:24 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 15:49 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 15:23 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 16:58 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 18:57 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 15:29 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:09 +0100
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:41 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 17:04 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:15 +0100
Re: "Lete2??s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:34 -0500
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 18:40 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 10:00 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:05 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 19:58 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 08:22 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:12 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 11:40 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:44 -0600
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:22 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:14 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:19 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 07:44 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 22:05 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 22:14 +0100
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 10:39 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 13:33 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 11:13 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 06:27 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:17 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:43 -0600
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-07 07:41 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:45 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 09:22 -0800
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:49 +0100
Re: "Lete2??s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:28 -0500
Re: "Lete2��s Stop Bashing C" "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-06 14:22 -0500
Re: Subject field encoding Noob <root@127.0.0.1> - 2016-12-07 21:40 +0100
Re: Subject field encoding Keith Thompson <kst-u@mib.org> - 2016-12-07 13:01 -0800
Re: Subject field encoding Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 16:02 -0500
Re: "Lete2�™s Stop Bashing C" asetofsymbols@gmail.com - 2016-12-08 15:50 -0800
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:07 +0000
Re: "Let€™s Stop Bashing C" Xcott Craver <nospam@nospam.invalid> - 2016-12-07 16:48 -0500
Re: "Let's Stop Bashing C" Noob <root@127.0.0.1> - 2016-12-07 23:29 +0100
Re: "Let’s Stop Bashing C" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-06 12:06 +0800
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 19:58 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2cadc$15v$1@dont-email.me> |
| In reply to | #98383 |
On 08/12/16 17:15, jacobnavia wrote: > Le 08/12/2016 à 17:04, David Brown a écrit : >> The C language, as a standard, will /never/ give access to overflow >> information. > > C gives access to overflow information for floating point overflow. It does - /if/ the implementation chooses to define the exception flags, which is not required by the standard. My (unsupported) guess is that very few programs use these, and that a good many programs that use floating point would get the same results but faster operation if these features and other IEEE compatibility features (which are not required by C) are disabled. > > Look there is no point in discussing with you. You have yet to give any indication that you are trying to discuss anything with me. You are more interested in ranting and raving because I suggested you consider the possibility that overflow checking is not always a good thing. > > You are against overflow checking because you think that the programmer > can figure out all the operations where an overflow is possible and test > for overflow accordingly, by hand or handcrafted assembler, whatever but > not in C. C, as you say, will never give any solution to overflow. > I think the programmer should figure out all cases in which there are overflows that affect the correctness of their code. That is part of the job of writing correct code. After all, signed integer overflow is undefined behaviour - programmers should not write code that has undefined behaviour. This is a simple basic fact - if you want to write programs, you should write correct programs. Overflows that give you incorrect results or undefined behaviour are bugs - they can never be part of correct code. (Some sorts of overflows are irrelevant to the results or perhaps even lead to correct results, and therefore usually do not need to be checked.) When people have written correct code, they usually want that code to run efficiently. They do not want useless checks of code they know is correct. Correctness is more important than speed - but speed is important too. You should first understand this before going any further about overflow checking. Then we come to the second basic fact about programming - programmers make mistakes. It is a good thing if tools help programmers spot their mistakes as early as possible, and fix them. /That/ is where overflow checking comes in handy. When you have understood this part too, it is time to look at how overflow detection can be implemented. You'll find a number of example methods in my post earlier - if you care to read it rather than shout at it. > You win. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 08:22 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <4d5df7ec-01b5-4cbf-8280-e2431b422562@googlegroups.com> |
| In reply to | #98380 |
On Thursday, December 8, 2016 at 10:05:02 AM UTC-6, David Brown wrote:
> There are basically two possibilities for a (signed) overflow to occur
> in code:
>
> 1. You know it might occur, but it doesn't matter if it does.
>
> In this case, you don't want extra checking.
>
> 2. You have a bug in your code.
How about:
3. You know that it won't occur if your program is fed valid data, but
data isn't necessarily trustworthy, and the cost of validating the
data would exceed the cost of processing it. If data is invalid,
the output doesn't have to be particularly meaningful, but even
maliciously-constructed data must not cause the program to behave in
harmful fashion. In this case, calculations relating to things like
memory allocation should be overflow-checked; other calculations need
not be overflow checked *provided* that overflows don't undermine the
effectiveness of other safety-checks in the program.
4. You know that it won't occur if your code is fed the sorts of data
for which it was designed, but might conceivably occur if the usage
is expanded. If a system is designed for 1,000 customers each of
whom owns 500 widgets, a 32-bit counter would suffice for tallying
up the total number of widgets. If the system becomes so popular
that millions of customers have thousands of widgets each, however,
that 32-bit counter might no longer suffice. Having the system
squawk when an overflow occurs would likely be preferable to having
it start misbehaving in other ways.
Both of those seem like situations where the language could be made much
more helpful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 20:12 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2cb8k$4pi$1@dont-email.me> |
| In reply to | #98385 |
On 08/12/16 17:22, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 10:05:02 AM UTC-6, David Brown wrote: >> There are basically two possibilities for a (signed) overflow to occur >> in code: >> >> 1. You know it might occur, but it doesn't matter if it does. >> >> In this case, you don't want extra checking. >> >> 2. You have a bug in your code. > > How about: > > 3. You know that it won't occur if your program is fed valid data, but > data isn't necessarily trustworthy, and the cost of validating the > data would exceed the cost of processing it. If data is invalid, > the output doesn't have to be particularly meaningful, but even > maliciously-constructed data must not cause the program to behave in > harmful fashion. In this case, calculations relating to things like > memory allocation should be overflow-checked; other calculations need > not be overflow checked *provided* that overflows don't undermine the > effectiveness of other safety-checks in the program. Your program should explicitly check that there will be no overflow (or, if you like, it's fine to use implementation-dependent methods that are safe to run with an overflow and give a clear indication afterwards) in cases where the overflow is important to identify. In cases where it does not matter, then it does not matter. (Note that accidentally causing undefined behaviour usually /does/ matter, unless your compiler says it is safe.) So that is basically case 1 - or case 2 if you get it wrong. > > 4. You know that it won't occur if your code is fed the sorts of data > for which it was designed, but might conceivably occur if the usage > is expanded. If a system is designed for 1,000 customers each of > whom owns 500 widgets, a 32-bit counter would suffice for tallying > up the total number of widgets. If the system becomes so popular > that millions of customers have thousands of widgets each, however, > that 32-bit counter might no longer suffice. Having the system > squawk when an overflow occurs would likely be preferable to having > it start misbehaving in other ways. If your 32-bit counter might overflow, you have three choices, as I see it: 1. Ignore the problem. Ship with a latent bug, safe in the knowledge that it is extraordinarily unlikely to occur. Win95 was shipped with a latent overflow bug on a 32-bit millisecond counter. But it was pretty safe from that bug - it was over ten years before anyone had managed to keep a Win95 system running long enough, 49 days, for the bug to be triggered. 2. Check for overflow before incrementing the counter, and take appropriate action such as refusing to accept another widget. 3. Make the counter 64-bit, and noting that since the sum weight of 2^64 widgets at 2 kg each (for example) would exceed the mass of the earth's crust, it is reasonable to assume the counter will not overflow. > > Both of those seem like situations where the language could be made much > more helpful. > At best, a compiler-generated overflow check would give the customer a clearer message when the system died. It would never be checked or tested before delivery. And at worst, it would give the developer an unwarranted sense of security.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 11:40 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <1d22e183-793e-4a10-9a89-97827a0b7874@googlegroups.com> |
| In reply to | #98398 |
On Thursday, December 8, 2016 at 1:12:43 PM UTC-6, David Brown wrote: > Your program should explicitly check that there will be no overflow (or, > if you like, it's fine to use implementation-dependent methods that are > safe to run with an overflow and give a clear indication afterwards) in > cases where the overflow is important to identify. In cases where it > does not matter, then it does not matter. (Note that accidentally > causing undefined behaviour usually /does/ matter, unless your compiler > says it is safe.) Unfortunately, in modern C, case #1 doesn't exist; even in cases where code would be happy if the result of overflow could arbitrarily behave as any number (not necessarily within range for any data type) that would be congruent to the wrapped result mod the range of integers, aggressive optimizations will cause what would otherwise be benign overflows to undermine essential checks for things like array bounds (even if the latter checks don't cause overflows nor act upon the results of computations which have overflowed). > > 4. You know that it won't occur if your code is fed the sorts of data > > for which it was designed, but might conceivably occur if the usage > > is expanded. If a system is designed for 1,000 customers each of > > whom owns 500 widgets, a 32-bit counter would suffice for tallying > > up the total number of widgets. If the system becomes so popular > > that millions of customers have thousands of widgets each, however, > > that 32-bit counter might no longer suffice. Having the system > > squawk when an overflow occurs would likely be preferable to having > > it start misbehaving in other ways. > > > Both of those seem like situations where the language could be made much > > more helpful. > > At best, a compiler-generated overflow check would give the customer a > clearer message when the system died. It would never be checked or > tested before delivery. And at worst, it would give the developer an > unwarranted sense of security. Many programs are executed in situations where undetected faulty output could cause far more serious harm than would a refusal to produce any output or a proclamation that output might be faulty. Having a program crash with an overflow when it's supposed to output a file for a 3D printer may not be desirable, but it would still be better than having it produce a file which seems to be invalid but generates a defective part. Crashing when given a malformed data would also be vastly preferable to arbitrarily executing code supplied by the creator of that file.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-10 02:44 -0600 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <t3fn4c96tvqvddt1cldkmvlk4o8jk6f0an@4ax.com> |
| In reply to | #98398 |
On Thu, 8 Dec 2016 20:12:36 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 08/12/16 17:22, supercat@casperkitty.com wrote: >> On Thursday, December 8, 2016 at 10:05:02 AM UTC-6, David Brown wrote: >>> There are basically two possibilities for a (signed) overflow to occur >>> in code: >>> >>> 1. You know it might occur, but it doesn't matter if it does. >>> >>> In this case, you don't want extra checking. >>> >>> 2. You have a bug in your code. >> >> How about: >> >> 3. You know that it won't occur if your program is fed valid data, but >> data isn't necessarily trustworthy, and the cost of validating the >> data would exceed the cost of processing it. If data is invalid, >> the output doesn't have to be particularly meaningful, but even >> maliciously-constructed data must not cause the program to behave in >> harmful fashion. In this case, calculations relating to things like >> memory allocation should be overflow-checked; other calculations need >> not be overflow checked *provided* that overflows don't undermine the >> effectiveness of other safety-checks in the program. > >Your program should explicitly check that there will be no overflow (or, >if you like, it's fine to use implementation-dependent methods that are >safe to run with an overflow and give a clear indication afterwards) in >cases where the overflow is important to identify. In cases where it >does not matter, then it does not matter. (Note that accidentally >causing undefined behaviour usually /does/ matter, unless your compiler >says it is safe.) > >So that is basically case 1 - or case 2 if you get it wrong. In some cases it's quite awkward to check if a combination of inputs will result in an overflow. Consider a system that allows someone to put thousands of line items on a PO, with tens of thousands of units for each line item, and allows line items to range in price from mils up to tens of thousands of dollars. So the (theoretical) maximum order would be the product of those limits. OTOH, no sane order will ever get anywhere near the trillions of dollars (or quadrillions of pennies) that you could theoretically put on such a PO. Now you could do the arithmetic in a type large enough to handle the largest (theoretically) possible result, although you may have issues with the limitations of C's types, but that may be inconvenient or slow. Or you could trap overflows, and send the order to the pending/exception queue, just like the order that computed successfully, but failed the final "reject if total>$5000000" test. Admittedly that's not all that common a situation, but I have seen the Cobol "ON SIZE ERROR" test used for that sort of thing. One way I've seen that dealt with is to do the (normally integer) calculation in float first, to get an approximate magnitude for the result. Ugly is not a strong enough word, but... That being said, I'd happily take a required 128-bit type in C instead of overflow checking.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-08 16:22 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c193$srs$2@dont-email.me> |
| In reply to | #98380 |
On 08/12/16 16:04, David Brown wrote: > I won't froth at the mouth > every time someone mentions a different programming language. By an odd co-incidence, that's on my list of New Year Resolutions for 2017. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 20:14 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2cbbe$4pi$2@dont-email.me> |
| In reply to | #98386 |
On 08/12/16 17:22, Richard Heathfield wrote: > On 08/12/16 16:04, David Brown wrote: >> I won't froth at the mouth >> every time someone mentions a different programming language. > > By an odd co-incidence, that's on my list of New Year Resolutions for 2017. > It is not wise to be too ambitious in your New Year Resolutions. Take it easy - start by vowing to remain calm when someone says C99 was an improvement over C90 :-)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-10 02:19 -0600 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <uben4cl66tnhf37jkupf2bgqiuf3618ple@4ax.com> |
| In reply to | #98365 |
On Thu, 8 Dec 2016 15:49:26 +0100, jacobnavia <jacob@jacob.remcomp.fr> wrote: >Le 08/12/2016 à 10:24, David Brown a écrit : >> Don't you also want to ask if it /should/ be done? I think in many >> cases there is no need to have overflow checking in floating point >> either - especially as the ability to check for overflow can be >> extremely costly. > >Yes. I see my error. Who cares about the results? What is important is >that they are done FAST! Well, as an aside, Seymour Cray built a good sized company based on pretty much that principle. Early Cray's were notorious for "odd" FP arithmetical results. a*b was commonly not the same value as b*a, the low few bits of many FP operations regularly got curdled by the hardware. Numerical analysis on those boxes was a full contact sport... But, boy were they fast!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 07:44 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <490a9713-ac98-47f5-a8ec-a0c7825ee97c@googlegroups.com> |
| In reply to | #98346 |
On Thursday, December 8, 2016 at 3:25:08 AM UTC-6, David Brown wrote:
> Don't you also want to ask if it /should/ be done? I think in many
> cases there is no need to have overflow checking in floating point
> either - especially as the ability to check for overflow can be
> extremely costly. In particular, if you have overflow checking (for
> integer or floating point) you hinder a lot of compiler optimisation
> such as re-arrangement of expressions, as your operations are no longer
> commutable, associative, and otherwise mathematically "nice". And when
> dealing with "big" processors, overflow checking means you can't do
> things in parallel using SIMD or vector instructions.
Many optimizations can be maintained if overflow may, but need not be,
reported in cases where a program would manage to yield arithmetically-
correct output anyway, and if a program need not be notified of the
precise place where overflow occurred but merely informed that an overflow
may have resulted in inaccurate results having been produced.
> I agree that overflow checking can sometimes be useful for testing and
> debugging. If you want to implement it, there are various methods:
It's often more important in production code. While there may be a few
places where efficiency is more important than safety, most programs spend
the vast majority of their time in a tiny portion of the code, and except
in places where code size is critical (small embedded systems) the cost
of using overflow checking outside the most time-critical loops would be
relatively slight. Further, on many platforms a compiler that is designed
to optimize such checks may be able to perform them quite cheaply even in
an optimized loop. For example, on some ARM platforms, a loop which needs
to add many 32-bit values to yield a 32-bit sum and report whether an
overflow occurred could perform such a check with almost zero extra overhead
by using conditional instructions. Start by loading r6 with a counter that
will hit 0x80000000 on the last iteration, and then generate code equivalent
to:
do {
fetch *r5++ into r0,r1,r2,r3
if (!last_add_overflowed) r4+=r0;
if (!last_add_overflowed) r4+=r1;
if (!last_add_overflowed) r4+=r2;
if (!last_add_overflowed) r4+=r3;
if (!last_add_overflowed) r6++;
} while(!last_add_overflowed);
The conditional checks add zero time overhead on the ARM7-TDMI or
Cortex-M3 (and probably some other versions as well), so there would
be zero per-loop overhead. The only extra time cost in the non-overflow
case would be adjusting the index in r6 (so it will set the overflow flag
on the last repetition) and checking whether the index reached 0x80000000
before the loop terminated. Note that if an overflow does occur the value
in r5 would be meaningless (code wouldn't know which registers had been
added to r5) but if code were to only use the total in the non-overflow
case a compiler wouldn't have to worry about that. If the mod-0xFFFFFFFF
value is needed in the overflow case, that could be handled at a cost of
one extra instruction per loop [save the value of r4 before on each
repetition so the last four adds can be repeated once overflow is detected]
or else by restarting the loop from scratch on the first overflow [doubling
the cost of the loop in the first-overflow case].
> 1. Make it machine-dependent and have a way to check for an "overflow
> flag" after an operation. This only makes sense on processors that
> actually have an overflow flag. It is also, IMHO, a poor solution. It
> gets really messy for expressions of more than one part - how is the
> flag set in "(a + b) * (c + d)" ? The user pays a high price in weak
> code generation even when he knows there is no overflow.
>...
> 5. I expect there are more ideas ...
5. Have a per-thread flag (perhaps errno, or perhaps something else) which
is set when an overflow occurs. My inclination would be to have macros
which would check if an overflow occurs, reset the flag, or save/restore
the flag, and specify that implementations may use errno or something
else, at their convenience.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 22:05 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2chri$stf$1@dont-email.me> |
| In reply to | #98373 |
On 08/12/16 16:44, supercat@casperkitty.com wrote:
> On Thursday, December 8, 2016 at 3:25:08 AM UTC-6, David Brown wrote:
>> Don't you also want to ask if it /should/ be done? I think in many
>> cases there is no need to have overflow checking in floating point
>> either - especially as the ability to check for overflow can be
>> extremely costly. In particular, if you have overflow checking (for
>> integer or floating point) you hinder a lot of compiler optimisation
>> such as re-arrangement of expressions, as your operations are no longer
>> commutable, associative, and otherwise mathematically "nice". And when
>> dealing with "big" processors, overflow checking means you can't do
>> things in parallel using SIMD or vector instructions.
>
> Many optimizations can be maintained if overflow may, but need not be,
> reported in cases where a program would manage to yield arithmetically-
> correct output anyway, and if a program need not be notified of the
> precise place where overflow occurred but merely informed that an overflow
> may have resulted in inaccurate results having been produced.
>
>> I agree that overflow checking can sometimes be useful for testing and
>> debugging. If you want to implement it, there are various methods:
>
> It's often more important in production code. While there may be a few
> places where efficiency is more important than safety, most programs spend
> the vast majority of their time in a tiny portion of the code, and except
> in places where code size is critical (small embedded systems) the cost
> of using overflow checking outside the most time-critical loops would be
> relatively slight. Further, on many platforms a compiler that is designed
> to optimize such checks may be able to perform them quite cheaply even in
> an optimized loop. For example, on some ARM platforms, a loop which needs
> to add many 32-bit values to yield a 32-bit sum and report whether an
> overflow occurred could perform such a check with almost zero extra overhead
> by using conditional instructions. Start by loading r6 with a counter that
> will hit 0x80000000 on the last iteration, and then generate code equivalent
> to:
>
> do {
> fetch *r5++ into r0,r1,r2,r3
> if (!last_add_overflowed) r4+=r0;
> if (!last_add_overflowed) r4+=r1;
> if (!last_add_overflowed) r4+=r2;
> if (!last_add_overflowed) r4+=r3;
> if (!last_add_overflowed) r6++;
> } while(!last_add_overflowed);
>
> The conditional checks add zero time overhead on the ARM7-TDMI or
> Cortex-M3 (and probably some other versions as well), so there would
> be zero per-loop overhead. The only extra time cost in the non-overflow
> case would be adjusting the index in r6 (so it will set the overflow flag
> on the last repetition) and checking whether the index reached 0x80000000
> before the loop terminated. Note that if an overflow does occur the value
> in r5 would be meaningless (code wouldn't know which registers had been
> added to r5) but if code were to only use the total in the non-overflow
> case a compiler wouldn't have to worry about that. If the mod-0xFFFFFFFF
> value is needed in the overflow case, that could be handled at a cost of
> one extra instruction per loop [save the value of r4 before on each
> repetition so the last four adds can be repeated once overflow is detected]
> or else by restarting the loop from scratch on the first overflow [doubling
> the cost of the loop in the first-overflow case].
As usual, you examples are very creative and very unrealistic. Adding
up 2^31 numbers but stopping when there is an overflow? Never happens.
Conditional checks are /not/ zero time overhead on any ARM devices,
though they can be close to zero overhead on pipelined superscaler
devices where skipped instructions can be eliminated early. On devices
such as the M3, the skipped instruction still takes a cycle to do
nothing, and it still costs in the bandwidth to read in the skipped
instruction.
At best, your code would be looking for something like:
ITE VC // if-then-else overflow clear
ADD.VC r4, r0, r4 // r4 = r0 + r4 if overflow clear
B.VS exitloop // else branch if overflow set
for each of the add lines.
On the other hand, with a nice simple 64-bit sum stored in r4, r7 then
the critical lines become:
ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag
ADC r7, r7, #0 // r7 = r7 + 0 + carry flag
That is shorter and faster. At the edge of the loop, check r7 to
indicate an overflow.
Alternatively, on an M4 with saturating arithmetic, just do it all as
saturated addition and check for the saturated flag at the end. That
would be rather target-specific, but that's okay - and you can use the
ARM CMSIS headers to make it compiler independent.
>
>> 1. Make it machine-dependent and have a way to check for an "overflow
>> flag" after an operation. This only makes sense on processors that
>> actually have an overflow flag. It is also, IMHO, a poor solution. It
>> gets really messy for expressions of more than one part - how is the
>> flag set in "(a + b) * (c + d)" ? The user pays a high price in weak
>> code generation even when he knows there is no overflow.
>> ...
>> 5. I expect there are more ideas ...
>
> 5. Have a per-thread flag (perhaps errno, or perhaps something else) which
> is set when an overflow occurs. My inclination would be to have macros
> which would check if an overflow occurs, reset the flag, or save/restore
> the flag, and specify that implementations may use errno or something
> else, at their convenience.
>
It is certainly possible to do that, yes.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 22:14 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2cid3$uu7$1@dont-email.me> |
| In reply to | #98408 |
Le 08/12/2016 à 22:05, David Brown a écrit : > On the other hand, with a nice simple 64-bit sum stored in r4, r7 then > the critical lines become: > > ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag > ADC r7, r7, #0 // r7 = r7 + 0 + carry flag And why you avoid using the V bit of the APSR? Why not use the actual hardware? It is always faster than "doing it by hand".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 10:39 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2du22$e8b$1@dont-email.me> |
| In reply to | #98411 |
On 08/12/16 22:14, jacobnavia wrote: > Le 08/12/2016 à 22:05, David Brown a écrit : >> On the other hand, with a nice simple 64-bit sum stored in r4, r7 then >> the critical lines become: >> >> ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag >> ADC r7, r7, #0 // r7 = r7 + 0 + carry flag > > And why you avoid using the V bit of the APSR? > > Why not use the actual hardware? It is always faster than "doing it by > hand". Did you read the rest of what I wrote? You are so keen on fighting and arguing that you fail to see when people write something that /supports/ what you are saying. If you want to use the overflow bit, you have to check it after /every/ addition, and that is three instructions per addition instead of two. I also suggested that when you have hardware that /really/ helps, such as saturated arithmetic support on Cortex M4 devices, then you can use a single instruction here and test the saturated flag at the end. Key to this is that the "saturated" flag is sticky - instructions set it, but don't clear it. The "overflow" flag is volatile - instructions set and clear it, so you must test as you go along. So yes, support for low-level features of hardware can be a good thing. But no, it should not be standardised in C - this kind of thing is highly target dependent. And no, "overflow" is not special enough to be treated as vital to C, even though it is more common than (for example) ARM's saturate flag.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 13:33 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <6357c76f-0686-45db-97cc-d9e5bae09ea7@googlegroups.com> |
| In reply to | #98408 |
On Thursday, December 8, 2016 at 3:05:15 PM UTC-6, David Brown wrote:
> As usual, you examples are very creative and very unrealistic. Adding
> up 2^31 numbers but stopping when there is an overflow? Never happens.
Adding up 32-bit numbers and wanting to know if overflows occur doesn't
seem obscure to me. Computing a 64-bit sum of 32-bit values would be a
fair bit more expensive than performing a 32-bit sum with overflow check.
> Conditional checks are /not/ zero time overhead on any ARM devices,
> though they can be close to zero overhead on pipelined superscaler
> devices where skipped instructions can be eliminated early. On devices
> such as the M3, the skipped instruction still takes a cycle to do
> nothing, and it still costs in the bandwidth to read in the skipped
> instruction.
Yes, but in the overflow-checking code I posted the only time any
instructions get skipped is if an overflow occurs (the loop exit itself
would be triggered by an overflow on the loop index causing the looping
jump to get skipped).
> At best, your code would be looking for something like:
>
> ITE VC // if-then-else overflow clear
> ADD.VC r4, r0, r4 // r4 = r0 + r4 if overflow clear
> B.VS exitloop // else branch if overflow set
>
> for each of the add lines.
What are the branches for? They're not needed. If an overflow occurs,
any operation which would cause the overflow flag to get cleared will be
skipped.
> On the other hand, with a nice simple 64-bit sum stored in r4, r7 then
> the critical lines become:
>
> ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag
> ADC r7, r7, #0 // r7 = r7 + 0 + carry flag
>
> That is shorter and faster. At the edge of the loop, check r7 to
> indicate an overflow.
That would work, though not as fast as the version with conditional skips,
if the requirement were to add unsigned 32-bit values to a 64-bit total.
I think for a signed form it would be necessary to do something like:
ADDS r4, r4, r0
ADC r7, r7, r0, asr #31
Otherwise, Not counting the memory loads or the final branch (which would
cost the same as an unchecked version in either case) my version would be:
loop:
LDRMIA ...
ITE VC ; Zero cycles on ARM7-TDMI in ARM mode, or Cortex-M3 if next
ADDS.VC R3,R3,R0 ; instruction is 16 bits (like this one is)
ITE VC
ADDS.VC R3,R3,R1
ITE VC
ADDS.VC R3,R3,R2
ITE VC
ADDS.VC R3,R3,R3
ITE VC
ADDS.VC R6,R6,#1
;final branch would use BVC rather than BNZ, but they cost the same
The ITE prefix will sometimes cost a cycle on the Cortex-M3 if a sequence
of ITE prefixes and two-word instructions (which would consume 1.5 words
per cycle) exhausts the instruction-fetch mechanism, but if it alternates
with single-word instructions that's not going to happen. On the ARM7-TDMI
the conditional execution is controlled via four-bit field that is present
in every ARM-mode instruction, so an ADDS.VS costs exactly the same as an
ADDS.
> Alternatively, on an M4 with saturating arithmetic, just do it all as
> saturated addition and check for the saturated flag at the end. That
> would be rather target-specific, but that's okay - and you can use the
> ARM CMSIS headers to make it compiler independent.
Is the saturating arithmetic on that platform "sticky"? Some processors
and DSPs implement saturating arithmetic such that a computation like
0x60000000+0x60000000-0x60000000 would yield 0x1FFFFFFF without any
indication that an overflow occurred.
> > 5. Have a per-thread flag (perhaps errno, or perhaps something else) which
> > is set when an overflow occurs. My inclination would be to have macros
> > which would check if an overflow occurs, reset the flag, or save/restore
> > the flag, and specify that implementations may use errno or something
> > else, at their convenience.
>
> It is certainly possible to do that, yes.
I would think it would make it easy for applications to offer assurance
that any results they produce have not been corrupted by overflow, while
still offering compilers far more latitude with regard to optimization
than would be available with any other overflow semantics I've seen proposed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 11:13 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2e00t$k1h$1@dont-email.me> |
| In reply to | #98415 |
On 08/12/16 22:33, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 3:05:15 PM UTC-6, David Brown wrote: >> As usual, you examples are very creative and very unrealistic. Adding >> up 2^31 numbers but stopping when there is an overflow? Never happens. > > Adding up 32-bit numbers and wanting to know if overflows occur doesn't > seem obscure to me. Computing a 64-bit sum of 32-bit values would be a > fair bit more expensive than performing a 32-bit sum with overflow check. You have different ideas about "obscure functions" that I do - that has been clear for years. > >> Conditional checks are /not/ zero time overhead on any ARM devices, >> though they can be close to zero overhead on pipelined superscaler >> devices where skipped instructions can be eliminated early. On devices >> such as the M3, the skipped instruction still takes a cycle to do >> nothing, and it still costs in the bandwidth to read in the skipped >> instruction. > > Yes, but in the overflow-checking code I posted the only time any > instructions get skipped is if an overflow occurs (the loop exit itself > would be triggered by an overflow on the loop index causing the looping > jump to get skipped). > Incorrect - you specifically require the additions to be skipped if previous additions overflowed. But since you posted pseudocode rather than C code, ARM assembly code, or a proper description of the actual problem, it is hard to be sure what you meant. >> At best, your code would be looking for something like: >> >> ITE VC // if-then-else overflow clear >> ADD.VC r4, r0, r4 // r4 = r0 + r4 if overflow clear >> B.VS exitloop // else branch if overflow set >> >> for each of the add lines. > > What are the branches for? They're not needed. If an overflow occurs, > any operation which would cause the overflow flag to get cleared will be > skipped. Fair enough. > >> On the other hand, with a nice simple 64-bit sum stored in r4, r7 then >> the critical lines become: >> >> ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag >> ADC r7, r7, #0 // r7 = r7 + 0 + carry flag >> >> That is shorter and faster. At the edge of the loop, check r7 to >> indicate an overflow. > > That would work, though not as fast as the version with conditional skips, > if the requirement were to add unsigned 32-bit values to a 64-bit total. > I think for a signed form it would be necessary to do something like: > > ADDS r4, r4, r0 > ADC r7, r7, r0, asr #31 I have been keeping things simple with unsigned arithmetic - I hope that is okay. > > Otherwise, Not counting the memory loads or the final branch (which would > cost the same as an unchecked version in either case) my version would be: > > loop: > LDRMIA ... > ITE VC ; Zero cycles on ARM7-TDMI in ARM mode, or Cortex-M3 if next > ADDS.VC R3,R3,R0 ; instruction is 16 bits (like this one is) > ITE VC > ADDS.VC R3,R3,R1 > ITE VC > ADDS.VC R3,R3,R2 > ITE VC > ADDS.VC R3,R3,R3 > ITE VC > ADDS.VC R6,R6,#1 > ;final branch would use BVC rather than BNZ, but they cost the same > > The ITE prefix will sometimes cost a cycle on the Cortex-M3 if a sequence > of ITE prefixes and two-word instructions (which would consume 1.5 words > per cycle) exhausts the instruction-fetch mechanism, but if it alternates > with single-word instructions that's not going to happen. On the ARM7-TDMI > the conditional execution is controlled via four-bit field that is present > in every ARM-mode instruction, so an ADDS.VS costs exactly the same as an > ADDS. I did not realise the ITE instruction could be handled early in the Cortex M pipeline and thus take 0 cycles in execution (though it still takes bandwidth in the flash and instruction buses, which can be bigger than the execution time). Yes, I agree that this implementation looks like the fastest version for the function you want (unless the saturated arithmetic version below is usable on your device). Of course, this has nothing to do with the sort of overflow detection being discussed, and is very highly target dependent. It is not the kind of code that is likely to be generated by a compiler, and would probably need to be hand-written. > >> Alternatively, on an M4 with saturating arithmetic, just do it all as >> saturated addition and check for the saturated flag at the end. That >> would be rather target-specific, but that's okay - and you can use the >> ARM CMSIS headers to make it compiler independent. > > Is the saturating arithmetic on that platform "sticky"? Some processors > and DSPs implement saturating arithmetic such that a computation like > 0x60000000+0x60000000-0x60000000 would yield 0x1FFFFFFF without any > indication that an overflow occurred. It is sticky on the M4, anyway. > >>> 5. Have a per-thread flag (perhaps errno, or perhaps something else) which >>> is set when an overflow occurs. My inclination would be to have macros >>> which would check if an overflow occurs, reset the flag, or save/restore >>> the flag, and specify that implementations may use errno or something >>> else, at their convenience. >> >> It is certainly possible to do that, yes. > > I would think it would make it easy for applications to offer assurance > that any results they produce have not been corrupted by overflow, while > still offering compilers far more latitude with regard to optimization > than would be available with any other overflow semantics I've seen proposed. >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-07 06:27 -0600 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <0vuf4c57g48jckf0ecq4daacev7jv5oia1@4ax.com> |
| In reply to | #98247 |
On Wed, 07 Dec 2016 11:47:09 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>> Le 07/12/2016 à 04:06, Ben Bacarisse a écrit :
>>> These instructions raise an exception when overflow occurs. No doubt
>>> one could harness that to provide what looks like an overflow flag but
>>> it would not be as simple as returning a bit from some status register.
>>
>> So what?
>> Any overflow trap sets that flag!
>
>What flag?
>
>> And it would be simpler than what I have to generate for the x86. In
>> the x86 I have to generate the test and the jump. Using the dec alpha
>> I wouldn't have to generate anything, just set the overflow signal to
>> a function that does the appropiate thing.
>
>Yes, my remark was about the machine having an overflow flag. But I'm
>still confused about what you are proposing. For a compiler writer to
>detect overflow is one thing, but making that facility useful to
>programmers is another. I would like to know what you are proposing.
>
>I've seen a lot of different approaches and I'm not much of a fan of any
>of them. I get the feeling there is probably a useful way to do this
>but I'm not sure I know what it is.
>
>I lean towards a construct that lets the programmer delineate the code
>for which overflow checking matters:
>
> if (_Overflow(c += a*b)) ... handle overflow ...
>
>Being a high-level sort of person I'd want this to propagate into
>function calls which might mean that the compiler needs to generate both
>a checked and an unchecked version of each function if there is some
>cost to the checking:
>
> if (_Overflow(f(g()))) ...
>
>f and g called outside of an _Overflow(...) expression should not pay
>any price. This, though, goes wrong with functions called through a
>pointer object.
>
>What mechanisms have people used before, and what was good/bad about it?
Cobol uses a construct of the form:
COMPUTE A = (B * C) + D
ON SIZE ERROR
...some code...
Which is a bit more like an exception. Now in Cobol the right side of
the expression really can't overflow (at least ignoring divide by zero
and limiting things to most non-FP values), and the compiler is
(mostly - there are limits) obligated to compute to whatever precision
is required to actually hold the result, and then the ON SIZE ERROR
really applies to the assignment (so while B*C might be too large,
it's not an error if D is a sufficiently large negative number to get
things back into range). It works fairly well for its intended
purpose.
C doesn't really lend itself to exact the same approach, since
assignment is not really a statement in the same sense.
If I were doing this in C++, I'd certainly take the exception route,
you could even do that fairly easily by implementing some classes that
do arithmetic, on the same types as are native, but buried inside some
checking code that throws as appropriate (or sets a errno-like global,
if you'd prefer). Implementing such classes efficiently would be a
QoI issue.
I can't see how you'd do something like this in C without some sort of
enhancement, but a set of checked types*, and a global errno-like
overflow flag would probably work. The usual promotions would be
extended to convert any type to the (otherwise identical) matching
checked type if combined with another checked value. Then clear the
overflow flag, do all the work you want, then see if anything failed.
The semantics of the checked types would probably be the common two's
complement ones.
*lcc-win might support doing this via the overloading mechanism it
supports, but I'm not sufficiently familiar.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 07:17 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <cac0872e-0215-4872-8bfa-34e72288119e@googlegroups.com> |
| In reply to | #98252 |
On Wednesday, December 7, 2016 at 6:27:17 AM UTC-6, robert...@yahoo.com wrote: > I can't see how you'd do something like this in C without some sort of > enhancement, but a set of checked types*, and a global errno-like > overflow flag would probably work. The usual promotions would be > extended to convert any type to the (otherwise identical) matching > checked type if combined with another checked value. Then clear the > overflow flag, do all the work you want, then see if anything failed. > The semantics of the checked types would probably be the common two's > complement ones. I would add a proviso that even "checked" types should be allowed to behave as though they can accommodate as much additional range as the compiler sees fit, provided that the overflow check must squawk if any precision has been lost or any variables presently hold out-of-range values and the compiler can't prove that they won't be used in ways that might cause precision loss.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-07 23:43 -0600 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <ggrh4c5jljj74nm51q701krl3p941ojc58@4ax.com> |
| In reply to | #98264 |
On Wed, 7 Dec 2016 07:17:32 -0800 (PST), supercat@casperkitty.com
wrote:
>On Wednesday, December 7, 2016 at 6:27:17 AM UTC-6, robert...@yahoo.com wrote:
>> I can't see how you'd do something like this in C without some sort of
>> enhancement, but a set of checked types*, and a global errno-like
>> overflow flag would probably work. The usual promotions would be
>> extended to convert any type to the (otherwise identical) matching
>> checked type if combined with another checked value. Then clear the
>> overflow flag, do all the work you want, then see if anything failed.
>> The semantics of the checked types would probably be the common two's
>> complement ones.
>
>I would add a proviso that even "checked" types should be allowed to
>behave as though they can accommodate as much additional range as the
>compiler sees fit, provided that the overflow check must squawk if any
>precision has been lost or any variables presently hold out-of-range
>values and the compiler can't prove that they won't be used in ways that
>might cause precision loss.
Perhaps more simply stated that the overflow *must* be signaled if the
miscalculation due to the overflow would be visible to the program,
but that it *may* be signaled if any intermediate operations overflow.
Something like the example you used elsewhere:
>
> int compute_sum(int32_t *result, int32_t *x[], int32_t *y, size_t count)
> {
> int64_t sum = 0;
> for (int i=0; i<count; i++)
> {
> sum += (int64_t)x[i]*y[i];
> if (sum < INT_MIN || sum > INT_MAX)
> return 1;
> }
> *result = sum;
> return 0;
> }
Could (on x86-32) reasonably be compiled as:
ebp:ecx:ebx=0:0:0
loop:
mov eax,dword ptr [esi]
imul dword ptr [edi]
add ebx,eax
adc ecx,edx
adc ebp,0
add esi,4
add edi,4
..loop.. ;yeah, we'd really like another register here
generating a 96-bit result (ebp:ecx:ebx) internally, and doing the
overflow check (ebp:ecx not all zeros or all ones) at the end.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-12-07 07:41 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <slrn3vfso4ffbd.5mn.ike@iceland.freeshell.org> |
| In reply to | #98223 |
On 2016-12-06, jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 07/12/2016 ? 00:05, Ike Naar a ?crit : >> On 2016-12-06, jacobnavia <jacob@jacob.remcomp.fr> wrote: >>> Le 06/12/2016 ? 20:20, supercat@casperkitty.com a ?crit : >>>> In Standard C, determining whether an arithmetic operation would produce an >>>> overflow is generally much more difficult than performing the operation in >>>> the non-overflow case. In many cases, it will be difficult or impossible >>>> for a compiler to generate code which is anywhere near as efficient as would >>>> be possible if the language supported better overflow semantics. >>> >>> A compiler can (as I did with lcc-win) test always the overflow flag >>> after each operation that can generate an overflow condition. >> >> What if the hardware does not support an overflow flag? >> (Example: the DEC Alpha). >> > > The DEC Alpha supports testing for overflow. > > I wrote in this newsgroup on Sep 1 2009: > ><quote> > > DEC Alpha assembler manual page 23 (in the pdf file) > > > > "Overflow exceptions occur when arithmetic operations compute signed > > values and the destination lacks the precision to store the result" > > > > Page 48 lists the assembler operations and we have: > > > > ... > > Add longword (with overflow): addlv > > Multiply longword (with overflow) mullv ><end quote> > > At that time, a certain Mr Carmody started that thing just like you. Six > and half years have passed and still the same people oppose any > progress, any change with the same falsehoods. > > I repeat: > > The dec alpja has an overflow flag that will be triggered by suitable > opcodes that do NOT discard the value of that flag but write it, so you > can test it in the next instructions. > > The dec alpha had already disappeared when Carmody brought that bright > idea... Six and half years later and it has not been rebuilt... > > Other processors (risc machines) do the same. > > But you can still repeat the same nonsense and I still can tell you > > GO FUCK! > > This ensures that hodgin will not answer this message since he said that > he will never answer to a post with obscenities. Too bad we can't discuss technical matters in a civil way, but, okay, so be it. The 'overflow' variants the of arithmetic instructions (addlv, mullv, sublv etc.) signal an overflow exception, but they do not set an overflow flag, so I don't see how one could efficiently "test the overflow flag".
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 11:45 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o28p5p$lhj$1@dont-email.me> |
| In reply to | #98235 |
Le 07/12/2016 à 08:41, Ike Naar a écrit : > > The 'overflow' variants the of arithmetic instructions (addlv, > mullv, sublv etc.) signal an overflow exception, but they do not > set an overflow flag, so I don't see how one could efficiently > "test the overflow flag". > So what? Any overflow trap sets that flag! And it would be simpler than what I have to generate for the x86. In the x86 I have to generate the test and the jump. Using the dec alpha I wouldn't have to generate anything, just set the overflow signal to a function that does the appropiate thing. All the code I need to generate for doing the same thing would be superfluous.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 09:22 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <lnh96f3b97.fsf@kst-u.example.com> |
| In reply to | #98239 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 07/12/2016 á 08:41, Ike Naar a écrit :
>> The 'overflow' variants the of arithmetic instructions (addlv,
>> mullv, sublv etc.) signal an overflow exception, but they do not
>> set an overflow flag, so I don't see how one could efficiently
>> "test the overflow flag".
>
> So what?
> Any overflow trap sets that flag!
Sets what flag? My understanding (based mostly on reading this
discussion) is that the Alpha doesn't have a hardware "overflow flag".
Are you talking about dedicating some memory location for use as an
overflow flag, controlled by software?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web