This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch/rebase] Add a rebase database to keep track of DLL addresses


On Thu, Jul 07, 2011 at 10:26:09AM +0200, Corinna Vinschen wrote:
>On Jul  6 15:35, Charles Wilson wrote:
>> On 7/6/2011 2:30 PM, Corinna Vinschen wrote:
>> > On Jul  6 11:27, Charles Wilson wrote:
>> >> (And there ARE cases where they CAN be null: e.g. the newly-allocated
>> >> entries at the tail of the list -- since you allocate in rounded-up
>> >> chunks of 100(?); the name pointers are, of course, explicitly SET to
>> >> null when reading data in from the db, prior to reading and allocating
>> >> storage for the strings themselves, etc).
>> > 
>> > Oh, come on.
>> 
>> I didn't say there was anything wrong.  I'm trying to make sure *I*
>> understand: these functions do not check against null, but the
>> algorithm, elsewhere, is structured such that null checks are not
>> required.  That's fine; I just wanted to be sure I understood.
>
>It didn't read that way.  The comparison functions are used by bsearch
>and qsort only, so the argument pointers can never be NULL unless the
>array itself is NULL.  The name members are always allocated when a new
>member is added to the array, so they can never be NULL, either.  This
>was pretty much clear from the start so how do you think does it sound
>to get a lecture in a purely theoretical problem?
>
>> Look, I'm used to *extremely* defensive programming on critical embedded
>> systems, where a segfault means somebody [might] die. So every function
>> has to check and handle illegal input -- or has to document why it
>> doesn't need to do so; you don't treat segfaults as a
>> programmer-error-detection mechanism ("bug in the calling function").
>
>Point taken.  Nevertheless, even in this scenario you concentrate on
>the real problems of a function, not the theoretical ones.

Also, in embedded systems you tend to worry about space so adding
defensive tests for impossible conditions wastes critical memory.

(I work on embedded systems too and fight every day with people who
think memory is cheap)

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]