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

Groups > comp.lang.c++ > #69217 > unrolled thread

Which exception for a buffer overrun?

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

Contents

  Which exception for a buffer overrun? Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-15 03:00 -0700
    Re:Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 12:52 +0200
      Re: Re:Which exception for a buffer overrun? queequeg@trust.no1 (Queequeg) - 2019-10-16 12:52 +0000
        Re: Re:Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-16 18:29 +0200
    Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 13:54 +0300
      Re: Which exception for a buffer overrun? Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-15 04:08 -0700
        Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:57 +0200
          Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-15 23:59 +0200
            Re: Which exception for a buffer overrun? scott@slp53.sl.home (Scott Lurndal) - 2019-10-15 22:13 +0000
              Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 15:04 +0200
            Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-16 07:57 +0300
              Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 15:05 +0200
              Re: Which exception for a buffer overrun? Keith Thompson <kst-u@mib.org> - 2019-10-16 15:34 -0700
            Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 10:16 +0200
              Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 05:54 -0700
                Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 16:12 +0200
                  Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 20:45 +0200
                  Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-17 06:34 -0700
                    Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 16:34 +0200
              Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 08:15 +1300
                Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 23:00 +0200
                  Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 10:36 +1300
                    Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 10:14 +0200
                  Re: Which exception for a buffer overrun? Daniel <danielaparker@gmail.com> - 2019-10-16 20:06 -0700
              Re: Which exception for a buffer overrun? Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-18 09:45 +0200
          Re: Which exception for a buffer overrun? Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-17 21:22 +0200
        Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 17:48 +0300
      Re: Which exception for a buffer overrun? "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2019-10-15 13:09 +0200
        Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:35 +0200
          Re: Which exception for a buffer overrun? scott@slp53.sl.home (Scott Lurndal) - 2019-10-15 13:30 +0000
        Re: Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 13:49 +0200
          Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:59 +0200
        Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-15 14:48 +0000
          Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 18:37 +0300
            Re: Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 18:48 +0200
        Re: Which exception for a buffer overrun? queequeg@trust.no1 (Queequeg) - 2019-10-16 13:00 +0000
      Re: Which exception for a buffer overrun? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-15 18:21 +0100
        Re: Which exception for a buffer overrun? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-15 20:32 +0000
          Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-16 06:20 +0000
      Re: Which exception for a buffer overrun? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-16 14:43 -0700
    Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-15 11:12 +0000
    Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-15 13:44 -0700
      Re: Which exception for a buffer overrun? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-15 22:43 +0100
        Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 00:01 -0700
          Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-16 19:02 +0000
            Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 15:22 -0700
              Re: Which exception for a buffer overrun? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2019-10-17 03:31 +0100
                Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 15:35 +1300
                  Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 10:17 +0200
              Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-20 22:18 +0000
                Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-21 04:06 -0700

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

#69257

On 16/10/2019 21:15, Ian Collins wrote:
> On 16/10/2019 21:16, David Brown wrote:

>> Readability is of course very important - and code correctness even more
>> so.  However, I am not convinced that exceptions are a great correctness
>> feature.  It is hard to write fully exception-safe code.  And, worse, it
>> is easy to write code that /appears/ to be exception safe, but is not.
>>
>> The two key problems, as I see it, are first that exceptions means all
>> sorts of code (function calls and expressions) can fail unexpectedly at
>> any time, leading to early returns from your function.  You have to be
>> thinking all the time about what will happen if there is an exception
>> when the code runs.  This can mean making more RAII classes, or more
>> indirect references (via unique_ptr, for example), simply to ensure
>> cleanup in case functions throw an exception.  That will make the code
>> safe and correct - but can be of significant readability cost.
> 
> The same set of conditions also apply to code that uses early returns. 
> Throwing an exception is just a special case of an early return.

There are two big differences.  One is that with an early return, 
everything is clear in the code - you know /exactly/ when the return 
happens, without having to consider whether functions may or may not 
throw.  The second is that you have control of the return - you can 
choose if it is early, or if other things are done first.

