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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 01:25 +0100 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <o2a978$1q8$1@dont-email.me> |
| In reply to | #98324 |
Le 08/12/2016 à 00:32, Keith Thompson a écrit : > Sets what flag? My understanding (based mostly on reading this > discussion) is that the Alpha doesn't have a hardware "overflow flag". No. Like many other processor it uses the opcodes to provoke an exception, meaning that if you want overflow check with special instructions, you have caught the overflow signal and have a routine that could give some information like the line and file of the fault. The signal points to an encoded information about the operation that was being executed at the point of failure. What to do? 1) Restart. A prespecified restart point cleans up what it is possible to cleanup, maybe logs the incident, and goes on. 2) Rewind the stack until a prespecified catch. This would execute a list of operations that should be part of the cleanup. This can be avoided if software uses global memory pools for each restartable module. Instead of executing all those free(suchAndsuch) we just reset the memory pool and declare all memory as unwritten. 3) The default: crash. A crash is a good starting point for getting bugs out. If you want to check for overflows, any overflow should crash.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 16:36 -0800 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <a91d571d-b28f-4a00-b9ab-775c0e92421a@googlegroups.com> |
| In reply to | #98327 |
On Wednesday, December 7, 2016 at 6:25:42 PM UTC-6, jacobnavia wrote: > What to do? > > 1) Restart. A prespecified restart point cleans up what it is possible > to cleanup, maybe logs the incident, and goes on. > > 2) Rewind the stack until a prespecified catch. This would execute a > list of operations that should be part of the cleanup. This can be > avoided if software uses global memory pools for each restartable > module. Instead of executing all those free(suchAndsuch) we just reset > the memory pool and declare all memory as unwritten. > > 3) The default: crash. > A crash is a good starting point for getting bugs out. If you want to > check for overflows, any overflow should crash. 4. Set some global-per-thread error flag which an application could check to discover if an overflow occurred. This approach will be much more amenable to optimization than approaches which disrupt program flow, since it won't cause operations to be left partially-completed. In many cases, provided that overflows don't have any side effects aside from producing a possibly-meaningless value it won't matter if they get handled immediately, or simply result in a program indicating at the end that a calculation error occurred someplace and the reported results should not be trusted. In places where an operation must not be performed if an as-yet-unreported overflow has occurred, code can check if an overflow has occurred and cancel the operation if so.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 17:09 -0800 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <lntwafz0oh.fsf@kst-u.example.com> |
| In reply to | #98327 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 08/12/2016 á 00:32, Keith Thompson a écrit :
>> Sets what flag? My understanding (based mostly on reading this
>> discussion) is that the Alpha doesn't have a hardware "overflow flag".
>
> No. Like many other processor it uses the opcodes to provoke an
> exception, meaning that if you want overflow check with special
> instructions, you have caught the overflow signal and have a routine
> that could give some information like the line and file of the fault.
Upthread, you said: "Any overflow trap sets that flag!" Was that
statement incorrect?
In the past, you've talked about ways to give a C program access to an
"overflow flag". Are you now talking more generally about ways to
detect and handle overflow, without necessarily using an actual flag?
Or do you propose to create a flag in software on systems that don't
have it in hardware?
If you're modifying what you said earlier, that's fine. I'm just trying
to understand what you're saying.
[...]
--
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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 10:28 +0100 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <o2b910$c3r$1@dont-email.me> |
| In reply to | #98330 |
Le 08/12/2016 à 02:09, Keith Thompson a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: >> Le 08/12/2016 á 00:32, Keith Thompson a écrit : >>> Sets what flag? My understanding (based mostly on reading this >>> discussion) is that the Alpha doesn't have a hardware "overflow flag". >> >> No. Like many other processor it uses the opcodes to provoke an >> exception, meaning that if you want overflow check with special >> instructions, you have caught the overflow signal and have a routine >> that could give some information like the line and file of the fault. > > Upthread, you said: "Any overflow trap sets that flag!" Was that > statement incorrect? > I think understanding that is beyond your abilities Thompson. The only objective of your posts is to point out some imperfection in what I write to ask with your habitual cynism: Did I understand incorrectly sir? Your were wrong there? > In the past, you've talked about ways to give a C program access to an > "overflow flag". Are you now talking more generally about ways to > detect and handle overflow, without necessarily using an actual flag? With access to the overflow flag I was speaking about many processors that have an actual flag. RISC machines generate traps or whatever. That was never the point. The point is to give access to the programmer to handling that situation. > Or do you propose to create a flag in software on systems that don't > have it in hardware? > I have mentioned the way it is done in lcc-win. > If you're modifying what you said earlier, that's fine. I'm just trying > to understand what you're saying. > "I am just trying to understand"... since six and halmf years some people here do not get it. I am wasting my time here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-08 08:34 -0800 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <lnpol2z8g1.fsf@kst-u.example.com> |
| In reply to | #98347 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 08/12/2016 á 02:09, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 08/12/2016 á 00:32, Keith Thompson a écrit :
>>>> Sets what flag? My understanding (based mostly on reading this
>>>> discussion) is that the Alpha doesn't have a hardware "overflow flag".
>>>
>>> No. Like many other processor it uses the opcodes to provoke an
>>> exception, meaning that if you want overflow check with special
>>> instructions, you have caught the overflow signal and have a routine
>>> that could give some information like the line and file of the fault.
>>
>> Upthread, you said: "Any overflow trap sets that flag!" Was that
>> statement incorrect?
>
> I think understanding that is beyond your abilities Thompson.
Here we go again.
> The only objective of your posts is to point out some imperfection in
> what I write to ask with your habitual cynism:
No, the objective of my post was to ask you a question, to clarify
something you wrote earlier that I'm not sure I understood. What is
beyond my understanding is why you insist on treating a simple question
as an insult.
> Did I understand incorrectly sir?
Obviously.
> Your were wrong there?
What?
>> In the past, you've talked about ways to give a C program access to an
>> "overflow flag". Are you now talking more generally about ways to
>> detect and handle overflow, without necessarily using an actual flag?
>
> With access to the overflow flag I was speaking about many processors
> that have an actual flag.
Yes, and I was asking about machines that don't have an actual flag.
> RISC machines generate traps or whatever. That was never the point. The
> point is to give access to the programmer to handling that situation.
Fine, how do you propose to give that access on a system that doesn't
have an actual flag? Given a compiler that provides the features you
suggest, can I write code that will work correctly on, say, both x86 and
alpha?
>> Or do you propose to create a flag in software on systems that don't
>> have it in hardware?
>
> I have mentioned the way it is done in lcc-win.
If you've discussed it in detail, I don't recall. You've talked about
setting a flag. How would that work on Alpha?
>> If you're modifying what you said earlier, that's fine. I'm just trying
>> to understand what you're saying.
>
> "I am just trying to understand"... since six and halmf years some
> people here do not get it.
No, I'm asking a specific question about something you wrote a few days
ago.
> I am wasting my time here.
Stop being so damned paranoid. I am not your enemy.
If you want to discuss this further, you can reply to the e-mail I sent
you on November 18. I expect you'll continue to ignore it, but I'm
prepared to be pleasantly surprised.
--
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]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-08 20:08 +0000 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <87lgvqw5du.fsf@gmail.com> |
| In reply to | #98388 |
Keith Thompson <kst-u@mib.org> writes: >> >> I think understanding that is beyond your abilities Thompson. > > Here we go again. Particularly ironic, given that Jacob's first response to any disagreement is to accuse everyone of having a personal grudge against him.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 10:24 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2b8ql$bhk$1@dont-email.me> |
| In reply to | #98322 |
On 08/12/16 00:22, jacobnavia wrote: >>> I think Jacob may not understand what "regular" means. Jacob, a >>> "regular" is someone who posts many articles over a lengthy period of >>> time. That includes you, Jacob. You /are/ a regular. >>> >> > > Look guys, I am repeating what I said six and half years ago and it is > distressing that all the refuted arguments come again as nothing ever > would move in this group. > > 1) You all know very well what I mean when I say that C has weakness > that should be adressed. In my discussion I present technical arguments > that are not refuted. > > 2) All machines can check for overflow. For instance, Mr Brown proposed > for MIPS: > > #addition... > addu $t0, $t1, $t2 # caution, don't trap! > xor $t3, $t1, $t2 # if signs differ $t3 < 0 > slt $t3, $t3, $zero > bne $t3, $zero, No_overflow #signs differ > xor $t3,$t0,$t1 # signs match, check result > slt $t3,$t3,$zero #sum sign different > bne $t3,$zero, Overflow.. > > That's when you buy a machine like that... Others are better, as > everybody knows. Some machines do not have flags to test but any > overflow is rerouted to an interrupt routine that probably the software > can adapt. It is maybe expensive but the language should provide means > of doing that fairly easily, by default if you want. > > Any overflow is a signal that is rerouted to code to treat an overflow > condition. You can assign priorities to pieces of the software, meaning > that if an overflow occurs because of data noise, or electrical > problems, or just variables that weren't sized correctly there is a > "restart" point for that module. > > C allows for a standard way of treating floating point overflow but not > integer overflow. This is no longer justified. > > Now, how could that be done? > > Let's discuss that for once? > > OK? > 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. I agree that overflow checking can sometimes be useful for testing and debugging. If you want to implement it, there are various methods: 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. 2. Make it machine-dependent and support trap-on-overflow when supported. This has low cost to the user - the only limitation is to prevent optimisations and code re-arrangement. You get a "crash to debugger" when overflow happens, which can be very helpful in tracing bugs. 3. Make it explicit in the code, such as is done with gcc's __builtin_add_overflow extension. Users can check for overflow as needed. The compiler can generate tight code (using the overflow flag if supported, or weird sequences like the MIPS one above - there is always a way). That keeps everything explicit, has minimal overhead, and lets user code handle overflow at run-time. But it's ugly in the user code. (Special types and operator overloading compiler extensions might let you do this in a neater way.) 4. Implement some sort of exception mechanism, and special types or classes of integers for which overflow checking is enabled. This has the advantage of being implementable as classes in existing C++ without changes to the compiler. The disadvantage, of course, is that it is C++ and not C. 5. I expect there are more ideas ...
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 15:49 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2brr5$at4$1@dont-email.me> |
| In reply to | #98346 |
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! 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". Yes, I see my error. Why complicate the mathematics beyo,nd first grade? And of course I should insist that what yopu say is perfectly true, even if I have posted many times that it is possible without so much effort to see tha ddition operation as two operations; the addition and the check, that are treated as a single unit. But that is too sophsticated. Let's forget overflow and nasty reality. And when > dealing with "big" processors, overflow checking means you can't do > things in parallel using SIMD or vector instructions. > YES! I repeat: who cares about result? What is important is that we optimize everything. > I agree that overflow checking can sometimes be useful for testing and > debugging. If you want to implement it, there are various methods: > Yes, testing and debugging ONLY. Overflows never happen in the real world. > 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. > Yeah overflow checking is not possible and will never work anyway. > 2. Make it machine-dependent and support trap-on-overflow when > supported. This has low cost to the user - the only limitation is to > prevent optimisations and code re-arrangement. You get a "crash to > debugger" when overflow happens, which can be very helpful in tracing bugs. > Yes, it MIGHT be helpful. > 3. Make it explicit in the code, such as is done with gcc's > __builtin_add_overflow extension. YES! GCC is the only true and fast compiler. Forget about the traitors to the cause that happen to use something else. Why do they get into trouble? GCC IS THE BEST COMPILER IN THE WORLD. Users can check for overflow as > needed. The compiler can generate tight code (using the overflow flag > if supported, or weird sequences like the MIPS one above - there is > always a way). That keeps everything explicit, has minimal overhead, > and lets user code handle overflow at run-time. Exactly. GCC IS THE SOLUTION FOR EVERYTHING. How could I have forgotten such an elementary truth? But it's ugly in the > user code. (Special types and operator overloading compiler extensions > might let you do this in a neater way.) > Yes. Never even consider the possibility of the C language giving acces to such an important thing. Let's use a gcc extension. That is much more portable. > 4. Implement some sort of exception mechanism, and special types or > classes of integers for which overflow checking is enabled. This has > the advantage of being implementable as classes in existing C++ without > changes to the compiler. The disadvantage, of course, is that it is C++ > and not C. > AND AFTER USING GCC, change to C++!!! THAT IS THE SOLUTION OF COURSE! > 5. I expect there are more ideas ... > No. Everything has been said and done.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-08 15:23 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <87lgvqbg2x.fsf@bsb.me.uk> |
| In reply to | #98365 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 08/12/2016 à 10:24, David Brown a écrit : <snip> (I've cut David text because whatever it said, your reply is truly extraordinary.) > Yes. I see my error. Who cares about the results? What is important is > that they are done FAST! <snip> > But that is too sophsticated. Let's forget overflow and nasty reality. <snip> > I repeat: who cares about result? What is important is that we > optimize everything. <snip> > Yes, testing and debugging ONLY. Overflows never happen in the real world. <snip> > GCC is the only true and fast compiler. Forget about the traitors to > the cause that happen to use something else. Why do they get into > trouble? > > GCC IS THE BEST COMPILER IN THE WORLD. <snip> ...and so on in the same vein. You say you want a technical discussion about overflow checking but when someone writes a reasonable well-thought out technical post you reply with nothing but sarcasm. Even if you think what David wrote was completely wrong and misguided you could calmly say why, if not for the present discussion, at least for the benefit of others who might come across this thread later. I also made what I considered to be a technical reply but now I'm glad you simply ignored it. I was going to make another because I think the question is an interesting one but I don't think there is any point. Do you? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 16:58 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2bvs6$ojd$1@dont-email.me> |
| In reply to | #98370 |
Le 08/12/2016 à 16:23, Ben Bacarisse a écrit : also made what I considered to be a technical reply but now I'm glad > you simply ignored it. I was going to make another because I think the > question is an interesting one but I don't think there is any point. Do > you? > No. There isn't any point in discussing anything here. Let's come back to mr hodgin and his calive. That will solve everything
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-08 18:57 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <87a8c6b65g.fsf@bsb.me.uk> |
| In reply to | #98378 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 08/12/2016 à 16:23, Ben Bacarisse a écrit : > also made what I considered to be a technical reply but now I'm glad >> you simply ignored it. I was going to make another because I think the >> question is an interesting one but I don't think there is any point. Do >> you? >> > > No. There isn't any point in discussing anything here. OK. > Let's come back to mr hodgin and his calive. That will solve everything Not for me thanks, but be my guest. Maybe someone else will want to discuss overflow handling in C. There was a post about how it was done in COBOL but COBOL is such a special case I don't think it carries over to C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-08 15:29 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2bu6r$iv3$1@dont-email.me> |
| In reply to | #98365 |
On 08/12/16 14:49, jacobnavia 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, of course the results matter. Why not try to reason with David
without resorting to hyperbole? The results are important, and economy
is important too. If the results don't have to be correct, they can be
established in zero time. And if the results aren't available in time,
their correctness is irrelevant. So, ideally, what we want is the right
results as fast as possible. Consequently, it makes sense for programs
to check for overflow when it is likely to cause problems, but not when
it isn't. Consider the following code:
#define MAX_COLS 16
for(i = 0; i < MAX_COLS; i++)
{
count[i] = !!r[i] + !!g[i] + !!b[i];
}
There is *no possibility* that *any* of those additions can overflow. So
why check?
> 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".
>
> Yes, I see my error. Why complicate the mathematics beyo,nd first grade?
> And of course I should insist that what yopu say is perfectly true, even
> if I have posted many times that it is possible without so much effort
> to see tha ddition operation as two operations; the addition and the
> check, that are treated as a single unit.
>
> But that is too sophsticated. Let's forget overflow and nasty reality.
Why the sarcasm? What's the point? Why not just present your arguments
clearly and rationally, and discuss them calmly and sensibly?
> And when
>> dealing with "big" processors, overflow checking means you can't do
>> things in parallel using SIMD or vector instructions.
>>
>
> YES!
>
> I repeat: who cares about result? What is important is that we optimize
> everything.
He's not saying that. He's saying that an overflow check on every single
operation is simply not necessary if the programmer exercises due care
to add his own checks in circumstances where an overflow might occur.
And, just in case the programmer /isn't/ exercising due care, there's no
reason why the implementation shouldn't check overflow anyway, just so
long as /when/ it does so is in the hands of the programmer (or the tester).
>> I agree that overflow checking can sometimes be useful for testing and
>> debugging. If you want to implement it, there are various methods:
>>
>
> Yes, testing and debugging ONLY. Overflows never happen in the real world.
Well, the whole point of testing is to find bugs, and that certainly
includes overflow problems.
>> 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.
>>
>
> Yeah overflow checking is not possible and will never work anyway.
I don't think he's claiming that overflow checking is not possible. I
think he's claiming that it isn't always a good idea. Why try to extend
his position like that?
>> 2. Make it machine-dependent and support trap-on-overflow when
>> supported. This has low cost to the user - the only limitation is to
>> prevent optimisations and code re-arrangement. You get a "crash to
>> debugger" when overflow happens, which can be very helpful in tracing
>> bugs.
>>
>
> Yes, it MIGHT be helpful.
Indeed. So why do you think he's claiming otherwise?
>> 3. Make it explicit in the code, such as is done with gcc's
>> __builtin_add_overflow extension.
>
> YES!
> GCC is the only true and fast compiler. Forget about the traitors to the
> cause that happen to use something else. Why do they get into trouble?
He hasn't said that GCC is the only true and fast compiler. You have,
but he hasn't. As for "traitors to the cause", well, that certainly
includes me, because I use a number of compilers. So what?
All he's saying is that, of the several ways for implementing overflow
checking, making it explicit in the code is one of those ways. He only
mentioned gcc as an example of how it can be done.
> GCC IS THE BEST COMPILER IN THE WORLD.
He hasn't said so. You have, but he hasn't.
> Users can check for overflow as
>> needed. The compiler can generate tight code (using the overflow flag
>> if supported, or weird sequences like the MIPS one above - there is
>> always a way). That keeps everything explicit, has minimal overhead,
>> and lets user code handle overflow at run-time.
>
> Exactly. GCC IS THE SOLUTION FOR EVERYTHING. How could I have forgotten
> such an elementary truth?
That isn't what he said.
> But it's ugly in the
>> user code. (Special types and operator overloading compiler extensions
>> might let you do this in a neater way.)
>>
>
> Yes. Never even consider the possibility of the C language giving acces
> to such an important thing. Let's use a gcc extension. That is much more
> portable.
Well, it probably is, given that gcc is implemented on so many platforms
and implementors are so slow to adopt changes to the standard. BUT that
isn't what he's saying. He's saying that one way of checking for
overflow is to leave it to the user programmer. That's my preferred
route, but he's suggesting that it has disadvantages, which it does. Did
you not see that his point was a point in favour of your case, not a
point against it?
>> 4. Implement some sort of exception mechanism, and special types or
>> classes of integers for which overflow checking is enabled. This has
>> the advantage of being implementable as classes in existing C++ without
>> changes to the compiler. The disadvantage, of course, is that it is C++
>> and not C.
>>
>
> AND AFTER USING GCC, change to C++!!!
> THAT IS THE SOLUTION OF COURSE!
Did you not see that he's just including that possibility for
completeness, and that he is not arguing for a switch to C++, which he
calls a /dis/advantage, not an advantage?
>
>
>> 5. I expect there are more ideas ...
>>
>
> No. Everything has been said and done.
What do you want people to say when you come up with a new idea? Are you
seeking discussion, or rubber-stamp approval? Would you feel better if
people responded to every idea of yours with "yes, Jacob, I'm sure that
will be lovely"? What would be the point of that? Discussion is healthy,
and you would benefit from it much more if you could see that.
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 17:09 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c0h5$r82$1@dont-email.me> |
| In reply to | #98371 |
Look Mr Heathfield, I can't stand this any more. Let's stop. C is PERFECT AS IT IS, let's go on using C89 and forget about overflow. He said: He's saying that an overflow check on every single operation is simply not necessary if the programmer exercises due care to add his own checks in circumstances where an overflow might occur. Now we have the solution: it is up to the programmer of course. We discussed here the same thing six and half years ago because a first discussion I started on Sep 1, 2009. The same arguments are being marshalled again and again. OK. YOU WIN!
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-08 16:41 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c2e2$2mi$1@dont-email.me> |
| In reply to | #98381 |
On 08/12/16 16:09, jacobnavia wrote: > Look Mr Heathfield, I can't stand this any more. Let's stop. C is > PERFECT AS IT IS, let's go on using C89 and forget about overflow. Well, if that's truly what you believe, then okay, but I disagree that C is perfect as it is, and I certainly disagree that we should forget about overflow. > He said: > > He's saying that an overflow check on every single operation is simply > not necessary if the programmer exercises due care to add his own checks > in circumstances where an overflow might occur. You are conflating two of his points. He's actually saying that in /some/ cases an overflow check is redundant, and he's right. I gave an example of such code. > Now we have the solution: it is up to the programmer of course. That's one solution. Another solution is for the implementation to add a runtime check, and this is what you are proposing. My own view is that such a check would be a good thing /provided/ it is controllable by the programmer in some way --- either through a command line switch (for code that is not able, for portability reasons, to use extensions) or, for code that does have that freedom, perhaps a pragma: #pragma LCC_WIN OC_Enable and #pragma LCC_WIN OC_Disable (or whatever your pragma naming convention might be). > We discussed here the same thing six and half years ago because a first > discussion I started on Sep 1, 2009. The same arguments are being > marshalled again and again. Well, what did you expect? That somehow overflow checking is different now than it was then? > OK. > > YOU WIN! As long as you continue to think of it as a contest, we all lose. -- 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 17:04 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c08k$q4t$1@dont-email.me> |
| In reply to | #98365 |
On 08/12/16 15:49, jacobnavia 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! Eh, no, that is /not/ the point. But if I want to add x and y, and I know that this will not cause an overflow because I know what I am doing and I know the range of values I am using, then I know that x + y will not overflow. I certainly do not want extra code and extra runtime wasted in needless and pointless checking of overflow. 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. In this case, you don't want extra code at run-time - you want a compile-time diagnostic if possible, and a "crash on overflow" trap if possible. You might not be able to get this behaviour, of course, so you might compile in "I'm debugging - check everything, even if it's slow" mode and then "I believe the code works - run quickly" mode. If the code is correct, you don't have problems with overflow. If you are writing correct code, you should not pay the price for other people's slack coding. In my own code, I don't get overflows. If there is something that might overflow, I check it /before/ the calculation, or I use bigger types and check that way. I know that for my development, checking for overflow would be a /bad/ thing and it is not a feature I would want from the compiler. Of course, I also know that that is the way /I/ develop code, and others can find it useful. Since most of my programs are small, for small embedded systems, I am much less reliant on other people's code than most developers are - thus I have more knowledge about the ranges of my data than others might have. So the question is highly relevant - is it actually useful to check for overflow? Who would want the feature, and why? Until you have considered that properly, rather than sarcastically and dismissively, you cannot have any idea about the best way to handle overflow. > > > 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". > > Yes, I see my error. Why complicate the mathematics beyo,nd first grade? You are more concerned with being snide than thinking about what I am saying. It is not uncommon for a compiler to simplify expressions based on the normal rules of arithmetic. While it is unlikely that a programmer would write "x = a + b - a;" directly, it can certainly occur as a result of macros, inlining, constant propagation, strength reduction, and other common optimising passes. If you have to check for overflow, this must be done as "tmp = a + b; checkForOverFlow(); tmp -= a; checkForOverflow(); x = tmp;" instead of "x = b;". That is just a little artificial example - I am sure you can think of many realistic ones if you try. > And of course I should insist that what yopu say is perfectly true, even > if I have posted many times that it is possible without so much effort > to see tha ddition operation as two operations; the addition and the > check, that are treated as a single unit. > > But that is too sophsticated. Let's forget overflow and nasty reality. > I prefer safe and reliable reality where there is no overflow, rather than pretend safety where you think you can ignore overflow "because the compiler will deal with it". > And when >> dealing with "big" processors, overflow checking means you can't do >> things in parallel using SIMD or vector instructions. >> > > YES! > > I repeat: who cares about result? What is important is that we optimize > everything. And I repeat - write your code correctly, and it gives the correct result without overflowing. Overflow detection is only a matter of aiding debugging (though that is clearly a good aim). Why do you think cpu designers and manufacturers have put so much effort into vector processing? Why do tool vendors and library authors put so much effort into using these vector units? Is it because they all disregard the importance of correct results and correct code? Or is it because they know how to write code that does not have the problems you are trying to detect? > >> I agree that overflow checking can sometimes be useful for testing and >> debugging. If you want to implement it, there are various methods: >> > > Yes, testing and debugging ONLY. Overflows never happen in the real world. Overflows may happen if real world code has bugs. But they are only one of a thousand other types of bugs which will not be caught. > >> 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. >> > > Yeah overflow checking is not possible and will never work anyway. I am telling you some of the disadvantages of it, not that it will not work. > >> 2. Make it machine-dependent and support trap-on-overflow when >> supported. This has low cost to the user - the only limitation is to >> prevent optimisations and code re-arrangement. You get a "crash to >> debugger" when overflow happens, which can be very helpful in tracing >> bugs. >> > > Yes, it MIGHT be helpful. Indeed. Usually, it is not helpful. And certainly there are many other checks that a compiler can do at compile-time and at run-time that are going to be more helpful at finding bugs than overflow checking. Thus you should ask yourself if this really is something you want to spend the effort on - or would your users be better served by you spending your time on other features? Overflow checking can sometimes be helpful in debugging - but it is not /that/ useful, and it is not a free lunch. > >> 3. Make it explicit in the code, such as is done with gcc's >> __builtin_add_overflow extension. > > YES! > GCC is the only true and fast compiler. Forget about the traitors to the > cause that happen to use something else. Why do they get into trouble? > > GCC IS THE BEST COMPILER IN THE WORLD. In my opinion, gcc /is/ currently the best compiler in the world - at least for /my/ needs. But that is irrelevant here - I show it as an example of a way to make overflow checking explicit. I could have referred to the same functions in clang - would that have made you happy? None of the other compilers I am familiar with have similar functions, so I can't give other examples - but I am sure that tools such as Intel's icc and MSVC have something equivalent. > > > Users can check for overflow as >> needed. The compiler can generate tight code (using the overflow flag >> if supported, or weird sequences like the MIPS one above - there is >> always a way). That keeps everything explicit, has minimal overhead, >> and lets user code handle overflow at run-time. > > Exactly. GCC IS THE SOLUTION FOR EVERYTHING. How could I have forgotten > such an elementary truth? Well, the gcc developers are usually polite and helpful, and when someone gives them suggestions for improving their tools they listen and try to understand - and if they reject the idea, they do so politely. It seems the same does not apply to all compiler developers. So let me put it this way for you. I have no interest in lccwin. I would not consider using it. I would not consider recommending it to anyone for any purpose. And the main reason for that is that the development and support is done by an angry little man who feels it is more important to attack people, cry about any references to other compilers, and declare that everyone involved in C development is on a personal mission to harm him and his business. You don't have to treat me like a paying customer - but when I freely offer help and advice, I think a little common decency and respect is in order. > > > But it's ugly in the >> user code. (Special types and operator overloading compiler extensions >> might let you do this in a neater way.) >> > > Yes. Never even consider the possibility of the C language giving acces > to such an important thing. Let's use a gcc extension. That is much more > portable. > The C language, as a standard, will /never/ give access to overflow information. If you don't understand that, or don't understand why, you can start by re-reading my posts. Then you can look at the standards themselves, and think about what C really is and how it is used. With enough thought, hopefully you will realise that the C standards will not support overflow detection. But they /do/ support the use of implementation-specific extensions, allowing people to make compilers with extra features - such as overflow detection. And if you open your eyes to the wider world, then you will see that despite your hatred it really is gcc that is the closest thing to a de-facto standard here, and is followed by other compilers. So yes, if you want to add overflow detection in a somewhat portable manner, then you should implement the gcc extensions here. > >> 4. Implement some sort of exception mechanism, and special types or >> classes of integers for which overflow checking is enabled. This has >> the advantage of being implementable as classes in existing C++ without >> changes to the compiler. The disadvantage, of course, is that it is C++ >> and not C. >> > > AND AFTER USING GCC, change to C++!!! > THAT IS THE SOLUTION OF COURSE! Certainly that is what /I/ would do if I wanted a need and efficient overflow detection mechanism. But then, I am a practical man, and I will use the tool that does the job best - I won't froth at the mouth every time someone mentions a different programming language. > > >> 5. I expect there are more ideas ... >> > > No. Everything has been said and done. > >
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 17:15 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c0st$sec$1@dont-email.me> |
| In reply to | #98380 |
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. Look there is no point in discussing with you. 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. You win.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-12-08 11:34 -0500 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c20i$ulr$2@dont-email.me> |
| In reply to | #98383 |
On Thursday December 8 2016 11:15, in comp.lang.c, "jacobnavia" <jacob@jacob.remcomp.fr> 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. Jacob, I asked earlier (in Message-ID: <o27bm1$mgq$1@dont-email.me>), and didn't see an answer from you. I'll ask again. > Jacob, just a question... > > Why not have your code generate a signal (like the floatingpoint error > signal SIGFPE, but for integer operations) when an arithmetic overflow > occurs? That way, arithmetic overflow could be handled in the same manner as > floatingpoint exceptions and leave the programmer in charge of whether (and > how) to handle the occurrence. Yes, it would be a non-standard extension of > C's asynchronous signal handling facilities, but would fit with both the > current programming practice that ignore overflows, /and/ the current > programming practice that handles asynchronous math failures through > signals. > > What do you think? Is this approach worthwhile? I will add to this one more thing: this proposal seems to fit nicely with platforms that do not expose an "overflow flag", but instead execute a trap on overflow. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 18:40 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2c5s0$fml$1@dont-email.me> |
| In reply to | #98389 |
Le 08/12/2016 à 17:34, Lew Pitcher a écrit : > On Thursday December 8 2016 11:15, in comp.lang.c, "jacobnavia" > <jacob@jacob.remcomp.fr> 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. > > Jacob, I asked earlier (in Message-ID: <o27bm1$mgq$1@dont-email.me>), and > didn't see an answer from you. I'll ask again. > I did try to follow your idea, and to my surprised, when I typed man signal in my linux system I got this The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. The man pages said that signal() is not thread safe. I did not undertand exactly why, and then tried to figure more about that problem (or lack of it) and forgot to post the results of my investigations.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 10:00 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <c08b2c84-da39-4219-98e7-2f9ed176f014@googlegroups.com> |
| In reply to | #98393 |
On Thursday, December 8, 2016 at 11:40:40 AM UTC-6, jacobnavia wrote:
> Le 08/12/2016 à 17:34, Lew Pitcher a écrit :
> > On Thursday December 8 2016 11:15, in comp.lang.c, "jacobnavia" wrote:
> >> C gives access to overflow information for floating point overflow.
> I did try to follow your idea, and to my surprised, when I typed
>
> man signal
>
...
> The man pages said that signal() is not thread safe. I did not undertand
> exactly why, and then tried to figure more about that problem (or lack
> of it) and forgot to post the results of my investigations.
Beyond SIGFPE, many C implementations support Annex F which allows for
programs to safely perform calculations which may overflow, and in most
cases defer overflow checking until the end. There are a few cases where
overflow may result in seemingly-valid but nonsensical results (e.g.
double x = someValue;
double y = (x+x)/x; // Should arithmetically be 2.0
double z = 1/y; // Should arithmetically be 0.5
the calculation of z should yield 0.5, precisely, but if Annex F overflow
occurs it will yield 0.0 with no indication that anything went wrong) but
for the most part having overflow yield a special non-numeric value is a
good approach.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-08 19:05 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <874m2eb5sn.fsf@bsb.me.uk> |
| In reply to | #98389 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Thursday December 8 2016 11:15, in comp.lang.c, "jacobnavia" > <jacob@jacob.remcomp.fr> 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. > > Jacob, I asked earlier (in Message-ID: <o27bm1$mgq$1@dont-email.me>), and > didn't see an answer from you. I'll ask again. > >> Jacob, just a question... >> >> Why not have your code generate a signal (like the floatingpoint error >> signal SIGFPE, but for integer operations) when an arithmetic overflow >> occurs? That way, arithmetic overflow could be handled in the same manner as >> floatingpoint exceptions and leave the programmer in charge of whether (and >> how) to handle the occurrence. Yes, it would be a non-standard extension of >> C's asynchronous signal handling facilities, but would fit with both the >> current programming practice that ignore overflows, /and/ the current >> programming practice that handles asynchronous math failures through >> signals. >> >> What do you think? Is this approach worthwhile? I think the trouble with this is that C's signal handling is very weak. It would be hard work to do anything more useful than report the issue and exit. There's also the problem that on architectures which don't have signal-raising integer operations you might pay the price of checking all sort of perfectly innocent arithmetic operations so some mechanism to limit the scope of the checking would be useful. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web