X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Sat, 25 Dec 2004 22:46:20 -0500
Message-Id: <200412260346.iBQ3kKSW003577@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp AT delorie DOT com
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>
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


> DJ, are you just having a bad day? It's Christmas. Lighten up.

If you've been around long enough, you'd realize that I don't do
Christmas.

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

Yes, that would probably be me, but it's certainly the DJGPP
development team, as we wrote that code.

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

You can use signal() to trap segfaults, but the best way to do it is
to NOT trap segfaults, and use gdb to debug your program.

> There's that 'We' again.

Yup, we is us.  Check the copyright on those headers.

> It is not up to you to punish me for writing code you consider bad.

No, but it is my job to help you write the best code you can.

> Think about it. Your job as implementor is to provide the most
> robust environment possible for me to play in. It is not your job to
> catch me out.

It *is* my job to implement the standards in the most efficient way,
though.  Encouraging people to write portable conforming code is just
a bonus.  Even if we *did* change our libc, the next system you
compile on will just fail in a different mysterious way.  We serve the
programmers best by helping them write code that will "just work" on
*every* system.

In cases where a majority of the C implementations out there do
something extra to help the programmer, we do that too.  A majority of
the implementations out there do ctype the way we do, so if we "fix"
it we're just setting you up for failure on the next OS you write
software for.

> It is on the other hand, my (the user's) job to catch you out. This
> so that you can produce an even more robust environment to your
> audience.

If you find a case where standards conforming calls to our functions
cause our functions to fail, we want to know.  If you feed our
functions garbage and get garbage back, don't complain.

> How about this..
> 
> [((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 say that would be wasting memory, since conforming programs would
never need the extra buffer.

> PS. I'm older than you and I might have more time on my hands.

Perhaps you could use some of that time fixing your software to do the
right thing ;-)