Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #83803 > unrolled thread

c is unfinished

Back to article view | Back to comp.lang.c

Contents

  c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 12:52 -0700
    Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 13:05 -0700
      Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:25 -0700
        Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:28 -0700
    Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-13 15:20 -0500
      Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:15 -0700
        Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-14 07:27 -0500
          Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 12:47 +0000
            Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 06:50 -0700
              Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:04 -0700
          Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:23 -0700
    c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-13 14:17 -0700
      Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 08:57 -0400
        Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:06 -0700
          Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:23 -0700
            Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 10:28 -0400
              Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:06 -0700
                Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 15:26 +0000
                  Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:38 -0700
                    Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:15 -0700
                      Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:42 -0700
                    Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 16:23 +0000
                      Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 09:56 -0700
                        Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 10:03 -0700
                        Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:28 +0000
                          Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:08 -0700
                            Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 18:51 +0000
                    Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:10 +0000
                      Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:26 -0700
                        Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:55 +0000
                        Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:44 -0700
                          Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 08:59 +0100
                            Re: c is unfinished supercat@casperkitty.com - 2016-03-15 07:23 -0700
                              Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 15:31 +0100
                                Re: c is unfinished supercat@casperkitty.com - 2016-03-15 08:02 -0700
                                  Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:11 +0100
                                    Re: c is unfinished supercat@casperkitty.com - 2016-03-16 08:33 -0700
                  Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 09:40 +1300
                    Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 14:01 -0700
                      Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 15:33 -0700
                        Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 23:07 +0000
                          Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 16:27 -0700
                        Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:37 -0700
                    Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 21:07 +0000
                      Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 10:16 +1300
                        Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 22:05 +0000
                          Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:30 -0700
                            Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:39 -0700
                            Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:00 +0000
                              Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 18:09 -0700
                                Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:14 +0000
                                  Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 13:51 -0700
                                Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 10:01 +0100
                                  Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 17:07 -0700
                                    Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:26 +0100
                                      Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-16 13:28 -0700
                                  Re: c is unfinished Philip Lantz <prl@canterey.us> - 2016-03-15 20:03 -0700
                                    Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:52 +0100
                                  Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 20:39 +1300
                                    Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 09:14 +0100
                                      Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 22:40 +1300
                                        Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 12:46 +0100
                          Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 14:53 +1300
                            Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:17 +0000
                              Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 21:19 +1300
                        Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:16 -0700
                      Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:03 -0700
                Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 08:32 -0700
                Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 08:43 -0700
                Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 16:14 +0000
                  Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 10:01 -0700
                    Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:30 +0000
                    Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 10:57 -0700
                      Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:32 -0700
                        Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 12:12 -0700
                        Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:21 +0000
                        Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:16 +0000
                          Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:34 -0700
                            Re: c is unfinished Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:15 -0500
                              Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:05 -0700
                                Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 22:34 -0700
                          Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:17 -0700
                            Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-15 01:10 +0000
                      Re: c is unfinished supercat@casperkitty.com - 2016-03-14 12:03 -0700
                    Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:08 +0000
                      Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 13:01 -0700
                        Re: c is unfinished supercat@casperkitty.com - 2016-03-14 13:28 -0700
                        Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 14:25 -0700
                          Re: c is unfinished supercat@casperkitty.com - 2016-03-14 14:40 -0700
                          Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 14:44 -0700
                            Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:44 +0000
                            Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:26 -0700
        Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:09 -0700
    Re: c is unfinished Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2016-03-13 23:34 +0000
      Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:40 -0700
    Re: c is unfinished supercat@casperkitty.com - 2016-03-14 09:33 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#83890

W dniu poniedziałek, 14 marca 2016 17:15:43 UTC+1 użytkownik fir napisał:
>      call_api_1();
> if(call_api_1.err) //do smth

this combined approach may be good (i mean those above compined with handlers)

those above may be maybe more handy is someone want to do some recovery and has
more entry points  as in this case it is better to add a lot of ifs for each error point

well he could also use