> 
>> The other problem is that a lot of the information about C++ exceptions
>> that a function can throw, is basically lying.  You can /say/ that a
>> function only throws specific exception types, which would be very
>> useful, but it's a lie.  At least C++11 "noexcept" is a stronger, and
>> now "throw" specifications are no longer part of C++17 at all.  But
>> there is currently no way to say what exceptions a function really could
>> throw, no way to check such features at compile time, no integration
>> with the type system, and the default is for functions to be specified
>> as "this function could throw anything, or pass on any exception" rather
>> than the more sensible "this function won't throw - it will do what it
>> says it will do".
> 
> This is true, but we are already there when we use the standard library 
> unless we build with exceptions disabled.
> 

Correct me if I am wrong, but for the most part the only exception that 
will be thrown by the standard library is for failed memory allocations. 
  On many platforms, it is highly unlikely ever to happen - and for many 
programs, the situation is so unexpected and critical that a dead crash 
and error message is probably an acceptable way to handle it.

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

#69259

On 17/10/2019 10:00, David Brown wrote:
> On 16/10/2019 21:15, Ian Collins wrote:
>> On 16/10/2019 21:16, David Brown wrote:
> 
>>> Readability is of course very important - and code correctness even more
>>> so.  However, I am not convinced that exceptions are a great correctness
>>> feature.  It is hard to write fully exception-safe code.  And, worse, it
>>> is easy to write code that /appears/ to be exception safe, but is not.
>>>
>>> The two key problems, as I see it, are first that exceptions means all
>>> sorts of code (function calls and expressions) can fail unexpectedly at
>>> any time, leading to early returns from your function.  You have to be
>>> thinking all the time about what will happen if there is an exception
>>> when the code runs.  This can mean making more RAII classes, or more
>>> indirect references (via unique_ptr, for example), simply to ensure
>>> cleanup in case functions throw an exception.  That will make the code
>>> safe and correct - but can be of significant readability cost.
>>
>> The same set of conditions also apply to code that uses early returns.
>> Throwing an exception is just a special case of an early return.
> 
> There are two big differences.  One is that with an early return,
> everything is clear in the code - you know /exactly/ when the return
> happens, without having to consider whether functions may or may not
> throw.  The second is that you have control of the return - you can
> choose if it is early, or if other things are done first.

I was mainly responding to more of the "This can mean making more RAII 
classes" section. Once you have early returns, objects instantiated in a 
function have to be, for lack of a better term, self managing. This is 
what applies equally to code with early returns and throws.  Early 
return safe and exception safe are pretty much synonymous.

>>> The other problem is that a lot of the information about C++ exceptions
>>> that a function can throw, is basically lying.  You can /say/ that a
>>> function only throws specific exception types, which would be very
>>> useful, but it's a lie.  At least C++11 "noexcept" is a stronger, and
>>> now "throw" specifications are no longer part of C++17 at all.  But
>>> there is currently no way to say what exceptions a function really could
>>> throw, no way to check such features at compile time, no integration
>>> with the type system, and the default is for functions to be specified
>>> as "this function could throw anything, or pass on any exception" rather
>>> than the more sensible "this function won't throw - it will do what it
>>> says it will do".
>>
>> This is true, but we are already there when we use the standard library
>> unless we build with exceptions disabled.
>>
> 
> Correct me if I am wrong, but for the most part the only exception that
> will be thrown by the standard library is for failed memory allocations.

That is true, but even innocuous operations such as insertions can throw 
if a constructor of the type being inserted throws.  That's why I said 
we have to build (every component of an application) with exceptions 
disabled to truly grantee something won't throw.

-- 
Ian

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

#69268

