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

#69222

On Tue, 2019-10-15, Frederick Gotham wrote:
>
> Do you use out_of_range when there's a buffer overrun? It seems to
> be the closest

I don't think it's always a good idea to squeeze your errors into the
standard hierarchy.

I wrote a class last week for parsing TIFF files. When fed a broken
file, one thing that can happen is that an IFD offset points outside
the file. But other errors include zero-length arrays, missing
mandatory information and so on.

I don't think it would make sense to use out_of_range there. I made
a TiffDecoder::Error exception instead, and subclassed that one.

The key question is: how would the caller use the information?
My user would just want to know that the TIFF data was unusable.

/Jorgen

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

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

#69235

On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:
> Do you use out_of_range when there's a buffer overrun? It seems to be the closest

May be if what you write is rather abstract class like 
boost::scoped_array and you implement at() function for it.
BTW boost::scoped_array does not have at().
On less abstract cases the buffer overrun usually means that
the input data is somehow damaged or corrupted. Then it is
better to throw something that tells that the protocol has
not been followed, byte sequence is illegal or arguments are
incorrect. 

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

#69236

On 15/10/2019 21:44, Öö Tiib wrote:
> On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:
>> Do you use out_of_range when there's a buffer overrun? It seems to be the closest
> 
> May be if what you write is rather abstract class like
> boost::scoped_array and you implement at() function for it.
> BTW boost::scoped_array does not have at().
> On less abstract cases the buffer overrun usually means that
> the input data is somehow damaged or corrupted. Then it is
> better to throw something that tells that the protocol has
> not been followed, byte sequence is illegal or arguments are
> incorrect.

Bad input data isn't a logic error.

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

#69242

On Wednesday, 16 October 2019 00:44:04 UTC+3, Mr Flibble  wrote:
> On 15/10/2019 21:44, Öö Tiib wrote:
> > On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:
> >> Do you use out_of_range when there's a buffer overrun? It seems to be the closest
> > 
> > May be if what you write is rather abstract class like
> > boost::scoped_array and you implement at() function for it.
> > BTW boost::scoped_array does not have at().
> > On less abstract cases the buffer overrun usually means that
> > the input data is somehow damaged or corrupted. Then it is
> > better to throw something that tells that the protocol has
> > not been followed, byte sequence is illegal or arguments are
> > incorrect.
> 
> Bad input data isn't a logic error.

The logic_error means that the error is because of possibly
preventable logical inconsistency in input. But how can 
std::stoi() know that the out of range or illegal input
is coming from corrupt input data? Also for preventing the
inconsistency its caller has possibly to do most of what
stoi does itself.

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

#69255

On Wed, 2019-10-16, Öö Tiib wrote:
> On Wednesday, 16 October 2019 00:44:04 UTC+3, Mr Flibble  wrote:
>> On 15/10/2019 21:44, Öö Tiib wrote:
>> > On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:

>> >> Do you use out_of_range when there's a buffer overrun? It seems
>> >> to be the closest
>> > 
>> > May be if what you write is rather abstract class like
>> > boost::scoped_array and you implement at() function for it.
>> > BTW boost::scoped_array does not have at().
>> > On less abstract cases the buffer overrun usually means that
>> > the input data is somehow damaged or corrupted. Then it is
>> > better to throw something that tells that the protocol has
>> > not been followed, byte sequence is illegal or arguments are
>> > incorrect.
>> 
>> Bad input data isn't a logic error.
>
> The logic_error means that the error is because of possibly
> preventable logical inconsistency in input.

No; as I understand it it means faulty program logic, i.e. a
detectable bug, same as what the assert() macro is supposed to
be used for.

So since std::out_of_range is a std::logic_error, I guess you're not
supposed to use array::at() "speculatively".

Possibly I missed some context.

[snip]

/Jorgen

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

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

#69263

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

#69265

On 17/10/2019 01:15, The Doctor wrote:
> In article <05047d4c-6f30-4c4a-9c55-78e4e38516ee@googlegroups.com>,
> � ö Tiib  <ootiib@hot.ee> wrote:
>
> 57 lines no content.
>

There seems to be a general problem the last several hours - I've seen 
dozens of "no content" posts.  They all seem to be Google Groups 
posters, but possibly it's also related to my newsgroup servre (my ISP 
uses GigaNews).  The original messages are there on Google Groups..

Mike.

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

#69266

On 17/10/2019 15:31, Mike Terry wrote:
> On 17/10/2019 01:15, The Doctor wrote:
>> In article <05047d4c-6f30-4c4a-9c55-78e4e38516ee@googlegroups.com>,
>> � ö Tiib  <ootiib@hot.ee> wrote:
>>
>> 57 lines no content.
>>
> 
> There seems to be a general problem the last several hours - I've seen
> dozens of "no content" posts.  They all seem to be Google Groups
> posters, but possibly it's also related to my newsgroup servre (my ISP
> uses GigaNews).  The original messages are there on Google Groups..

Must be a GigaNews problem, everything is fine on news.individual.net.

-- 
Ian.

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

#69269

On 17/10/2019 04:35, Ian Collins wrote:
> On 17/10/2019 15:31, Mike Terry wrote:
>> On 17/10/2019 01:15, The Doctor wrote:
>>> In article <05047d4c-6f30-4c4a-9c55-78e4e38516ee@googlegroups.com>,
>>> � ö Tiib  <ootiib@hot.ee> wrote:
>>>
>>> 57 lines no content.
>>>
>>
>> There seems to be a general problem the last several hours - I've seen
>> dozens of "no content" posts.  They all seem to be Google Groups
>> posters, but possibly it's also related to my newsgroup servre (my ISP
>> uses GigaNews).  The original messages are there on Google Groups..
> 
> Must be a GigaNews problem, everything is fine on news.individual.net.
> 

I'm getting the blank messages on news.eternal-september.org also.
Maybe they get their feed from GigaNews, or maybe the problem is wider.

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

#69303

On Wed, 2019-10-16, Öö Tiib wrote:
> On Wednesday, 16 October 2019 22:02:46 UTC+3, Jorgen Grahn  wrote:
>> On Wed, 2019-10-16, Öö Tiib wrote:
>> > On Wednesday, 16 October 2019 00:44:04 UTC+3, Mr Flibble  wrote:
>> >> On 15/10/2019 21:44, Öö Tiib wrote:
>> >> > On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:
>> 
>> >> >> Do you use out_of_range when there's a buffer overrun? It seems
>> >> >> to be the closest
>> >> > 
>> >> > May be if what you write is rather abstract class like
>> >> > boost::scoped_array and you implement at() function for it.
>> >> > BTW boost::scoped_array does not have at().
>> >> > On less abstract cases the buffer overrun usually means that
>> >> > the input data is somehow damaged or corrupted. Then it is
>> >> > better to throw something that tells that the protocol has
>> >> > not been followed, byte sequence is illegal or arguments are
>> >> > incorrect.
>> >> 
>> >> Bad input data isn't a logic error.
>> >
>> > The logic_error means that the error is because of possibly
>> > preventable logical inconsistency in input.
>> 
>> No; as I understand it it means faulty program logic, i.e. a
>> detectable bug, same as what the assert() macro is supposed to
>> be used for.
>
> "The class logic_error defines the type of objects thrown as
> exceptions to report errors presumably detectable before the
> program executes, such as violations of logical preconditions
> or class invariants."

I.e. bugs.

> Seems they assume that something can detect coherency of all
> input data before program is ran.

But there is no such thing.  The way I read this thread (after
snipping, reconstruction and a weekend) std::logic_error is for bugs,
and std::stoi() misuses it.  And that's also what you argue.  Right?

>> So since std::out_of_range is a std::logic_error, I guess you're not
>> supposed to use array::at() "speculatively".
>> 
>> Possibly I missed some context.
>
> No, you snipped it. ;) You wanted to see only first sentence and
> not to read the context. See:
>
>> [snip]

Sorry.  What happened was I was too tired to read it all (and to read
the std::stoi documentation), but not too tired to read the sentence I
commented on and believed that, seen in isolation, I didn't agree with
it. So I complained about that isolated part, added the disclaimer,
and snipped because I didn't want to imply I had read all of it.

> "But how can std::stoi() know that the out of range or illegal
> input is coming from corrupt input data? Also for preventing
> the inconsistency its caller has possibly to do most of what
> stoi does itself."

Ok, so std::stoi() is new with C++11, tries to grab an int from a
string, and (among other things) throws std::out_of_range if the
string's number doesn't fit in an int.

That does seem a bit useless.

> The std::out_of_range and std::invalid_argument are other
> std::logic_errors that std::vector does not throw but 
> std::stoi throws. And indeed these are guarding logical
> preconditions that the text in the string is really number
> and that it does fit into int. However converting strings
> whose contents I know before program run into ints run-time
> using std::stoi feels even worse logic error. I can instead
> write those ints directly into code.

I agree.  I haven't used std::stoi, but I imagine if I /did/ use it
I would have to guard individual calls in try...catch, which to me
misses the point with exceptions.

/Jorgen

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

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

#69308

