- Which exception for a buffer overrun? - 21 Updates
- strange issue ... - 1 Update
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 15 03:00AM -0700 Do you use out_of_range when there's a buffer overrun? It seems to be the closest |
| melzzzzz <mel@melzzzzz.com>: Oct 15 12:52PM +0200 > Do you use out_of_range when there's a buffer overrun? It seems to be the closest I decided not to use exceptions in new programs... -- press any key to continue or any other to quit... ----Android NewsGroup Reader---- http://usenet.sinaapp.com/ |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 01:54PM +0300 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. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 15 04:08AM -0700 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? Are you one of those people who will only use something for the one specific use that it says on the box? I'm curious what your stance is on exception throwing in recursive functions (instead of conditional return statements)? |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Oct 15 01:09PM +0200 Op 15.okt..2019 om 12:54 schreef Paavo Helde: > 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. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 15 11:12AM 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 . |
| David Brown <david.brown@hesbynett.no>: Oct 15 01:35PM +0200 On 15/10/2019 13:09, Fred. Zwarts wrote: > 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). |
| melzzzzz <mel@melzzzzz.com>: Oct 15 01:49PM +0200 > 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/ |
| David Brown <david.brown@hesbynett.no>: Oct 15 01:57PM +0200 On 15/10/2019 13:08, Frederick Gotham wrote: >> 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? I'd say yes. Aim to use the right tool for the job. Use a poorer choice of tool if you can't get the right tool, but only if there is no option. <https://www.youtube.com/watch?v=B84pS6JTI9A> > Are you one of those people who will only use something for the one > specific use that it says on the box? I can't answer for Paavo, but I am one of these people who try to think out the best way to handle a task. > I'm curious what your stance is on exception throwing in recursive > functions (instead of conditional return statements)? In C++, throwing an exception is usually /massively/ slower than returning a code. It can easily be thousands of times slower. And for recursive functions, it probably scales in time with the depth of the recursion - and may limit optimisations of the functions. Exceptions are fine when the situation is very rare and you don't have requirements for worst-case latency, or where there is no sensible way to handle the situation (like running out of memory), or when efficiency doesn't matter and they make the code simpler and clearer (perhaps for network or file errors). They are a bad idea for normal processing as an alternative to return values. (The balance here will change significantly once static exceptions are part of the language - they will be a great deal more efficient, and a great deal easier for compile-time checking to support, at the cost of less flexibility). |
| David Brown <david.brown@hesbynett.no>: Oct 15 01:59PM +0200 On 15/10/2019 13:49, melzzzzz wrote: <snip jumbled quotations> > 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. |
| scott@slp53.sl.home (Scott Lurndal): Oct 15 01:30PM >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. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 15 02:48PM On Tue, 2019-10-15, Fred. Zwarts wrote: > 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 . |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 05:48PM +0300 On 15.10.2019 14:08, Frederick Gotham 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. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 06:37PM +0300 On 15.10.2019 17:48, Jorgen Grahn wrote: >> 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". |
| melzzzzz <mel@melzzzzz.com>: Oct 15 06:48PM +0200 > 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/ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 06:21PM +0100 On 15/10/2019 11:54, Paavo Helde wrote: > 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." |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 15 08:32PM > 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? -- 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 |
| "Öö Tiib" <ootiib@hot.ee>: Oct 15 01:44PM -0700 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. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 10:43PM +0100 On 15/10/2019 21:44, Öö Tiib wrote: > 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." |
| Soviet_Mario <SovietMario@CCCP.MIR>: Oct 15 11:59PM +0200 On 15/10/2019 13:57, David Brown wrote: > part of the language - they will be a great deal more efficient, and a > great deal easier for compile-time checking to support, at the cost of > less flexibility). mine is just a no more than a hobbist tinkerer's opinion, but ... even if I surely won't object to performance issues, another (often contrasting) point of view would be readability and cross-usability of code I mean, often I feel the need of "consistent" (= UNIFORM) error management. Even if surely more performant, mixed management can be difficult to understand and use. So some importance maybe should also be given to the choice of using the same tool systematically for every problem of the same nature (errors), regardeless of its performance potential problems. Also "snippet" reuse is hindered by mixed use of both exceptions and return types, and maybe it's more error prone. One thing I really can't stand is the way C used to share a single variable (errno) to store status, that may be overwritten unpredictably -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| scott@slp53.sl.home (Scott Lurndal): Oct 15 10:13PM >One thing I really can't stand is the way C used to share a >single variable (errno) to store status, that may be >overwritten unpredictably Can you elaborate? It was well understood and documented when errno could be modified (on any system or library call). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 15 11:54AM -0700 On Friday, October 11, 2019 at 9:06:22 AM UTC-4, Bonita Montero wrote: ... > } > Bút the other code simply doesn't matter. > It is just for your stupidity. In your original message, you simplified the problem down to: > { > return ABC; > } In later messages, you clarified that ABC is actually FREE_NODE. The error message you cited objects to LruCache<unsigned long, unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<char> >::FREE_NODE, so A is presumably LruCache. However, which function is A::B::f() a simplification of? My first thought was that B was Node, but your definition for Node doesn't declare any functions. I don't actually need the name or declaration for the real function corresponding to f, merely it's relationship to the classes you've already mentioned. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment