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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#84078

On 03/16/16 21:14, David Brown wrote:
> On 16/03/16 08:39, Ian Collins wrote:
>> On 03/15/16 22:01, David Brown wrote:
>>
>>>
>>> Exceptions have their disadvantages too.  Combined with good RAII, they
>>> may save you from remembering to clean up some resources along the way -
>>> but they don't stop you forgetting to handle the exception.  So that
>>> means that any seemingly safe function call, that would not need any
>>> error checking in C, might return half-completed with an exception.
>>
>> I don't see how this would happen - if something throws it should have
>> an equivalent check in C.
>>
>>> I am not convinced that exceptions really help - they just move the
>>> problem around a bit.  (RAII, of course, is a great idea.)
>>
>> I think you have spent too long in the embedded world David!  The number
>> of times I wish I had a "bugger it, give up!" option in C isn't small..
>>
>>> In my view, C++ exceptions would be much more useful if they really were
>>> for exceptional circumstances.  The key problems with C-style error
>>> handling (when using C++ with RAII) are:
>>
>> Yes, I can see that, but those horses have bolted.
>>
>>> 1. You have to remember to check for errors from any function that can
>>> return errors.
>>> 2. This error checking must be done at the point of the function call.
>>> 3. The error checking has overhead, whether there is an error or not.
>>> 4. Whether a function can return an error or not is a matter of
>>> documentation for the function, and not something the compiler can check.
>>>
>>> The key problems with C++ exceptions, as I see it:
>>>
>>> 1. You have to remember to handle exceptions from any function that can
>>> throw an exception.
>>
>> There's the think - you don't.  You can choose to deffer the handling at
>> a place where its makes most sense.  If you have a complex transaction
>> that doesn't support retries, you may as well just catch at the level of
>> the top level call.  or even in main if a condition isn't recoverable.
>
> No, you /do/ need to remember to handle exceptions from any function
> that can throw an exception.  You might want to handle it in a different
> place, further up the call chain, but you still need to handle it.

Indeed, but the choice is yours.  If you miss an error code check, you 
may never know...

> And
> the further you are from the point of the throw, the bigger the risk
> that you will forget (or that someone else is writing that code, and you
> have not communicated the exception requirements well enough).

But even then, if an exception is thrown, you will know.  Missing error 
codes is a silent bug.

<snip>

>>> In other words, C++ exceptions don't solve the issues with C error
>>> handling.  They just move it around a bit, and hide some of it.
>>
>> Hide a lot of it!
>
> Some (including me) would say that they hide the issues too much - you
> want to know about possible errors and handle them.

Often, you don't.  There could a be a dozen ways for a transaction to 
fail, but all the calling code cares about is did it fail or not?  If 
needed, the exception can covey the detail.

>>> If a function wants to throw, it has to have a "throw" specifier listing
>>> the exception classes that it can throw.  It is allowed to throw those
>>> classes, or classes derived from them - and nothing else.  The stdexcept
>>> class hierarchy would be extended to make this convenient - typically
>>> all exception classes would derive ultimately from a common base class.
>>
>> Haven't other languages tried this and ended up with either a terrible
>> mess, or all exceptions derived form a common base?
>>
>
> Some OO languages use common bases for object hierarchies - sometimes it
> is a good thing, sometimes a bad thing.  I suggest it here as a better
> way of having a "catch anything" clause - but it is not a key point in
> my suggested solution.

I was thinking more of the case of "Bloody hell! do we have to list all 
these exceptions in the function declaration?  Bugger it, make them 
inherit from a common base".  Which ends up being worse than useless.

-- 
Ian Collins

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

#84084