On 16/10/2019 23:36, Ian Collins wrote:
> On 17/10/2019 10:00, David Brown wrote:
>> On 16/10/2019 21:15, Ian Collins wrote:
>>> On 16/10/2019 21:16, David Brown wrote:
>>
>>>> Readability is of course very important - and code correctness even
>>>> more
>>>> so.  However, I am not convinced that exceptions are a great
>>>> correctness
>>>> feature.  It is hard to write fully exception-safe code.  And,
>>>> worse, it
>>>> is easy to write code that /appears/ to be exception safe, but is not.
>>>>
>>>> The two key problems, as I see it, are first that exceptions means all
>>>> sorts of code (function calls and expressions) can fail unexpectedly at
>>>> any time, leading to early returns from your function.  You have to be
>>>> thinking all the time about what will happen if there is an exception
>>>> when the code runs.  This can mean making more RAII classes, or more
>>>> indirect references (via unique_ptr, for example), simply to ensure
>>>> cleanup in case functions throw an exception.  That will make the code
>>>> safe and correct - but can be of significant readability cost.
>>>
>>> The same set of conditions also apply to code that uses early returns.
>>> Throwing an exception is just a special case of an early return.
>>
>> There are two big differences.  One is that with an early return,
>> everything is clear in the code - you know /exactly/ when the return
>> happens, without having to consider whether functions may or may not
>> throw.  The second is that you have control of the return - you can
>> choose if it is early, or if other things are done first.
> 
> I was mainly responding to more of the "This can mean making more RAII
> classes" section. Once you have early returns, objects instantiated in a
> function have to be, for lack of a better term, self managing. This is
> what applies equally to code with early returns and throws.  Early
> return safe and exception safe are pretty much synonymous.
> 

Yes, I see what you mean.  From the other viewpoint, it means you get
the advantages and safety of RAII without having to use exceptions -
RAII classes are still an excellent way to structure a lot of code.  But
again, with early returns you have more control - you can decide how
early to return, meaning you don't have to have make the parts
self-managing with RAII if it doesn't make sense in the program
structure.  (And by "early returns", that includes any kind of failure
handling through return values.)

>>>> The other problem is that a lot of the information about C++ exceptions
>>>> that a function can throw, is basically lying.  You can /say/ that a
>>>> function only throws specific exception types, which would be very
>>>> useful, but it's a lie.  At least C++11 "noexcept" is a stronger, and
>>>> now "throw" specifications are no longer part of C++17 at all.  But
>>>> there is currently no way to say what exceptions a function really
>>>> could
>>>> throw, no way to check such features at compile time, no integration
>>>> with the type system, and the default is for functions to be specified
>>>> as "this function could throw anything, or pass on any exception"
>>>> rather
>>>> than the more sensible "this function won't throw - it will do what it
>>>> says it will do".
>>>
>>> This is true, but we are already there when we use the standard library
>>> unless we build with exceptions disabled.
>>>
>>
>> Correct me if I am wrong, but for the most part the only exception that
>> will be thrown by the standard library is for failed memory allocations.
> 
> That is true, but even innocuous operations such as insertions can throw
> if a constructor of the type being inserted throws.  That's why I said
> we have to build (every component of an application) with exceptions
> disabled to truly grantee something won't throw.
> 

If you are not throwing exceptions in your own classes, then insertions
won't throw, because constructors won't throw.

Of course, whether you can build the whole application with exceptions
disabled, and whether that is a good idea, is going to depend on the
type of application and the mix of code you have.

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

#69267

On Wednesday, October 16, 2019 at 5:00:47 PM UTC-4, David Brown wrote:

> 
> Correct me if I am wrong, but for the most part the only exception that 
> will be thrown by the standard library is for failed memory allocations. 

I don't think you can count on that. One example, implementations of 
basic_streambuf::overflow are allowed to throw on failure.

Daniel

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

#69273

> The two key problems, as I see it, are first that exceptions means all
> sorts of code (function calls and expressions) can fail unexpectedly at
> any time, leading to early returns from your function.  You have to be
> thinking all the time about what will happen if there is an exception
> when the code runs.  This can mean making more RAII classes, or more
> indirect references (via unique_ptr, for example), simply to ensure
> cleanup in case functions throw an exception.  That will make the code
> safe and correct - but can be of significant readability cost.

And having the cleanup mannually is more readable???

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

#69272

> They are a bad idea for normal processing as an alternative to return
> values.

When you know that the exception would always address the caller, you
can stick with return-values anyway.

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

#69229

On 15.10.2019 14:08, Frederick Gotham wrote:
> On Tuesday, October 15, 2019 at 11:54:45 AM UTC+1, Paavo Helde wrote:
>
>> A buffer overrun should be considered a bug in the program and should be
>> dealt with by abort() or similar, not by an exception.
>
>
> So if I use a scissors to cut a slice of bread, am I abusing the scissors?

This bread is eaten or thrown away soon. Software OTOH tends to stick 
around for years and decades, and will affect many people, both 
maintainers and users. So any abuse, however slight, will multiply 
thousand-fold.

>
> Are you one of those people who will only use something for the one specific use that it says on the box?

No, I have built water boilers from a couple of gillette blades :-) But 
I did this in full knowledge that my solution had serious drawbacks and 
should not be used universally.

>
> I'm curious what your stance is on exception throwing in recursive functions (instead of conditional return statements)?
>

I am very fond of RAII and exceptions. Some of my lower level code is 
littered with throws. However, there is no throw out_of_range or catch 
out_of_range anywhere in my code.

Instead, I use some ASSERT and DEBUG_ASSERT macros for checking 
pre-conditions and post-conditions and reporting the failing code line.

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

#69221

Op 15.okt..2019 om 12:54 schreef Paavo Helde:
> On 15.10.2019 13:00, Frederick Gotham wrote:
>>
>> Do you use out_of_range when there's a buffer overrun? It seems to be 
>> the closest
> 
> A buffer overrun should be considered a bug in the program and should be 
> dealt with by abort() or similar, not by an exception. If an exception 
> is thrown, it should be a "fatal" one, e.g. InternalFatalError, causing 
> the error to be prominently logged/reported so it can be forwarded to 
> the program maintainer for fixing, and the program terminated or at 
> least returned the the main GUI/UI loop.
> 
> There is no point in throwing a special exception like out_of_range 
> because the calling code has no way to fix its code to pass the correct 
> index (if it could do that, it could have passed the correct index the 
> first time).
> 

Whether a buffer overrun is fatal depends on the circumstances. E.g., 
when a web server receives a request from a client that would cause a 
buffer overrun and the server detects it in time, then there is no 
reason to abort the web server. It could throw an exception to trigger 
the error handling which could e.g., close the connection with the client.

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

#69223

On 15/10/2019 13:09, Fred. Zwarts wrote:
> Op 15.okt..2019 om 12:54 schreef Paavo Helde:
>> On 15.10.2019 13:00, Frederick Gotham wrote:
>>>
>>> Do you use out_of_range when there's a buffer overrun? It seems to be
>>> the closest
>>
>> A buffer overrun should be considered a bug in the program and should
>> be dealt with by abort() or similar, not by an exception. If an
>> exception is thrown, it should be a "fatal" one, e.g.
>> InternalFatalError, causing the error to be prominently
>> logged/reported so it can be forwarded to the program maintainer for
>> fixing, and the program terminated or at least returned the the main
>> GUI/UI loop.
>>
>> There is no point in throwing a special exception like out_of_range
>> because the calling code has no way to fix its code to pass the
>> correct index (if it could do that, it could have passed the correct
>> index the first time).
>>
> 
> Whether a buffer overrun is fatal depends on the circumstances. E.g.,
> when a web server receives a request from a client that would cause a
> buffer overrun and the server detects it in time, then there is no
> reason to abort the web server. It could throw an exception to trigger
> the error handling which could e.g., close the connection with the client.
> 

Look carefully at what you wrote - "when a web server receives a request
from a client that *would/ cause a buffer overrun".  There is no buffer
overrun - there is proper checking of unsafe incoming data, /avoiding/
any risk of overrun.  How you handle this is up to you - if you think it
will happen often, make it part of normal processing.  If you think it
is going to be very rare, and exception is fine.

This is very different from a /real/ buffer overrun.  A buffer overrun
is a programming error.  The bug might be a coding error, or it might be
a higher level error in the design (not checking unsafe data on its way in).

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

#69227

David Brown <david.brown@hesbynett.no> writes:
>On 15/10/2019 13:09, Fred. Zwarts wrote:
>> Op 15.okt..2019 om 12:54 schreef Paavo Helde:

>> Whether a buffer overrun is fatal depends on the circumstances. E.g.,
>> when a web server receives a request from a client that would cause a
>> buffer overrun and the server detects it in time, then there is no
>> reason to abort the web server. It could throw an exception to trigger
>> the error handling which could e.g., close the connection with the client.
>> 
>
>Look carefully at what you wrote - "when a web server receives a request
>from a client that *would/ cause a buffer overrun".  There is no buffer
>overrun - there is proper checking of unsafe incoming data, /avoiding/
>any risk of overrun.  How you handle this is up to you - if you think it
>will happen often, make it part of normal processing.  If you think it
>is going to be very rare, and exception is fine.
>
>This is very different from a /real/ buffer overrun.  A buffer overrun
>is a programming error.  The bug might be a coding error, or it might be
>a higher level error in the design (not checking unsafe data on its way in).

Which raises the question of how the OP is detecting the soi disant buffer overrun.

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

#69224

[Multipart message — attachments visible in raw view] — view raw

"Fred. Zwarts" <F.Zwarts@KVI.nl> Wrote in message:
> Op 15.okt..2019 om 12:54 schreef Paavo Helde:> On 15.10.2019 13:00, Frederick Gotham wrote:>>>> Do you use out_of_range when there's a buffer overrun? It seems to be >> the closest> > A buffer overrun should be considered a bug in the program and should be > dealt with by abort() or similar, not by an exception. If an exception > is thrown, it should be a "fatal" one, e.g. InternalFatalError, causing > the error to be prominently logged/reported so it can be forwarded to > the program maintainer for fixing, and the program terminated or at > least returned the the main GUI/UI loop.> > There is no point in throwing a special exception like out_of_range > because the calling code has no way to fix its code to pass the correct > index (if it could do that, it could have passed the correct index the > first time).> Whether a buffer overrun is fatal depends on the circumstances. E.g., when a web server receives a request from a client that would cause a buffer overrun and the server detects it in time, then there is no reason to abort the web server. It could throw an exception to trigger the error handling which could e.g., close the connection with the client.

Buffer overrun is fatal error. Usually, it is not normal operation. When you receive data from socket, you specify size of buffer... If buffer is too small there will be overrun and program will crash, if you are lucky... 
-- 
press any key to continue or any other to quit... 



----Android NewsGroup Reader----
http://usenet.sinaapp.com/

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

#69226

On 15/10/2019 13:49, melzzzzz wrote:

<snip jumbled quotations>

> 
> Buffer overrun is fatal error. Usually, it is not normal operation.
> When you receive data from socket, you specify size of buffer... If
> buffer is too small there will be overrun and program will crash, if
> you are lucky...
> 

If your buffer is too small, it's because you have asked for too much
data in the socket receive - i.e., it's a bug in the code.

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

#69228

On Tue, 2019-10-15, Fred. Zwarts wrote:
> Op 15.okt..2019 om 12:54 schreef Paavo Helde:
>> On 15.10.2019 13:00, Frederick Gotham wrote:
>>>
>>> Do you use out_of_range when there's a buffer overrun? It seems to be 
>>> the closest
>> 
>> A buffer overrun should be considered a bug in the program and should be 
>> dealt with by abort() or similar, not by an exception. If an exception 
>> is thrown, it should be a "fatal" one, e.g. InternalFatalError, causing 
>> the error to be prominently logged/reported so it can be forwarded to 
>> the program maintainer for fixing, and the program terminated or at 
>> least returned the the main GUI/UI loop.
>> 
>> There is no point in throwing a special exception like out_of_range 
>> because the calling code has no way to fix its code to pass the correct 
>> index (if it could do that, it could have passed the correct index the 
>> first time).
>
> Whether a buffer overrun is fatal depends on the circumstances. E.g., 
> when a web server receives a request from a client that would cause a 
> buffer overrun and the server detects it in time, then there is no 
> reason to abort the web server. It could throw an exception to trigger 
> the error handling which could e.g., close the connection with the client.

(And destroy the HTTP Session object owning all related resources.)

Thanks; that was also the counter-example I was going to give.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#69230