On Monday, 21 October 2019 01:18:14 UTC+3, Jorgen Grahn  wrote:
> On Wed, 2019-10-16, Öö Tiib wrote:
> > On Wednesday, 16 October 2019 22:02:46 UTC+3, Jorgen Grahn  wrote:
> >> On Wed, 2019-10-16, Öö Tiib wrote:
> >> > On Wednesday, 16 October 2019 00:44:04 UTC+3, Mr Flibble  wrote:
> >> >> On 15/10/2019 21:44, Öö Tiib wrote:
> >> >> > On Tuesday, 15 October 2019 13:00:44 UTC+3, Frederick Gotham  wrote:
> >> 
> >> >> >> Do you use out_of_range when there's a buffer overrun? It seems
> >> >> >> to be the closest
> >> >> > 
> >> >> > May be if what you write is rather abstract class like
> >> >> > boost::scoped_array and you implement at() function for it.
> >> >> > BTW boost::scoped_array does not have at().
> >> >> > On less abstract cases the buffer overrun usually means that
> >> >> > the input data is somehow damaged or corrupted. Then it is
> >> >> > better to throw something that tells that the protocol has
> >> >> > not been followed, byte sequence is illegal or arguments are
> >> >> > incorrect.
> >> >> 
> >> >> Bad input data isn't a logic error.
> >> >
> >> > The logic_error means that the error is because of possibly
> >> > preventable logical inconsistency in input.
> >> 
> >> No; as I understand it it means faulty program logic, i.e. a
> >> detectable bug, same as what the assert() macro is supposed to
> >> be used for.
> >
> > "The class logic_error defines the type of objects thrown as
> > exceptions to report errors presumably detectable before the
> > program executes, such as violations of logical preconditions
> > or class invariants."
> 
> I.e. bugs.

Somehow the preconditions are violated.  Can be bug in this
program, can be data in file got corrupted, can be a person
prepared it wrongly manually or can be other, external program
made it wrongly.

> > Seems they assume that something can detect coherency of all
> > input data before program is ran.
> 
> But there is no such thing.  The way I read this thread (after
> snipping, reconstruction and a weekend) std::logic_error is for bugs,
> and std::stoi() misuses it.  And that's also what you argue.  Right?

If logic_error means only programming bug then yes, but it seems that  
it is not the case. It is wider in standard so it seems to be intent. For 
example we have similar logic_errors (invalid_argument) thrown by
std::bitset constructors (from string or char*) and several other places.

When there is code that does std::map::find, then compares it with
std::map::end and if equal then throws something otherwise continues
using found_iterator->second then why we may not use std::map::at
instead that does same and we get reference not that ->second bloat?

> >> So since std::out_of_range is a std::logic_error, I guess you're not
> >> supposed to use array::at() "speculatively".
> >> 
> >> Possibly I missed some context.
> >
> > No, you snipped it. ;) You wanted to see only first sentence and
> > not to read the context. See:
> >
> >> [snip]
> 
> Sorry.  What happened was I was too tired to read it all (and to read
> the std::stoi documentation), but not too tired to read the sentence I
> commented on and believed that, seen in isolation, I didn't agree with
> it. So I complained about that isolated part, added the disclaimer,
> and snipped because I didn't want to imply I had read all of it.

No problem.

> > "But how can std::stoi() know that the out of range or illegal
> > input is coming from corrupt input data? Also for preventing
> > the inconsistency its caller has possibly to do most of what
> > stoi does itself."
> 
> Ok, so std::stoi() is new with C++11, tries to grab an int from a
> string, and (among other things) throws std::out_of_range if the
> string's number doesn't fit in an int.
> 
> That does seem a bit useless.

It is useful in sense that it is never thrown when the number fits into
int. When it is thrown then it depends on context how we should
react. If the string came from configuration of program then we
likely should refuse to run the program (as misconfigured). If it did
come from network request then we perhaps should reject only the
request (with some error code like 400). 
 
> > The std::out_of_range and std::invalid_argument are other
> > std::logic_errors that std::vector does not throw but 
> > std::stoi throws. And indeed these are guarding logical
> > preconditions that the text in the string is really number
> > and that it does fit into int. However converting strings
> > whose contents I know before program run into ints run-time
> > using std::stoi feels even worse logic error. I can instead
> > write those ints directly into code.
> 
> I agree.  I haven't used std::stoi, but I imagine if I /did/ use it
> I would have to guard individual calls in try...catch, which to me
> misses the point with exceptions.

That seems to depend on context. For examples that I gave
already above it may mean that configuration file of program is
defective or that single external request is defective. 
What can immediate caller do to handle the situation? Take
some "default" int value? That is likely transgressing over its
responsibilities. Maybe I misunderstand your point.
On most cases we should let exceptions to propagate to level that
started the whole operation that now apparently failed (like reading
configuration or parsing incoming request).  

[toc] | [prev] | [standalone]

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

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

csiph-web