void foo()
{
 on_error(err_in_api_Call1);
api_call_1();
 on_error(err_in_api_Call2);
api_call_2();
 on_error(err_in_api_Call3);
api_call_3();
}
 but still there is not avaliable of code flof management in foo by err handlers (someone coulod try to do it though)
soe

void foo()
{
 on_error(some_handelr);

api_call_1();
if(api_call_1.err) //...
api_call_2();
if(api_call_2.err) //...
api_call_3();
if(api_call_3.err) //...
}

may be more handy

gloabal and lazy  on_error(some_handelr_of_type_print_error_information_in_retry_dialog_box);
may be handy for some lazy people like me
where you could put this one line at the start of your main and never check any api call

[toc] | [prev] | [next] | [standalone]

#83888

On 14/03/16 15:38, Malcolm McLean wrote:
> On Monday, March 14, 2016 at 3:26:41 PM UTC, Richard Heathfield wrote:
>> On 14/03/16 15:06, Malcolm McLean wrote:
>>
>>> (Quick question, what happens if we make the image dimensions size_t?)
>>
>> Once you've fixed the code so that it works properly, nothing worse
>> happens with size_t than happens with int.
>>
> Of course we have a whizzy machine which traps on arithmetical overflow

Stop right there. We already discussed the pre-conditions, didn't we? As 
I pointed out in my previous reply, "Once it links, it won't work 
(because you forgot to check your pre-conditions)."

There is no substitute for getting the code right.

-- 
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]

#83891

On Monday, March 14, 2016 at 4:23:11 PM UTC, Richard Heathfield wrote:
> On 14/03/16 15:38, Malcolm McLean wrote:

> > Of course we have a whizzy machine which traps on arithmetical overflow
> 
> Stop right there. We already discussed the pre-conditions, didn't we? As 
> I pointed out in my previous reply, "Once it links, it won't work 
> (because you forgot to check your pre-conditions)."
> 
> There is no substitute for getting the code right.
> 
Yes there is.
That's try .. catch, with stuff like arithmetical overflow caught and handled.
If caller wants to create an image that is bigger than INT_MAX width * height *4,
it's pretty clearly an illegitimate request. So we either return NULL and shunt
the problem up, or we throw an exception.
Throwing the exception is easier, particularly as almost any function that
perform any sort of arithmetical operation on integers could possibly overflow.
 

[toc] | [prev] | [next] | [standalone]

#83893

W dniu poniedziałek, 14 marca 2016 17:56:53 UTC+1 użytkownik Malcolm McLean napisał:
> On Monday, March 14, 2016 at 4:23:11 PM UTC, Richard Heathfield wrote:
> > On 14/03/16 15:38, Malcolm McLean wrote:
> 
> > > Of course we have a whizzy machine which traps on arithmetical overflow
> > 
> > Stop right there. We already discussed the pre-conditions, didn't we? As 
> > I pointed out in my previous reply, "Once it links, it won't work 
> > (because you forgot to check your pre-conditions)."
> > 
> > There is no substitute for getting the code right.
> > 
> Yes there is.
> That's try .. catch, with stuff like arithmetical overflow caught and handled.
> If caller wants to create an image that is bigger than INT_MAX width * height *4,
> it's pretty clearly an illegitimate request. So we either return NULL and shunt
> the problem up, or we throw an exception.
> Throwing the exception is easier, particularly as almost any function that
> perform any sort of arithmetical operation on integers could possibly overflow.

rewrite throwing an exception into calling error handler an it will be clearer

[toc] | [prev] | [next] | [standalone]

#83894

On 14/03/16 16:56, Malcolm McLean wrote:
> On Monday, March 14, 2016 at 4:23:11 PM UTC, Richard Heathfield wrote:
>> On 14/03/16 15:38, Malcolm McLean wrote:
>
>>> Of course we have a whizzy machine which traps on arithmetical overflow
>>
>> Stop right there. We already discussed the pre-conditions, didn't we? As
>> I pointed out in my previous reply, "Once it links, it won't work
>> (because you forgot to check your pre-conditions)."
>>
>> There is no substitute for getting the code right.
>>
> Yes there is.