On 16/03/16 10:40, Ian Collins wrote:
> On 03/16/16 21:14, David Brown wrote:
>> On 16/03/16 08:39, Ian Collins wrote:
>>> On 03/15/16 22:01, David Brown wrote:
>>>
>>>>
>>>> Exceptions have their disadvantages too.  Combined with good RAII, they
>>>> may save you from remembering to clean up some resources along the
>>>> way -
>>>> but they don't stop you forgetting to handle the exception.  So that
>>>> means that any seemingly safe function call, that would not need any
>>>> error checking in C, might return half-completed with an exception.
>>>
>>> I don't see how this would happen - if something throws it should have
>>> an equivalent check in C.
>>>
>>>> I am not convinced that exceptions really help - they just move the
>>>> problem around a bit.  (RAII, of course, is a great idea.)
>>>
>>> I think you have spent too long in the embedded world David!  The number
>>> of times I wish I had a "bugger it, give up!" option in C isn't small..
>>>
>>>> In my view, C++ exceptions would be much more useful if they really
>>>> were
>>>> for exceptional circumstances.  The key problems with C-style error
>>>> handling (when using C++ with RAII) are:
>>>
>>> Yes, I can see that, but those horses have bolted.
>>>
>>>> 1. You have to remember to check for errors from any function that can
>>>> return errors.
>>>> 2. This error checking must be done at the point of the function call.
>>>> 3. The error checking has overhead, whether there is an error or not.
>>>> 4. Whether a function can return an error or not is a matter of
>>>> documentation for the function, and not something the compiler can
>>>> check.
>>>>
>>>> The key problems with C++ exceptions, as I see it:
>>>>
>>>> 1. You have to remember to handle exceptions from any function that can
>>>> throw an exception.
>>>
>>> There's the think - you don't.  You can choose to deffer the handling at
>>> a place where its makes most sense.  If you have a complex transaction
>>> that doesn't support retries, you may as well just catch at the level of
>>> the top level call.  or even in main if a condition isn't recoverable.
>>
>> No, you /do/ need to remember to handle exceptions from any function
>> that can throw an exception.  You might want to handle it in a different
>> place, further up the call chain, but you still need to handle it.
> 
> Indeed, but the choice is yours.  If you miss an error code check, you
> may never know...

My point is that this applies roughly equally to C++ exception handling
and C-style error returns.  C++ gives you more flexibility on /where/
you handle the errors, but you still need to remember to handle them.
And C can sometimes give you more automated help in remembering to check
results - lint-style tools can often spot missing checks on malloc
returns, and the gcc function attribute "warn_unused_result" can help.
But ultimately, both methods rely on the programmer remembering to check
the results, and neither language gives as much help as would have been
possible if static checking had been a priority when C++ exceptions were
developed.

> 
>> And
>> the further you are from the point of the throw, the bigger the risk
>> that you will forget (or that someone else is writing that code, and you
>> have not communicated the exception requirements well enough).
> 
> But even then, if an exception is thrown, you will know.  Missing error
> codes is a silent bug.
> 

Missing an appropriate exception catch, and missing an error check, are
bugs - /if/ the error is triggered, and if it causes a problem.  I would
prefer to see a compile-time error if these are missing - not wait for
testing and hope that I can provoke all possible errors during lab
tests.  (Yes, I know that is an aim in testing - you want to test all
possible code paths.  But practice does not always follow theory - and
compile-time errors are always better than run-time errors.)

> 
>>>> In other words, C++ exceptions don't solve the issues with C error
>>>> handling.  They just move it around a bit, and hide some of it.
>>>
>>> Hide a lot of it!
>>
>> Some (including me) would say that they hide the issues too much - you
>> want to know about possible errors and handle them.
> 
> Often, you don't.  There could a be a dozen ways for a transaction to
> fail, but all the calling code cares about is did it fail or not?  If
> needed, the exception can covey the detail.

I agree that you often don't need the details.  But I still want to know
if things /can/ fail, and if they /did/ fail.

