[Fwd: Re: cvs commit: src/include ctype.h src/lib/libc/gen isctype.c tolower.c toupper.c]

[Devon H. O'Dell]

Sorry, forgot to hit the reply all button.

--Devon
--- Begin Message ---



From:

"Devon H. O'Dell" <dodell at xxxxxxxxxxxxxxx>




Date:

Thu, 07 Jul 2005 11:53:41 -0700



Chris Pressey wrote:
On Thu, 7 Jul 2005 10:36:29 -0700 (PDT)
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:

:> Currently return 0 if the integer is
:> out of range (it might be more appropriate to assert).
:
:It is definately more appropriate to assert IMO.
:
:-Chris
   Well, it's hard to say.  If the standard said we should assert,
   then we should assert.


Obviously ;)


   But the programmer might not have the expectation  
   of an is*() call *EVER* causing the program to exit.


If the behaviour is undefined, then the programmer is not allowed to
have expectations.  And it's courteous of us to inform them of their
unwarranted expectations, in as explicit a way as possible.  To me,
this means an assert.
If you're worried about programs that have been written to a lower
standard, such that they rely on behaviour that the (actually
in-effect-now) standard has since defined as "undefined", then I'd have
to go back to the idea of a conformancy switch.  i.e.:  Be liberal in
what we accept and strict in what we produce AND have an optional switch
that makes us strict in what we accept.
Such a compromise sounds good, but from a programmer's point of view, I 
would think that the optional switch might allow the leniency (i.e. be 
strict by default). This would allow to more easily catch programs that 
are frequenly used and lax in their implementation. If it's not expected 
that many programs will fault from this, I don't see why it shouldn't be 
done this way -- it'll help fix programs, and if that's not worth it, 
the behavior can still be turned off.

Just my 2c,
NO! 2C IS MINE! *ducks*

-Chris
--Devon

--- End Message ---