[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Apr 2013 08:32:26 +0200
From: Gregor Pintar <grpintar@...il.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
2013/4/30, Rich Felker <dalias@...ifal.cx>:
> On Mon, Apr 29, 2013 at 11:55:00PM +0200, Szabolcs Nagy wrote:
>> * Gregor Pintar <grpintar@...il.com> [2013-04-29 19:35:03 +0200]:
>> > > (eg hash_update(ctx, buf, len) should never fail
>> > > even if there is a counter in ctx that can overflow
>> > > every 2^64th bit of input, documenting the behaviour
>> > > for longer inputs is better, it would be even better
>> > > if the apropriate standards were more careful about
>> > > failures)
>> > Devs that ignore return values would probably ignore documentation too.
>>
>> i think the problem is not ignorance, but the combinatorial
>> explosion of code paths which increases bug probability
>>
>> in my view the purpose of error codes is to indicate runtime
>> errors (eg allocation or io failures) and not to prevent bugs
>> in the program logic (there are other tools for that, most
>> notably the type checker, adding extra error handling paths
>> for bug prevention usually makes things worse)
>
> Agreed. You've expressed the issue very concisely and effectively. The
> way I tend to think of it is that error codes should express a
> condition that can occur in a correct program. If the condition can't
> occur in a correct program, no effort should be spent at runtime
> detecting it. If a program is going to go about detecting error codes
> that couldn't occur without a bug in the program, though, it should do
> so via assert() rather than complex error-propagation logic.
>
My idea was that program would be correct, if it inputs too much data
to hash function. It is very cheap to implement in most algorithms
(detect counter overflow). Otherwise program has to count it himself.
However, in most cases it is too late to handle correctly when it
already fails. Not returning error on too much input or output could
silently cause incorrect usage. Using assert might be better idea
since at that point it is fatal anyway, but that would cause data
leak, unless program would catch SIGABRT (it should others like SIGINT
anyway) and wipe data, but that requires all sensitive data in program
is global.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
