X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Sun, 26 Dec 2004 00:49:51 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-ID: <01c4ead4$Blat.v2.2.2$30c06ce0@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2
In-reply-to: <CZOdnQS-wOQaWFDcRVn-gQ@comcast.com> (message from Joe Wright on
	Sat, 25 Dec 2004 14:54:54 -0500)
Subject: Re: CTYPE stuff for Eli or DJ
References: <KpSdnePxHo9G_VHcRVn-oQ AT comcast DOT com> <200412241848 DOT iBOImiRM013524 AT envy DOT delorie DOT com> <Ub6dnQHCSdfA-lHcRVn-1w AT comcast DOT com> <200412241919 DOT iBOJJnq5014101 AT envy DOT delorie DOT com> <ZrGdnQaTgL1eIlHcRVn-vg AT comcast DOT com> <01c4ea6a$Blat.v2.2.2$88d35240 AT zahav DOT net DOT il> <fe-dnemo0_kzyFDcRVn-2A AT comcast DOT com> <200412251642 DOT iBPGge9n026679 AT envy DOT delorie DOT com> <CZOdnQS-wOQaWFDcRVn-gQ AT comcast DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sat, 25 Dec 2004 14:54:54 -0500
> From: Joe Wright <joewwright AT comcast DOT net>
> 
> > The correct thing to return, when the program passes you an erroneous
> > input, is an error signal and set errno to ERANGE.  Since the ctype
> > functions have no way of returning an error signal directly, the error
> > must be signalled indirectly.  We do this by segfaulting.  If you want
> > to handle the error, install a segfault handler.
> > 
> DJ, are you just having a bad day?

If so, then so am I, because I agree with DJ.

> 'We do this by segfaulting'? Who is 'We'? Do you mean the 
> implementor?

Yes, ``we'' the implementor, the people who wrote the DJGPP library.
Mostly, that means DJ himself, because most of the library code is due
to his work.

> There is no reference in the Standard about the 
> implementation segfaulting and what the user should do about it. 

The Standard doesn't mention a segfault, but it does say

    In all cases the argument is an int, the value of which shall be
    representable as an unsigned char or shall equal the value of the
    macro EOF.  If the argument has any other value, the behavior is
    undefined.

``Our'' variant of undefined behavior is a segfault.

> What is a segfault handler? Do you offer one with DJGPP?

Yes.  If you define a signal handler for the SIGSEGV signal (via the
library functions `signal' or `sigaction', which see), your handler
will be called when the program segfaults.  You can then do whatever
you wish, even cause the program to continue as if nothing happened.

> [((unsigned)(c)+1)&(UCHAR_MAX*2+1)]
> 
> ..as our index? It doesn't punish us for invalid input simply 
> because there is no such thing. What do 'We' say about that?

``We'' ask you again: why do you think that returning a zero is okay
for the is* macros in that case?  A zero is a valid return value: it
means, for example, that the argument is not a printable character.
Why is that the right thing to do for an argument that is not a
single-byte value?  Suppose that the program erroneously invokes
`isprint' with a wide character that represents some Unicode
codepoint--how on Earth can we know whether it's printable or not?