On 15.10.2019 17:48, Jorgen Grahn wrote:
> On Tue, 2019-10-15, Fred. Zwarts wrote:
>> Op 15.okt..2019 om 12:54 schreef Paavo Helde:
>>> On 15.10.2019 13:00, Frederick Gotham wrote:
>>>>
>>>> Do you use out_of_range when there's a buffer overrun? It seems to be
>>>> the closest
>>>
>>> A buffer overrun should be considered a bug in the program and should be
>>> dealt with by abort() or similar, not by an exception. If an exception
>>> is thrown, it should be a "fatal" one, e.g. InternalFatalError, causing
>>> the error to be prominently logged/reported so it can be forwarded to
>>> the program maintainer for fixing, and the program terminated or at
>>> least returned the the main GUI/UI loop.
>>>
>>> There is no point in throwing a special exception like out_of_range
>>> because the calling code has no way to fix its code to pass the correct
>>> index (if it could do that, it could have passed the correct index the
>>> first time).
>>
>> Whether a buffer overrun is fatal depends on the circumstances. E.g.,
>> when a web server receives a request from a client that would cause a
>> buffer overrun and the server detects it in time, then there is no
>> reason to abort the web server. It could throw an exception to trigger
>> the error handling which could e.g., close the connection with the client.
>
> (And destroy the HTTP Session object owning all related resources.)
>
> Thanks; that was also the counter-example I was going to give.