I rest my case, m'lud.

-- 
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]

#83898

On Monday, March 14, 2016 at 5:28:34 PM UTC, Richard Heathfield wrote:
> On 14/03/16 16:56, Malcolm McLean wrote:
> 
> >> There is no substitute for getting the code right.
> >>
> > Yes there is.
> 
> I rest my case, m'lud.
> 
A lot of engineering is about making things fault-tolerant.
As a first hurdle, obviously the plane has to fly if all the parts are to spec.
But what if one of the engines has a crack in a fan blade? Sometimes
there's nothing you can do - you've just got to accept that the result
will be a crash. But often, you can design it so that it can at least
keep airborne on only one engine. Or so that the pilot gets an "altitude,
altitude, altitude" message if he's too low, so that even if he's taken
his eye off the altimeter, or is drunk, or is a child because the real pilot
has had a heart attack, you've got a sporting chance of executing a 
landing.

Programs should work  reasonably correctly even if they contain errors.

[toc] | [prev] | [next] | [standalone]

#83908

On 14/03/16 18:08, Malcolm McLean wrote:
> On Monday, March 14, 2016 at 5:28:34 PM UTC, Richard Heathfield wrote:
>> On 14/03/16 16:56, Malcolm McLean wrote:
>>
>>>> There is no substitute for getting the code right.
>>>>
>>> Yes there is.
>>
>> I rest my case, m'lud.
>>
> A lot of engineering is about making things fault-tolerant.

Right. You anticipate that bad things will happen (e.g. a bird hits the 
fan) and you make sure that nothing worse happens (e.g. the engine falls 
off). In programming terms, you anticipate that bad things will happen 
(e.g. some idiot passes you negative values for width or height or both) 
and you make sure that nothing worse happens (e.g. the computer crashes).

You do that by intercepting bad data and dealing with it properly, not 
by ignoring it and hoping that your safety net's holes are small enough.

> Programs should work  reasonably correctly even if they contain errors.

Programs work a lot better if we try really hard not to put the errors 
into them in the first place.

You might conceivably have a case if the errors were easy to make and 
difficult to spot. Your example didn't qualify.

-- 
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]

#83941

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Monday, March 14, 2016 at 3:26:41 PM UTC, Richard Heathfield wrote:
> > On 14/03/16 15:06, Malcolm McLean wrote:
> >
> > > (Quick question, what happens if we make the image dimensions size_t?)
> > 
> > Once you've fixed the code so that it works properly, nothing worse 
> > happens with size_t than happens with int.
> > 
> Of course we have a whizzy machine which traps on arithmetical overflow
> and terminates the program with an error message (unless you've done 
> something outside the domain of C to intercept the error handler and
> do something else). 

I'd rather have a program that gives me a weird result if I do something
extreme, but continues to allow me to press CTRL-Z to go back to the
situation before my attempt, than one which crashes irreversably when I
do something that steps over a boundary I wasn't aware of - or when I
accidentally type a zero too many.
You, apparently, would rather lose your entire last hour's labour in the
same circumstances. Fair enough, you can have your random segfaults if
you want them, but keep away from my work. I want my programs to fail
_safe_.

Richard

[toc] | [prev] | [next] | [standalone]

#83962

On Monday, March 14, 2016 at 10:10:54 PM UTC, Richard Bos wrote:
> 
> I'd rather have a program that gives me a weird result if I do something
> extreme, but continues to allow me to press CTRL-Z to go back to the
> situation before my attempt, than one which crashes irreversably when I
> do something that steps over a boundary I wasn't aware of - or when I
> accidentally type a zero too many.
> You, apparently, would rather lose your entire last hour's labour in the
> same circumstances. Fair enough, you can have your random segfaults if
> you want them, but keep away from my work. I want my programs to fail
> _safe_.
>
It depends whether wrong results are better or worse than no results.
If you're playing space invaders, the worst thing you can do is to
terminate the program, that's guaranteed to spoil the game.
If the invaders follow the wrong attack pattern, the player
might not even notice.