> 
>>>> If a function wants to throw, it has to have a "throw" specifier
>>>> listing
>>>> the exception classes that it can throw.  It is allowed to throw those
>>>> classes, or classes derived from them - and nothing else.  The
>>>> stdexcept
>>>> class hierarchy would be extended to make this convenient - typically
>>>> all exception classes would derive ultimately from a common base class.
>>>
>>> Haven't other languages tried this and ended up with either a terrible
>>> mess, or all exceptions derived form a common base?
>>>
>>
>> Some OO languages use common bases for object hierarchies - sometimes it
>> is a good thing, sometimes a bad thing.  I suggest it here as a better
>> way of having a "catch anything" clause - but it is not a key point in
>> my suggested solution.
> 
> I was thinking more of the case of "Bloody hell! do we have to list all
> these exceptions in the function declaration?  Bugger it, make them
> inherit from a common base".  Which ends up being worse than useless.
> 

No, that ends up being pretty much the situation that we have now with
exceptions in C++ - any function can throw or pass-on any exception,
unless you specifically say otherwise.  (And with due to the almost
total failure of C++ throw() specifications, the only thing you ever
specify is the default of "throw anything" or explicitly "throw nothing".)

So specifying that a function can throw the common base gives you the
same as today's default exception specification in C++.  I would want
the default to be the same as today's "noexcept".  And the use of an
exception hierarchy would let you say that a function might throw an "io
error" but not an "out of memory error" without having to list all the
types of io errors.

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

#83974

On 03/15/16 11:05, Richard Heathfield wrote:
> On 14/03/16 21:16, Ian Collins wrote:
>> On 03/15/16 10:07, Richard Heathfield wrote:
>>> On 14/03/16 20:40, Ian Collins wrote:
>>
>>>> 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! :)
>>>
>>> <shrug> I'm so used to:
>>>
>>> if((foo = acquire_resource(args)) != NULL)
>>> {
>>>      do_stuff_with(foo);
>>>      release_resource(&foo);
>>> }
>>>
>>> that I don't see it as either complex or particularly error-prone.
>>
>> Forgetting the release_resource(&foo) is frequently forgotten or
>> incorrect if the nature of the resource (or number of them) changes.
>> Such code often ends up with "goto cleanup" or similar, which I loathe.
>>
>>> I'd
>>> be curious to know why you think it's less efficient than try/catch.
>>
>> Well it's a case of s/think/know/!
>
> All right. Why do you know it? [Reading on...]
>
>> I've tested this behaviour on many compilers over even more years!  In
>> C++ the overhead (which tends to be significant) of exceptions only
>> applies when one is thrown.  The "if" is always executed.
>
> Okay, I'll bite. How does the computer know when to throw an exception,
> if not via (the opcode equivalent of) an "if"?

The same if that would otherwise return an error code.  That is the 
difference between

foo*
acquire_resource(args)
{
   if( broken(args) )
   {
     return NULL;
   }
   ...
}

compared to

foo
acquire_resource(args)
{
   if( broken(args) )
   {
     throw broken_args;
   }
  ...
}

-- 
Ian Collins

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

#83987

On 15/03/16 01:53, Ian Collins wrote:
> On 03/15/16 11:05, Richard Heathfield wrote:
>> On 14/03/16 21:16, Ian Collins wrote:
>>> On 03/15/16 10:07, Richard Heathfield wrote:
>>>> On 14/03/16 20:40, Ian Collins wrote:
>>>
>>>>> 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! :)
>>>>
>>>> <shrug> I'm so used to:
>>>>
>>>> if((foo = acquire_resource(args)) != NULL)
>>>> {
>>>>      do_stuff_with(foo);
>>>>      release_resource(&foo);
>>>> }
>>>>
>>>> that I don't see it as either complex or particularly error-prone.
>>>
>>> Forgetting the release_resource(&foo) is frequently forgotten or
>>> incorrect if the nature of the resource (or number of them) changes.
>>> Such code often ends up with "goto cleanup" or similar, which I loathe.
>>>
>>>> I'd
>>>> be curious to know why you think it's less efficient than try/catch.
>>>
>>> Well it's a case of s/think/know/!
>>
>> All right. Why do you know it? [Reading on...]
>>
>>> I've tested this behaviour on many compilers over even more years!  In
>>> C++ the overhead (which tends to be significant) of exceptions only
>>> applies when one is thrown.  The "if" is always executed.
>>
>> Okay, I'll bite. How does the computer know when to throw an exception,
>> if not via (the opcode equivalent of) an "if"?
>
> The same if that would otherwise return an error code.  That is the
> difference between
>
> foo*
> acquire_resource(args)
> {
>    if( broken(args) )
>    {
>      return NULL;
>    }
>    ...
> }
>
> compared to
>
> foo
> acquire_resource(args)
> {
>    if( broken(args) )
>    {
>      throw broken_args;
>    }
>   ...
> }
>