This is all fine, but the exception we are discussing would not be 
std::out_of_range (which would be presumable translated to "500 Internal 
Server Error"), but rather something like InvalidParameterException, 
translated to "400 Bad Request".

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

#69231

[Multipart message — attachments visible in raw view] — view raw

Paavo Helde <myfirstname@osa.pri.ee> Wrote in message:
> On 15.10.2019 17:48, Jorgen Grahn wrote:> On Tue, 2019-10-15, Fred. Zwarts wrote:>> Op 15.okt..201

Anyway, request too big shouldn't cause buffer overflow... 

Sory, for not quoting, I have crappy freeware on phone... 
-- 
press any key to continue or any other to quit... 



----Android NewsGroup Reader----
http://usenet.sinaapp.com/

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

#69246

Fred. Zwarts <F.Zwarts@kvi.nl> wrote:

> Whether a buffer overrun is fatal depends on the circumstances. E.g., 
> when a web server receives a request from a client that would cause a 
> buffer overrun and the server detects it in time, then there is no 
> reason to abort the web server. It could throw an exception to trigger 
> the error handling which could e.g., close the connection with the client.

Exception doesn't seem to be a good choice here, at least for me. 
Exceptions are meant to handle exceptional situations, not an invalid user 
input, even if this input, if not validated, would cause a buffer overrun 
or other critical error.

Your code can / should safely continue after an invalid user input, and 
handle it appropriately (by signalling an error, terminating the 
connection, logging it -- but it should be defined).

In my code, I use exceptions only to signal assertions and situations that 
should never happen if the code was correct, machine had enough memory, 
and the code could safely continue. The only way to recover from such 
exception is to log debugging information and gracefully die, not doing 
any more harm.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

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

#69232

On 15/10/2019 11:54, Paavo Helde wrote:
> On 15.10.2019 13:00, Frederick Gotham wrote:
>>
>> Do you use out_of_range when there's a buffer overrun? It seems to be 
>> the closest
> 
> A buffer overrun should be considered a bug in the program and should be 
> dealt with by abort() or similar, not by an exception. If an exception is 
> thrown, it should be a "fatal" one, e.g. InternalFatalError, causing the 
> error to be prominently logged/reported so it can be forwarded to the 
> program maintainer for fixing, and the program terminated or at least 
> returned the the main GUI/UI loop.
> 
> There is no point in throwing a special exception like out_of_range 
> because the calling code has no way to fix its code to pass the correct 
> index (if it could do that, it could have passed the correct index the 
> first time).
> 
> If the calling code is just querying the length of an array or something, 
> then this should never trigger exceptions. First, using exceptions for 
> non-exceptional situations would convolute the program logic, and secondly 
> it would be dead slow.
> 
> It's true that there is std::vector::at() which throws std::out_of_range, 
> derived from std::logic_error, but many people consider the whole 
> std::logic_error exception class hierarchy as an historical mistake.

For detectable bugs I throw custom exceptions derived from 
std::logic_error which are NOT caught (or are re-thrown) so the 
application terminates using std::terminate (which in turn will, by 
default, call abort()).Just calling abort() on its own without using 
exceptions is a bit pants as there is no opportunity to log.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into 
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who 
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – 
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are 
confronted by God," Bryne asked on his show The Meaning of Life. "What 
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery 
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a 
world that is so full of injustice and pain. That's what I would say."

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

#69234

On 2019-10-15, Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
> On 15/10/2019 11:54, Paavo Helde wrote:
>> On 15.10.2019 13:00, Frederick Gotham wrote:
>>>
>>> Do you use out_of_range when there's a buffer overrun? It seems to be 
>>> the closest
>> 
>> A buffer overrun should be considered a bug in the program and should be 
>> dealt with by abort() or similar, not by an exception. If an exception is 
>> thrown, it should be a "fatal" one, e.g. InternalFatalError, causing the 
>> error to be prominently logged/reported so it can be forwarded to the 
>> program maintainer for fixing, and the program terminated or at least 
>> returned the the main GUI/UI loop.
>> 
>> There is no point in throwing a special exception like out_of_range 
>> because the calling code has no way to fix its code to pass the correct 
>> index (if it could do that, it could have passed the correct index the 
>> first time).
>> 
>> If the calling code is just querying the length of an array or something, 
>> then this should never trigger exceptions. First, using exceptions for 
>> non-exceptional situations would convolute the program logic, and secondly 
>> it would be dead slow.
>> 
>> It's true that there is std::vector::at() which throws std::out_of_range, 
>> derived from std::logic_error, but many people consider the whole 
>> std::logic_error exception class hierarchy as an historical mistake.
>
> For detectable bugs I throw custom exceptions derived from 
> std::logic_error which are NOT caught (or are re-thrown) so the 
> application terminates using std::terminate (which in turn will, by 
> default, call abort()).Just calling abort() on its own without using 
> exceptions is a bit pants as there is no opportunity to log.

What's stopping you to log then call abort?
>
> /Flibble
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#69241

On Tue, 2019-10-15, Melzzzzz wrote:
> On 2019-10-15, Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
...

>> For detectable bugs I throw custom exceptions derived from 
>> std::logic_error which are NOT caught (or are re-thrown) so the 
>> application terminates using std::terminate (which in turn will, by 
>> default, call abort()).Just calling abort() on its own without using 
>> exceptions is a bit pants as there is no opportunity to log.
>
> What's stopping you to log then call abort?

I think he means if he throws, upper layers of code can decide if it
wants to log or not.  On the other hand, if it /does/ catch the
exception, stack unwinding will happen and there will be no
interesting core dump even if it re-throws.

I think I would log and then throw, and then in higher layers not
catch that exception.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#69260

On 10/15/2019 3:54 AM, Paavo Helde wrote:
> On 15.10.2019 13:00, Frederick Gotham wrote:
>>
>> Do you use out_of_range when there's a buffer overrun? It seems to be 
>> the closest
> 
> A buffer overrun should be considered a bug in the program and should be 
> dealt with by abort() or similar, not by an exception.

Fwiw, I remember creating a plug in system where a user defined program 
could crash. The watchdog process detected this, and tried to recover, 
restart or label as dead. An interesting method to do this is via robust 
mutexes.






If an exception
> is thrown, it should be a "fatal" one, e.g. InternalFatalError, causing 
> the error to be prominently logged/reported so it can be forwarded to 
> the program maintainer for fixing, and the program terminated or at 
> least returned the the main GUI/UI loop.
> 
> There is no point in throwing a special exception like out_of_range 
> because the calling code has no way to fix its code to pass the correct 
> index (if it could do that, it could have passed the correct index the 
> first time).
> 
> If the calling code is just querying the length of an array or 
> something, then this should never trigger exceptions. First, using 
> exceptions for non-exceptional situations would convolute the program 
> logic, and secondly it would be dead slow.
> 
> It's true that there is std::vector::at() which throws 
> std::out_of_range, derived from std::logic_error, but many people 
> consider the whole std::logic_error exception class hierarchy as an 
> historical mistake.
> 
> 

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

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

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

csiph-web