Date: Fri, 25 Aug 2000 18:59:51 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: radsmail AT juno DOT com
Message-Id: <1438-Fri25Aug2000185950+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
CC: djgpp AT delorie DOT com
In-reply-to: <ue4cqsg0k83m0461605mnkssjo43odacen@4ax.com> (message from
	Radical NetSurfer on Fri, 25 Aug 2000 02:44:18 -0400)
Subject: Re: BAD strupr, BAD getw
References:  <ue4cqsg0k83m0461605mnkssjo43odacen AT 4ax 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

> From: Radical NetSurfer <radsmail AT juno DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 25 Aug 2000 02:44:18 -0400
> 
> Tonight we had to create our very own code for
> 
> strupr
> 
> simply because DJGPP does NOT implement this function
> correctly at ALL :(

I'm sorry for your wasted efforts, because I don't see anything wrong
with DJGPP's implementation of strupr.  Would you care to show where
does it do the wrong thing?  The source is freely available; I attach
it below for your convenience.

> "abce'def"  -->  "ABCe'DEF"   expected!  BORLAND: CORRECT!
>                         " ABC?def"     <--   DJGPP  INCORRECT  :(

I cannot reproduce this; a simple test program I wrote works for me as
I'd expect.  Please post a short test program that exhibits the
incorrect behavior.  Please also tell what numeric code did you use
for the non-ASCII character in the original string, since mail
software can easily change it (I tried several popular possibilities,
but all of them worked for me).

Note that DJGPP's ctype functions currently don't support non-ASCII
characters, so don't expect these characters to be upcased by strupr:
the correct behavior is to leave them unaltered.

> observed behavior is:
> 
> STOP when FIRST non Alpha character is encounted!
> this is NOT the way compilers as far back as I am aware of,
> have ever handled   strupr,   strlwr !!

Please stop shouting, it doesn't help to find out the truth.  As I
said, strupr works for me as expected, and it does NOT stop at the
first non-ASCII character.

> WHY would you want a StrUpr/Lwr routine to STOP on the first
> non-Alpha character --- or replace what appear to be ILLEGAL
> characters

We don't.  We aren't.  strupr works.  Check your code.

> -- if simple DIGITs where also encountered what happens
> (check that too guys)?

We already did check this; it works as it should.  Please stop
insulting people whom you don't even know, and who gave you for free
the entire DJGPP project, a product of many years of hard work.

> DJGPP places illegal characters in the string || stops at the illegal
> character.

No, it doesn't.

> int getw(FILE *file);
> 
> this is INCORRECT!

It's correct; see below.

> get-WORD()  should of been defined as:
> 
> short getw(FILE*);
> 
> as a WORD is "typically/natively" DEFINED AS 16-BIT!

I don't see any problem here: simply put the result of getw into a
short variable, and you are done.  getw *does* read only 16 bits from
the file, it just returns it in an int, that's all.  But the upper
bits of that int are not used (except for sign-extension, for negative
values).  So you *do* get a short, as you should.

In contrast, what you propose--declare getw as returning a short--
will actually get many programs in trouble if they don't include
stdio.h, or if they compile with the -ansi switch.  That's because by
default any function's return value is promoted to int.

So, as you see, DJGPP does the Right Thing; you simply misunderstood
that.  Was it worth it to shout and insult just to realize that you
are mistaken?

Here's the source code of DJGPP's strupr, as promised:

#include <ctype.h>
#include <string.h>

char *
strupr(char *_s)
{
  char *rv = _s;
  while (*_s)
  {
    *_s = toupper((unsigned char)*_s);
    _s++;
  }
  return rv;
}