If you're measuring out radioactive doses for a medical treatment,
you mustn't dispense the wrong dose. Which the program crashing
out with an error message isn't good, it's far preferable to the
alternative.

But there are lots of possibilities between those two extremes.

[toc] | [prev] | [next] | [standalone]

#83965

On 14/03/16 23:26, Malcolm McLean wrote:
> On Monday, March 14, 2016 at 10:10:54 PM UTC, Richard Bos wrote:

<snip>

>> You, apparently, would rather lose your entire last hour's labour in the
>> same circumstances. Fair enough, you can have your random segfaults if
>> you want them, but keep away from my work. I want my programs to fail
>> _safe_.
>>
> It depends whether wrong results are better or worse than no results.

Those aren't the only choices.

<snip>

-- 
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]

#83981

On Monday, March 14, 2016 at 6:26:34 PM UTC-5, Malcolm McLean wrote:
> It depends whether wrong results are better or worse than no results.
> If you're playing space invaders, the worst thing you can do is to
> terminate the program, that's guaranteed to spoil the game.
> If the invaders follow the wrong attack pattern, the player
> might not even notice.

Different programs are subject to different requirements, but I would suggest
that a very common set of requirements is:

   1. When given valid input, yield correct output, but...

   2. When given invalid input, don't expose security vulnerabilities.

A good language should let programmers focus their efforts on the first
requirement.  Dialects of C which can offer any sort of behavioral guarantees
on integer overflow can often achieve that (note that it doesn't even matter
much what the guarantees *are*--even abnormal program termination would in
many cases meet the second requirement), but those which aggressively
optimize based on UB do not.

I find it interesting that compiler options to trap on integer overflow seem
very rare, especially in the 16-bit world.  I suspect that's probably because
there's no mechanism in the language to have the interpretation of an inner
expression vary depending upon whether the result is used as a signed or
unsigned value.  Given something like:

    unsigned char x=...,y=...;
    unsigned int area = x*y;

the assignment will "just work" for all values of x and y on a typical
two's-complement system where integer overflow "wraps", even if temporary
values are allowed to exceed the range of "int", but enabling integer
overflow trapping without breaking a lot of code would require that the
compiler recognize that because the value of x*y is being used as unsigned
there's no reason to promote to a signed type [note that behavior in all
*defined* cases is identical regardless of whether x and y get promoted to
int or unsigned, and on typical implementations is identical even in those
cases where the Standard would not require it].

[toc] | [prev] | [next] | [standalone]

#83984

On 15/03/16 06:44, supercat@casperkitty.com wrote:
> On Monday, March 14, 2016 at 6:26:34 PM UTC-5, Malcolm McLean wrote:
>> It depends whether wrong results are better or worse than no results.
>> If you're playing space invaders, the worst thing you can do is to
>> terminate the program, that's guaranteed to spoil the game.
>> If the invaders follow the wrong attack pattern, the player
>> might not even notice.
> 
> Different programs are subject to different requirements, but I would suggest
> that a very common set of requirements is:
> 
>    1. When given valid input, yield correct output, but...
> 
>    2. When given invalid input, don't expose security vulnerabilities.
> 
> A good language should let programmers focus their efforts on the first
> requirement.  Dialects of C which can offer any sort of behavioral guarantees
> on integer overflow can often achieve that (note that it doesn't even matter
> much what the guarantees *are*--even abnormal program termination would in
> many cases meet the second requirement), but those which aggressively
> optimize based on UB do not.
> 
> I find it interesting that compiler options to trap on integer overflow seem
> very rare, especially in the 16-bit world.  I suspect that's probably because
> there's no mechanism in the language to have the interpretation of an inner
> expression vary depending upon whether the result is used as a signed or
> unsigned value.  Given something like:
> 
>     unsigned char x=...,y=...;
>     unsigned int area = x*y;
> 
> the assignment will "just work" for all values of x and y on a typical
> two's-complement system where integer overflow "wraps", even if temporary
> values are allowed to exceed the range of "int", but enabling integer
> overflow trapping without breaking a lot of code would require that the
> compiler recognize that because the value of x*y is being used as unsigned
> there's no reason to promote to a signed type [note that behavior in all
> *defined* cases is identical regardless of whether x and y get promoted to
> int or unsigned, and on typical implementations is identical even in those
> cases where the Standard would not require it].
> 

