Re: [Lit.] Buffer overruns

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 12/24/04 

Date: Fri, 24 Dec 2004 06:37:20 +0000 (UTC)

Douglas A. Gwyn wrote:
>> public Object get(int i) {
>> // NOTE: The array bounds check can be safely omitted.
>> // A malicious caller might pass in an out-of-bounds index,
>> // but then they are just going to get an ArrayBoundsException
>> // -- no big deal.
>> return contents[i];
>> }
>
>That is *not* "doing the right thing with buffers"; it is
>irresponsible programming. Whatever function was supposed
>to be performed is aborted as a consequence of lack of care
>in the surrounding app. It could very well be a "big deal".

I don't know why you think it is irresponsible. Suppose the documented
interface to get() says that it is the caller's responsibility to supply
an in-bounds index, and the interface specifies that the caller will
receive an exception if the index is out of bounds. Then the above code
implements exactly the promised interface. If you have a complaint, the
complaint is not with the code, but with the interface. However, I don't
see why such an interface would be necessarily irresponsible; whether that
is an appropriate interface will depend on context, and in some contexts,
it might be a reasonable and responsible choice.

You raised a concern that the caller might be "aborted". I think what
you mean is that calling get() might throw an exception if the argument
is out of bounds. I don't know why you think that is necessarily
irresponsible. If the documented interface says that get() might raise
an exception, then it is up to the caller to either catch the exception
(if the caller cares about it) and handle or re-throw the problem, or to
decide not to catch the exception (if the caller decides that the right
thing is that the exception should be propagated on).

I assert that there are contexts where the above code might well be
reasonable. I do not know why you call it irresponsible programming.

Relevant Pages

  • 7.0 wishlist?
    ... Any object can be used where an interface type is expected if it has the right set of method signatures, whether or not it "implements" the interface using that keyword. ... the algorithm name is hard-coded and so this exception ... Most invocations of runnables ... Allow subclassing an enum with the subclasses able to REMOVE (not ...
    (comp.lang.java.programmer)
  • Re: Objekt einfrieren?
    ... public interface Freezable { ... public class FrozenException extends RuntimeException { ... welches neben E auch noch Freezable ... fo.setX; // gibt eine Exception ...
    (de.comp.lang.java)
  • Re: Some questions about handling exceptions and when to throw them
    ... In the event that a customer can't be ... Possibly even my own exception, ... because the caller should have checked first. ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Some questions about handling exceptions and when to throw them
    ... So in those cases throwing an exception would be a good decision. ... because the caller should have checked first. ... PrinterInfo GetEmployeeDefaultPrinter ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Exception handling help please
    ... > void MyFunc() ... > Then in the caller: ... Second, if you throw an object of a class derived from MyException, ... The copy of the exception object specified in the throw expression ...
    (comp.lang.cpp)