Ian, I hope you already know that not only do I have great respect for 
your ability as a programmer but also I recognise your undoubted skill 
as a debater. Nevertheless, I sincerely hope that I will never have to 
read your documentation.

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

#83988

On 03/15/16 21:17, Richard Heathfield wrote:
>
> Ian, I hope you already know that not only do I have great respect for
> your ability as a programmer but also I recognise your undoubted skill
> as a debater. Nevertheless, I sincerely hope that I will never have to
> read your documentation.

Docuwhat?

-- 
Ian Collins

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

#83942

On Monday, 14 March 2016 23:16:19 UTC+2, Ian Collins  wrote:
> On 03/15/16 10:07, Richard Heathfield wrote:
>
> > I'd
> > be curious to know why you think it's less efficient than try/catch.
> 
> Well it's a case of s/think/know/!
> 
> I've tested this behaviour on many compilers over even more years!  In 
> C++ the overhead (which tends to be significant) of exceptions only 
> applies when one is thrown.  The "if" is always executed.

I agree that not thrown exceptions are way more efficient than branches
but exception handling has still a cost as well (just smaller). 
Declaring functions that will never throw as 'noexcept' performs a
tiny bit better.

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

#83975

W dniu poniedziałek, 14 marca 2016 22:08:00 UTC+1 użytkownik Richard Heathfield napisał:
> On 14/03/16 20:40, Ian Collins wrote:
> > On 03/15/16 04:26, Richard Heathfield wrote:
> >> On 14/03/16 15:06, Malcolm McLean wrote:
> <snip>
> >>
> >>> 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.
> 
> That's a danger sign. :-)
> 
thats a danger sign but for mcleam 

here with try catch he is wrong imo, 
as to integer overflows for checking for bugs that could be usefull but it is seen it depends on hardware less on c 9where could be only emulated)

anyway cpu makers could make separate integer arithmetic opcodes that will throw integer overflow (probably better than switching mode with cpu flag) then on c level you could use 

int a,b,c;
checked overflow int d, e, f;

where a,b,c not rises signal and d,e,f rises one

said already that many ints can be provided
like

undefined overflow int a,b,c;
saturation overflow int a,b,c;

and so on

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

#83882

W dniu poniedziałek, 14 marca 2016 16:06:41 UTC+1 użytkownik Malcolm McLean napisał:
> 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.
> 
> But of course it's wrong. It doesn't handle out of memory errors,
> and, more insidiously, it doesn't handle width * height > INT_MAX.
>  
> (Quick question, what happens if we make the image dimensions size_t?)
> 
> 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).

try catch is disaster imo, returning values is also not much good imo

but there is another option that is c conformant, maybe someone will guess what?
;-0

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

#83885

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.
>
> But of course it's wrong. It doesn't handle out of memory errors,
> and, more insidiously, it doesn't handle width * height > INT_MAX.
>  
> (Quick question, what happens if we make the image dimensions size_t?)

Since size_t is an unsigned type, overflow of `width * height` would
have defined but undesirable behavior.  (Unless `size_t` is narrower
than `int` and `width * height` exceeds `INT_MAX`, but that's unlikely.)

Overflow is unlikely unless `size_t` is 16 bits (which would probably
imply a very old or small embedded system) or the image is *very* large,
several gigapixels.

You might avoid overflow by restricting width and height to "reasonable"
values.

> 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).

It depends on the language.

C++ has try and catch, but its behavior on integer overflow is the
same as C's.  Integer overflow doesn't throw an exception.

Ada has the equivalent of try/catch, and integer overflow does throw
(actually "raise") an exception.

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

#83886

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

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

<snip>
> 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.
>
> But of course it's wrong. It doesn't handle out of memory errors,
> and, more insidiously, it doesn't handle width * height > INT_MAX.

Even more insidiously it does not handle width * height > INT_MAX/4 nor
width * height * 4 > SIZE_MAX (though this is unlikely).

> (Quick question, what happens if we make the image dimensions size_t?)
>
> 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).

Even assuming (from other posts) that signed integer overflow raises an
exception, how would try/catch help with createimage(-10, 10)?  And are
you assuming that ((IMAGE *)0)->rgba will raise an exception?  And what
about width * height * 4 > SIZE_MAX?

-- 
Ben.

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

#83892