Detecting overflow is hard, and on most processors it is slow.  Not all
processors have appropriate instructions or flags, especially for things
like multiplication.  That means to detect overflow on 16x16->16 bit
multiplication, you need to do 16x16->32 and check the high word.  On
many processors (most RISC processors, I think), arithmetic instructions
will only update flags if you specifically choose the "set flags"
version of the instruction - and these cause pipeline stalls or
restrictions because you have a single bottle-neck flag register
affected by all such instructions.

Trying to get strict overflow also means that the compiler is much more
restricted in how it can organise and optimise expressions.  To take a
simple example, with everything as "int", as C stands the compiler can
optimise "(x * 4) / 2" to "x * 2" and then "x >> 1".  With overflow
checking, it would have to carry out the full multiply, check for
overflow, then do the shift.

Even at the best of times, you are replacing "op" with "op; jump if
overflow" - doubling the amount of work.  But with the issues above,
especially when using a modern processor, your arithmetic couple take
five to ten times as long.

[toc] | [prev] | [next] | [standalone]

#84017

On Tuesday, March 15, 2016 at 3:00:05 AM UTC-5, David Brown wrote:
> Trying to get strict overflow also means that the compiler is much more
> restricted in how it can organise and optimise expressions.  To take a
> simple example, with everything as "int", as C stands the compiler can
> optimise "(x * 4) / 2" to "x * 2" and then "x >> 1".  With overflow
> checking, it would have to carry out the full multiply, check for
> overflow, then do the shift.

If the semantics are such that the processor can perform a bunch of code and
then report at the end whether overflow may have produced an inaccurate
result, the compiler will have many more optimization opportunities than if
user-written code performs error handling.  Expressions such as the one you
list would be examples of reasons why having overflow checking in the
language would be a good thing if the semantics were defined such that a
compiler would be under no obligation to report "overflows" that did not
affect the numerical correctness of the result.  If user code performs
add_with_overflow_check(x,y) >> 1, a compiler will have no choice but to
check whether the addition of x+y overflows.  If instead the code is written
as (x+y)>>1 within a checked-integer context, a compiler which defines
>> as sign-extending would be free to simply use a "rotate right" to copy
the carry flag into the MSB of the result and ignore any "overflow" since
the numerically-correct result would be obtained in any case.

[toc] | [prev] | [next] | [standalone]

#84018

On 15/03/16 15:23, supercat@casperkitty.com wrote:
> On Tuesday, March 15, 2016 at 3:00:05 AM UTC-5, David Brown wrote:
>> Trying to get strict overflow also means that the compiler is much more
>> restricted in how it can organise and optimise expressions.  To take a
>> simple example, with everything as "int", as C stands the compiler can
>> optimise "(x * 4) / 2" to "x * 2" and then "x >> 1".  With overflow
>> checking, it would have to carry out the full multiply, check for
>> overflow, then do the shift.
> 
> If the semantics are such that the processor can perform a bunch of code and
> then report at the end whether overflow may have produced an inaccurate
> result, the compiler will have many more optimization opportunities than if
> user-written code performs error handling. 