On Monday, March 14, 2016 at 4:14:37 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > 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,
> 
> <snip>
> > 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.
> >
> > But of course it's wrong. It doesn't handle out of memory errors,
> > and, more insidiously, it doesn't handle width * height > INT_MAX.
> 
> Even more insidiously it does not handle width * height > INT_MAX/4 nor
> width * height * 4 > SIZE_MAX (though this is unlikely).
> 
> > (Quick question, what happens if we make the image dimensions size_t?)
> >
> > 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).
> 
> Even assuming (from other posts) that signed integer overflow raises an
> exception, how would try/catch help with createimage(-10, 10)?  And are
> you assuming that ((IMAGE *)0)->rgba will raise an exception?  And what
> about width * height * 4 > SIZE_MAX?
> 
We call malloc with -400. Since malloc() takes a signed value, that is constrained
to throw an exception, which we handle.
Of course -10, -10 will be a bit problematic, you could argue that such an
image should have area (I'll leave the mathematicians to rule on that one).

I am of course assuming a superior try .. catch C with some of the glitches 
taken out.

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

#83895

On 14/03/16 17:01, Malcolm McLean wrote:

<snip>

> We call malloc with -400. Since malloc() takes a signed value,

No, it doesn't. It takes a size_t. The conversion from a negative int 
value to a size_t value is implementation-defined (because it depends on 
the ranges of the types), but it is /defined/.

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

#83896

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, March 14, 2016 at 4:14:37 PM UTC, Ben Bacarisse wrote:
[...]
>> Even assuming (from other posts) that signed integer overflow raises an
>> exception, how would try/catch help with createimage(-10, 10)?  And are
>> you assuming that ((IMAGE *)0)->rgba will raise an exception?  And what
>> about width * height * 4 > SIZE_MAX?
>> 
> We call malloc with -400. Since malloc() takes a signed value, that is
> constrained to throw an exception, which we handle.
> Of course -10, -10 will be a bit problematic, you could argue that such an
> image should have area (I'll leave the mathematicians to rule on that one).

On what planet does malloc() take a signed value?

If you're talking about something other than C, I suggest that you
(a) specify the characteristics of your not-quite-C rather than
implicitly assuming them when it's convenient and/or (b) consider
discussing it elsewhere.

Sure, a -10 x -10 image would in principle have an area of 100,
but it would have (presumably) invalid width and height, and
it would (presumably) be impossible to render it on a display.
Even in languages with extensive constraint checking (I use Ada as
an example because I happen to be familiar with it), you can't depend
on the language itself to do all the checking that needs to be done.

> I am of course assuming a superior try .. catch C with some of the glitches 
> taken out.

Of course.  But if you arbitrarily correct C's "glitches" one at a
time as they pop up, the end result is not likely to be a coherent
language.  It's more likely to be, not C++, but something like what
C++'s detractors claim it to be.

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

#83902

On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> On what planet does malloc() take a signed value?
>
Once upon a time it took an int.
> 
> If you're talking about something other than C, I suggest that you
> (a) specify the characteristics of your not-quite-C rather than
> implicitly assuming them when it's convenient and/or (b) consider
> discussing it elsewhere.
>
The thread is "C is unfinished". So we're discussing what "finished" C
would look like. I explained the value of try .. catch. I'm not necessarily
proposing it, but there is a case for that type of handling, particularly
for arithmetical overflow and memory allocation failure.
However you also need garbage collection because you unwind the stack.
>
> Of course.  But if you arbitrarily correct C's "glitches" one at a
> time as they pop up, the end result is not likely to be a coherent
> language.  It's more likely to be, not C++, but something like what
> C++'s detractors claim it to be.
> 
Sometimes it's better for things to evolve gently, sometimes better
to change in a big go. It's a tradeoff.

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

#83912

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On what planet does malloc() take a signed value?
>>
> Once upon a time it took an int.

You don't really think that answers my question, do you?

[snip]

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

#83913

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

> On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> On what planet does malloc() take a signed value?
>>
> Once upon a time it took an int.

When?

I don't remember any period when that was the case.  It it ever did, it
was for some very small window between V6 Unix (where is did not exist)
and writing the Jan 1979 V7 manual pages (where it takes unsigned).

<snip>
-- 
Ben.

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

#83946

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

> On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >
> > On what planet does malloc() take a signed value?
> >
> Once upon a time it took an int.

Are you living in the supercat alternative universe now?

I have a very old, very idiosyncratic Dutch AT&T C manual in which
malloc() takes an _unsigned_ int. I have never seen one which took a
signed one.

Richard

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

#83949

On Monday, March 14, 2016 at 5:17:33 PM UTC-5, Richard Bos wrote:
> I have a very old, very idiosyncratic Dutch AT&T C manual in which
> malloc() takes an _unsigned_ int. I have never seen one which took a
> signed one.

Is there a chronology which specifies when C gained the keywords "unsigned",
"signed", and "void", when the library gained "malloc", and when the language
started creating a separate namespace for the elements of each structure or
union type?  My understanding is that those things all happened well before
the invention of C++ and consequent introduction of prototypes to the C
language, but none of those features were present in the very earliest
versions of C.  I don't know of a source that accurately date each of them,
though.

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

#83973

On Mon, 14 Mar 2016 15:34:55 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Monday, March 14, 2016 at 5:17:33 PM UTC-5, Richard Bos wrote:
>> I have a very old, very idiosyncratic Dutch AT&T C manual in which
>> malloc() takes an _unsigned_ int. I have never seen one which took a
>> signed one.
>
>Is there a chronology which specifies when C gained the keywords "unsigned",
>"signed", and "void", when the library gained "malloc", and when the language
>started creating a separate namespace for the elements of each structure or
>union type?  My understanding is that those things all happened well before
>the invention of C++ and consequent introduction of prototypes to the C
>language, but none of those features were present in the very earliest
>versions of C.  I don't know of a source that accurately date each of them,
>though.


Unsigned postdates the 6th Edition Unix (May 1975) implementation of
C:

https://www.bell-labs.com/usr/dmr/www/cman.pdf


DMR's page at Bell Labs has a number of interesting links on the
subject:

https://www.bell-labs.com/usr/dmr/www/

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

#83978

On Monday, March 14, 2016 at 8:14:33 PM UTC-5, robert...@yahoo.com wrote:
> Unsigned postdates the 6th Edition Unix (May 1975) implementation of
> C:
> https://www.bell-labs.com/usr/dmr/www/cman.pdf

That manual must come from the same alternate universe that Malcolm and I
come from.

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

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

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

csiph-web