That is sort-of true - /if/ that were the case for real processors (I
don't know of any that have appropriate "sticky overflow" bits).  And
even then, it would stop the compiler being able to make optimisations
that involve re-arranging and simplifying calculations (like the one
above).  It would just mean that the "jump if overflow flag set" would
be moved to the end of the sequence, instead of occurring after each
potentially overflowing operation.

> Expressions such as the one you
> list would be examples of reasons why having overflow checking in the
> language would be a good thing if the semantics were defined such that a
> compiler would be under no obligation to report "overflows" that did not
> affect the numerical correctness of the result.  If user code performs
> add_with_overflow_check(x,y) >> 1, a compiler will have no choice but to
> check whether the addition of x+y overflows.  If instead the code is written
> as (x+y)>>1 within a checked-integer context, a compiler which defines
>>> as sign-extending would be free to simply use a "rotate right" to copy
> the carry flag into the MSB of the result and ignore any "overflow" since
> the numerically-correct result would be obtained in any case.
> 

As always, compilers are free to implement additional checks or overflow
behaviour if they want.  Thus gcc has builtin functions to efficiently
handle signed arithmetic with overflow detection:

<https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html#Integer-Overflow-Builtins>

And as always, if you want these wrapped in a nice "checked integer"
type, you can use C++ and make one.  That would probably be more
constructive than complaining to this newsgroup about the same thing
again and again.

[toc] | [prev] | [next] | [standalone]

#84020

On Tuesday, March 15, 2016 at 9:32:00 AM UTC-5, David Brown wrote:
> That is sort-of true - /if/ that were the case for real processors (I
> don't know of any that have appropriate "sticky overflow" bits).  And
> even then, it would stop the compiler being able to make optimisations
> that involve re-arranging and simplifying calculations (like the one
> above).  It would just mean that the "jump if overflow flag set" would
> be moved to the end of the sequence, instead of occurring after each
> potentially overflowing operation.

There's no need for "sticky bits", which would only be helpful if a
processor had separate instructions which did or did not set them (since
most programs do a miss of operations that should or should not be checked).
Instead a compiler can use whatever combination of extended-precision math
and overflow checks will be most effective in a given situation.  For a
64-bit processor totalling a bunch of 32-bit integer values in a 64-bit
register, the extra cost could be essentially nil.  Likewise for an
ARM7-TDMI totalling a bunch of 32-bit integers with an overflow check on
each add.  In many other situations, overflow checks won't be free but can
still be made much cheaper than if they are performed after each operation.

> And as always, if you want these wrapped in a nice "checked integer"
> type, you can use C++ and make one.  That would probably be more
> constructive than complaining to this newsgroup about the same thing
> again and again.

Is there any way to design a "checked integer" type which won't bother
setting an overflow flag if the upper bits of the result never end up being
used for anything?

[toc] | [prev] | [next] | [standalone]

#84067

On 15/03/16 16:02, supercat@casperkitty.com wrote:
> On Tuesday, March 15, 2016 at 9:32:00 AM UTC-5, David Brown wrote:
>> That is sort-of true - /if/ that were the case for real processors (I
>> don't know of any that have appropriate "sticky overflow" bits).  And
>> even then, it would stop the compiler being able to make optimisations
>> that involve re-arranging and simplifying calculations (like the one
>> above).  It would just mean that the "jump if overflow flag set" would
>> be moved to the end of the sequence, instead of occurring after each
>> potentially overflowing operation.
> 
> There's no need for "sticky bits", which would only be helpful if a
> processor had separate instructions which did or did not set them (since
> most programs do a miss of operations that should or should not be checked).
> Instead a compiler can use whatever combination of extended-precision math
> and overflow checks will be most effective in a given situation.  For a
> 64-bit processor totalling a bunch of 32-bit integer values in a 64-bit
> register, the extra cost could be essentially nil.  Likewise for an
> ARM7-TDMI totalling a bunch of 32-bit integers with an overflow check on
> each add.  In many other situations, overflow checks won't be free but can
> still be made much cheaper than if they are performed after each operation.

Yes, that would work in some cases, such as for unsigned addition - if
you have signed numbers, your upper 32-bit register could get an
overflow and then be reduced to 0 again.  You can, of course, do this in
normal C as it exists today - just use an uint64_t for your summation.

> 
>> And as always, if you want these wrapped in a nice "checked integer"
>> type, you can use C++ and make one.  That would probably be more
>> constructive than complaining to this newsgroup about the same thing
>> again and again.
> 
> Is there any way to design a "checked integer" type which won't bother
> setting an overflow flag if the upper bits of the result never end up being
> used for anything?
> 

Try to make sure that all the relevant operations are inline functions,
and the compiler should be able to figure out which parts of the result
are used and which are not.

[toc] | [prev] | [next] | [standalone]

#84115

On Wednesday, March 16, 2016 at 2:11:47 AM UTC-5, David Brown wrote:
> On 15/03/16 16:02, supercat wrote:
> >                                                                For a
> > 64-bit processor totalling a bunch of 32-bit integer values in a 64-bit
> > register, the extra cost could be essentially nil.  Likewise for an
> > ARM7-TDMI totalling a bunch of 32-bit integers with an overflow check on
> > each add.  In many other situations, overflow checks won't be free but can
> > still be made much cheaper than if they are performed after each operation.
> 
> Yes, that would work in some cases, such as for unsigned addition - if
> you have signed numbers, your upper 32-bit register could get an
> overflow and then be reduced to 0 again.  You can, of course, do this in
> normal C as it exists today - just use an uint64_t for your summation.

If code needs to add a bunch of 32-bit signed values and report either the
correct result or an indication that an overflow occurred (with, as noted
earlier, the option of doing either in cases where an overflow did occur but
the arithmetically-correct result ends up being within "int" range), using
a 64-bit integer type will have little or no speed penalty on some processors
but may double the time required to perform the computation on others.
Checking the result after each operation may have zero or near-zero time
penalty on some processors, but a severe time penalty on others.  On some
ARM processors, for example, each instruction's execution may be made
conditional upon the result of previous instructions, so something like

    a=b+c+d+e+f;

could be written as:

    mov   r0,r1
    add   r0,r2
    addnv r0,r3 ; Skip add if overflow
    addnv r0,r4 ; Skip add if overflow
    addnv r0,r5 ; Skip add if overflow
    movvs r10,#1 ; R10 = overflow flag--set it if overflow occurs

Much cheaper than anything a compiler could be expected to generate from
any code that needs to detect overflow and is written in strictly-compliant
C.

> > Is there any way to design a "checked integer" type which won't bother
> > setting an overflow flag if the upper bits of the result never end up being
> > used for anything?
> 
> Try to make sure that all the relevant operations are inline functions,
> and the compiler should be able to figure out which parts of the result
> are used and which are not.

A compiler can't figure it out, since it from its point of view the act of
setting the error flag on overflow is a side-effect which it would be
required to maintain even if the result of the expression were ignored.

If a function returns a product x*y which some callers will use and others
will ignore, then if x*y were a language-defined checked type the compiler
could omit the calculation of x*y altogether in cases where calling code
ignores it, but if user code is responsible for overflow checking a compiler
would be required to perform the computation unconditionally, regardless of
whether client code uses the result, since from its point of view it would
be necessary to set the error flag if the computation *would* overflow, even
though overflow in that needless computation would have no effect on the
arithmetical correctness of the computations underlying the program's
output.

Many languages have foregone overflow checking since precise overflow
checking is expensive.  Looser overflow semantics, however [overflow may
yield Unspecified Value, and may be ignored in cases that can be shown
not to affect numerical correctness of a program's output or decision-
making] could pose much less of a burden while still providing the same
practical benefits.  Absent language support, however, I see no means by
which user code could let compilers implement such semantics.

[toc] | [prev] | [next] | [standalone]

#83919

On 03/15/16 04:26, Richard Heathfield wrote:
> On 14/03/16 15:06, Malcolm McLean wrote:
>> On Monday, March 14, 2016 at 2:28:38 PM UTC, John M. Harris, Jr. wrote:
>>>
>>> What's a "try"? What's a "catch"? In C, you don't need to worry about
>>> that silly stuff, you have return codes and errno, and libraries
>>> generally have something like errno that they set, if return codes
>>> aren't specific enough. Name collisions shouldn't happen in libraries,
>>> so that's not something I've ever had to worry about.
>>>
>> Say we've got this code.
>>
>> IMAGE *createimage(int width, int height)
>> {
>>      IMAGE *answer;
>>
>>      answer = malloc(sizeof((MAGE));
>>      answer->rgba = malloc(width * height * 4);
>>      answer->width = width;
>>      answer->height = height;
>>      meset(answer->rgba, 0, width*height*4);
>>      return answer;
>> }
>>
>> pretty unexceptional (pun), routine code.
>
>> try catch together with automatic cleanup allows us to write the code
>> exactly like that, in the natural way, and have correct behaviour on
>> malicious input (and image dimensions is something that could well be
>> derived from user input).
>
> I think your meaning of 'natural' is different to my meaning of 'natural'.

For once I have to agree with Malcolm.  Ignoring the separate issue of 
integer overflow, exceptions do allow code to be written in a more 
natural as well as safer style.  Having to check return codes is one of 
my main irritations when using C rather then C++.  The resulting code is 
more complex, more error prone and less efficient.  I think that 
violates more than one of your coding rules! :)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#83921

On Monday, March 14, 2016 at 4:40:26 PM UTC-4, Ian Collins wrote:
> For once I have to agree with Malcolm.  Ignoring the separate issue of 
> integer overflow, exceptions do allow code to be written in a more 
> natural as well as safer style.  Having to check return codes is one of 
> my main irritations when using C rather then C++.  The resulting code is 
> more complex, more error prone and less efficient.  I think that 
> violates more than one of your coding rules! :)

Exactly.  There are tools in the programmer's toolbox.  They have
appropriate usages.  All of them.

I think C is also unfinished in that it doesn't include the class.
I think once the basic class was created and the value of its use
seen in C++ code, C should've adopted it in the next standard.  That
one added feature would remove many people's reasons for using C++
over C as they find C++ very complex, but C too restrictive and
obtuse because it doesn't have the class syntax.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#83948

On Monday, March 14, 2016 at 5:01:39 PM UTC-4, Rick C. Hodgin wrote:
> On Monday, March 14, 2016 at 4:40:26 PM UTC-4, Ian Collins wrote:
> > For once I have to agree with Malcolm.  Ignoring the separate issue of 
> > integer overflow, exceptions do allow code to be written in a more 
> > natural as well as safer style.  Having to check return codes is one of 
> > my main irritations when using C rather then C++.  The resulting code is 
> > more complex, more error prone and less efficient.  I think that 
> > violates more than one of your coding rules! :)
> 
> Exactly.  There are tools in the programmer's toolbox.  They have
> appropriate usages.  All of them.
> 
> I think C is also unfinished in that it doesn't include the class.
> I think once the basic class was created and the value of its use
> seen in C++ code, C should've adopted it in the next standard.  That
> one added feature would remove many people's reasons for using C++
> over C as they find C++ very complex, but C too restrictive and
> obtuse because it doesn't have the class syntax.

I also think C is unfinished in that it doesn't support function
overloading.  A huge shortcoming in my opinion.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web