HDTenEightyP/NetNews huggingface dataset:
From: h.b.furuseth@usit.uio.NO
Newsgroups: gnu.gcc.bug
Subject: Bugs in gcc-2.3.3/cccp.c
Date: 25 Jan 1993 21:19:01 -0500
Organization: GNUs Not Usenet
Distribution: gnu

A few bug fixes to cccp - 

Page 1: There was a jump into the block, past the initialization of
variable already_output.

Page 2: finclude() called trigraph_pcp without a terminating \0 in the
input string.

Page 3: A little memory leak.


*** cccp.c~	Mon Jan 25 21:35:51 1993
--- cccp.c	Mon Jan 25 21:33:57 1993
***************
*** 3159,3163 ****
     */
    for (kt = directive_table; kt->length > 0; kt++) {
!     if (kt->length == ident_length && !strncmp (kt->name, ident, ident_length)) {
        register U_CHAR *buf;
        register U_CHAR *limit;
--- 3159,3165 ----
     */
    for (kt = directive_table; kt->length > 0; kt++) {
!     if (kt->length == ident_length && !strncmp (kt->name, ident, ident_length))
!  old_linenum:
!  {
        register U_CHAR *buf;
        register U_CHAR *limit;
***************
*** 3170,3175 ****
        int keep_comments;
  
-     old_linenum:
- 
        limit = ip->buf + ip->length;
        unterminated = 0;
--- 3172,3175 ----



*** cccp.c~	Mon Jan 25 21:35:51 1993
--- cccp.c	Mon Jan 25 21:33:57 1993
***************
*** 4115,4118 ****
--- 4115,4126 ----
    }
  
+   if ((fp->length > 0 && fp->buf[fp->length - 1] != '\n')
+       /* Backslash-newline at end is not good enough.  */
+       || (fp->length > 1 && fp->buf[fp->length - 2] == '\\')) {
+     fp->buf[fp->length++] = '\n';
+     missing_newline = 1;
+   }
+   fp->buf[fp->length] = '\0';
+ 
    /* Close descriptor now, so nesting does not use lots of descriptors.  */
    close (f);
***************
*** 4127,4138 ****
      trigraph_pcp (fp);
  
-   if ((fp->length > 0 && fp->buf[fp->length - 1] != '\n')
-       /* Backslash-newline at end is not good enough.  */
-       || (fp->length > 1 && fp->buf[fp->length - 2] == '\\')) {
-     fp->buf[fp->length++] = '\n';
-     missing_newline = 1;
-   }
-   fp->buf[fp->length] = '\0';
- 
    output_line_command (fp, op, 0, enter_file);
    rescan (op, 0);
--- 4135,4138 ----



*** cccp.c~	Mon Jan 25 21:35:51 1993
--- cccp.c	Mon Jan 25 21:33:57 1993
***************
*** 4578,4581 ****
--- 4578,4582 ----
      }
    }
+   free (line_command);
  }
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: gnu.gcc.bug
Subject: [kevinc@kpc.com: gcc v2.3.3 bug]
Date: 26 Jan 1993 22:24:11 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: brendan@cygnus.com (Brendan Kehoe)

------- Start of forwarded message -------
From: kevinc@kpc.com
Subject: gcc v2.3.3 bug
To: bug-g++@prep.ai.mit.edu
Cc: kevinc@solman.kpc.com
Date: Tue, 19 Jan 93 17:17:52 -0800

   I have found what I consider to be a bug in the optimizer for gcc.  I
realize that the issue of whether something is a bug is not always clear
when talking about a compiler's optimization.  One can always argue about
how far the optimizer should go.  I am calling this a bug since code is
generated which does absolutely nothing and it seems that the compiler
has ample information to avoid the behavior.

   What I found is a case where the optimizer does a very good job of
unrolling a loop to the point where it knows the result. It then iterates
the loop anyway.

   By the way, I am not just trying to cause trouble.  I have found a true
bug which causes the compiler to crash with the message "Internal compiler
error" when the -funroll-loops flag is set.  I am trying to reduce the
program to the smallest case which reproduces the bug.  In so doing I found
the bug that I am reporting now.

Machine: Sun Sparcstation 2
OS:      SunOS 4.1.3
GCC:     2.3.3

C++ source code (test.cc)
- ------------------------
#include <stdio.h>

main () {
   int i = 0 ;
   for (int j = 0; j < 500000; j++) {
      i += 1 ;
      }
   printf ("sums = %d\n", i) ;
   }
- ------------------------

I compile the above program with the command:

g++ -S -O2 -funroll-loops test.c

Assembler output (test.s)
- ------------------------
gcc2_compiled.:
.text
   .align 8
LC0:
   .ascii "sums = %d\12\0"
   .align 4
   .global _main
   .proc 04
_main:
   !#PROLOGUE# 0
   save %sp,-136,%sp
   !#PROLOGUE# 1
   call ___main,0
   nop
   mov 0,%o1
   sethi %hi(499999),%o0
   or %o0,%lo(499999),%o0
   add %o1,10,%o1
L26:
   cmp %o1,%o0
   ble,a L26
   add %o1,10,%o1
   sethi %hi(LC0),%o0
   or %o0,%lo(LC0),%o0
   sethi %hi(500000),%o1
   call _printf,0
   or %o1,%lo(500000),%o1
   ret
   restore %g0,0,%o0
- -----------------

The following section from above seems to be totally unneeded.:
   mov 0,%o1
   sethi %hi(499999),%o0
   or %o0,%lo(499999),%o0
   add %o1,10,%o1
L26:
   cmp %o1,%o0
   ble,a L26
   add %o1,10,%o1

Note that the compiler has already determined the result of the loop
(500000) and is using it as a constant parameter to printf.  Surely
it has enough information to avoid the loop altogether.

Please acknowledge receipt of this message.  Also I would like to
remain informed of the status of this bug as it passes through your
system if that is possible.

Kevin Cameron
kevinc@kpc.com

------- End of forwarded message -------

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400
                     ``In a cruel and imperfect world,'' says critic Rex Reed,
 ``[Audrey Hepburn] was living proof that God could still create perfection.''
From: daveg@thymus.synaptics.COM (Dave Gillespie)
Newsgroups: gnu.gcc.bug
Subject: Gcc 2.1 scoping bug
Date: 25 Jan 1993 21:30:02 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: daveg@synaptics.com

I've found an inconsistency with gcc 2.1 vs. the ARM concerning C++
scoping rules.  Briefly, the ARM states (10.4) that member names
always shadow global names inside a member function, but this does
not seem to be the case when a member function shadows a global
type name.

% gcc -v bug1.cxx
Reading specs from /packages/lib/sun4/gcc-lib/sparc-sun-sunos4.1.2/2.1/specs
gcc version 2.1
 /packages/lib/sun4/gcc-lib/sparc-sun-sunos4.1.2/2.1/cpp -lang-c++ -v -I/syn/inc
lude -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__spa
rc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix bug1.cxx /usr/tmp/cca06131.
i
GNU CPP version 2.1 (sparc)
 /packages/lib/sun4/gcc-lib/sparc-sun-sunos4.1.2/2.1/cc1plus /usr/tmp/cca06131.i
 -quiet -dumpbase bug1.cc -version -o /usr/tmp/cca06131.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 /packages/lib/sun4/gcc-lib/sparc-sun-sunos4.1.2/2.1/as -o bug1.o /usr/tmp/cca06
131.s
 ld -e start -dc -dp /lib/crt0.o -L/packages/lib/sun4/gcc-lib/sparc-sun-sunos4.1
.2/2.1/ -L/packages/lib/sun4/ bug1.o -lgcc -lc -lgcc
% a.out
range::range
% cat bug1.cxx
#include <stdio.h>

class range {
public:
  range() { printf("range::range\n"); }
};

class image {
public:
  void range() { printf("image::range\n"); }
  void foo() { range(); }
};

main()
{
  image I;
  I.foo();
}

%

Sun's cfront-based compiler produces the output "image::range" on
this program.  Gcc seems to exhibit this bug whether or not "foo"
is inline, and whether or not the two "range"s take any arguments
(as long as the arguments are the same in all three places).

Interestingly, if an "int" argument is added to the "range" function
and the "range" call, but *not* to the "range" constructor, gcc
agrees with cfront.  This also seems suspicious, as C++ scoping
and overload resolution are supposed to work independently.

Thanks,
								-- Dave
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: gnu.gcc.bug
Subject: [cote@tesecau.iro.umontreal.ca : Problem with increment operator]
Date: 26 Jan 1993 22:25:48 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: brendan@cygnus.com (Brendan Kehoe)

------- Start of forwarded message -------
From: cote@tesecau.iro.umontreal.ca (Marcel Cote)
Subject: Problem with increment operator
To: bug-g++@prep.ai.mit.edu
Date: Fri, 22 Jan 1993 03:12:32 GMT
Newsgroups: gnu.g++.bug
Organization: Universite de Montreal, Canada

To whom it may concern,

	This letter is to ask if you have any information concerning a discrepancy
I found while preparing data for a course.  The machine I was working on was a 
Sparc II with the operating system SunOS release 4.1.3.  There are no problems for 
compiling but at execution there is a segmentation fault.  The version of the 
compiler was gcc 2.3.3.  The fault line is indicated below.  If you omit the      
incrementation operator, the problem is corrected.  If I'm correct the syntax
is not faulty, even your debugger will permit to display the result. 

main()
{ char *a= "a";
  printf("%c\n",++a[0]);
}




------- End of forwarded message -------

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400
                     ``In a cruel and imperfect world,'' says critic Rex Reed,
 ``[Audrey Hepburn] was living proof that God could still create perfection.''
From: rms@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.gcc.bug
Subject: g++ bug? (NOPE!)
Date: 22 Jan 1993 21:11:30 -0500
Organization: GNUs Not Usenet
Distribution: gnu

    I ran our current compiler (Cygnus-2.3.3) against the sources you
    enclosed in your message, and I found that it worked for all 3
    versions of main.C (main.C, bak2, and bak3).  I suggest you forward
    this message to your professor and have her (or him) ask the computer
    service people to update the compiler you have installed at UCSC.

The version they would upgrade to is GCC 2.3.3.  It looks like
you tried it in a Cygnus offshoot version, not the current release.
Do you know whether it works in the current release?
From: bof@midget.saar.DE (Patrick Schaaf)
Newsgroups: gnu.gcc.bug
Subject: Re: Prototype handling bug(?) in 2.3.3
Date: 25 Jan 1993 20:54:17 -0500
Organization: GNUs Not Usenet
Distribution: gnu

In reply to Jason Merrills message on "Re: Prototype handling bug(?) in 2.3.3"
>Suppose you have
>void foobar();
>short a, b;
>foobar(a,b);
>void foobar(c,d)
>	short c,d;
>{
>}
>
>Then are c and d promoted to int as well?  Just curious.

Because foobar is declared and defined without a prototype, the parameters are
always passed as ints. The
	short c,d;
instructs the compiler to _interpret_ the two arguments as shorts (i.e.
retrieve the correct part of them according to the byte sex of the machine
it compiles for).

>I would agree with that.  Unfortunately, the compiler message is an error,
>not a warning, so I am forced to comment out the first prototype somehow.
>Unfortunately, it is in one of the system headers, which makes that an
>annoying task.

_Especially_ in this case, GnuC is helping you by making this an error.
The non-prototype declaration in the system include file tells you that
your getpwuid _expects_ to be called with an int on the stack, regardless
of how many bits of it it really uses. Now, you introduce the prototype
struct passwd *getpwuid(u_short uid);
which, if treated as a warning, gives GnuC two possibilities to proceed:
  - ignore your own prototype, and pass the parameters as an int.
    this would work in your case, but it wouldn't work if getpwuid were
    your own function, defined in some other module with a prototype
    argument list. In this case you would prefer
  - use your own prototype, and ignore the non-prototype declaration in
    the system header file. This, of course, will call the system library
    function with wrong arguments.
The compiler can't know how the function was defined, so it can't guess
what the Right Thing (tm) is in general. It might do this if the function
in question were in the same compilation unit, but it is not required to.

Two more comments:
  - if your manpage states that getpwuid has an int as the parameter, your
    prototype is simply wrong.
  - modern Unix (Posix) systems define a type "uid_t" as the parameter
    of getpwuid() and friends. If you attempt to provide prototypes for
    system library functions for some portable software distribution,
    use "uid_t" in your prototypes, and provide a proper definition of
    uid_t for any target machine that doesn't already know it.

Just in case you are confused by the use of "defined" and "declared"
above, they are ANSI terms. A definition defines the exact behaviour of a
function, i.e. the implementation:
int foobar(short bla)
{ dosomething(bla); }
A declaration declares how a function is called, i.e. both prototyped and
non-prototyped "interface definitions" for a function are declarations:
int foobar();
int foobar(short);
This meaning is consistently used in the standard for variables, too.


	Patrick


-- 
progress and die. this is just the way the world goes round.
a comment by patrick schaaf, saarbruecken, germany.
From: t2101fs@sun1.lrz-muenchen.de
Newsgroups: gnu.gcc.bug
Subject: Bug in g++ 2.3.3
Date: 25 Jan 1993 21:18:40 -0500
Organization: GNUs Not Usenet
Distribution: gnu

System i386 / SCO 3.2R2
gcc version 2.3.3

Compiling the following file results in an error message:
g++     xxx.cc   -o xxx
xxx.cc: In function `int  main ()':
xxx.cc:15: member `xxx' is private

But B :: xxx () isn't private ....

--- file xxx.cc ---
class A
{
    int xxx;
};

class B : A
{
public:
    void xxx ();
};

main ()
{
    B b;
    b . xxx ();
}
--- end of file xxx.cc ---
From: jmbrown@netcom.com (John M. Brown)
Newsgroups: gnu.gcc.bug
Subject: Compiler Err> virtual memory exhausted
Date: 25 Jan 1993 20:58:52 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Hi, I am new to the world of GCC, so please forgive my ignorance:

I am using GCC2.3.3 on 386BSD..

Trying to compile X11R5 (XFree86)

Get an error :

In file included from XStrKeysym.c:34:
ks_tables.h:982: virtual memory exhaused...

Any info on where I could go to chase to bugger down??


-- 
-------sig cut here-------
jmbrown@netcom.com                         HAL == IBM
jmbrown@diagsoft.com <SOON>                WNT == VMS  Hmmm Dave where did
Diagsoft, Inc.  Makers of QAPLUS                       the NT really come frm
(408) 438-8247
From: rms@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.gcc.bug
Subject: gcc 2.3.3's handling of setjmp like functions
Date: 22 Jan 1993 21:11:25 -0500
Organization: GNUs Not Usenet
Distribution: gnu

    However, considering the number of machines to which gcc has been
    ported and the likelihood of missing some functions, shouldn't there be a
    way to declare that a function is `setjmp-like'?  Possibly via a pragma
    so that it could be put into the appropriate header files?

It might be reasonable to have a way of doing this, but I don't
like the idea of using pragma for it.  (Or for anything.)
Any other ideas?
From: ksakai@mtl.t.u-tokyo.ac.JP
Newsgroups: gnu.gcc.bug
Subject: size_t problem
Date: 22 Jan 1993 21:44:24 -0500
Organization: GNUs Not Usenet
Distribution: gnu

 I have made gcc-2.3.3 successfully on RISC news (running newsos 4.1R)
with configured "--target=mips-sony-newsos4.1", then tried to make
libg++-2.3, but next error messages appeared.

----
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.
cc
In file included from ./std.h:26, from AllocRing.cc:22:
./../g++-include/string.h:28: declaration of `long int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `unsigned int  strlen (const c
har *)'
make[1]: *** [AllocRing.o] Error 1
make: *** [in-src] Error 1
----

 On the Omron Luna88k's gcc-2.3.3 (configured "--target=m88k-omron-luna
--with-gnu-ld"), same problem have occurred as this.

----
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
In file included from ./std.h:26, from AllocRing.cc:22:
./../g++-include/string.h:28: declaration of `long int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `unsigned int  strlen (const char *)'
make[1]: *** [AllocRing.o] Error 1
make: *** [in-src] Error 1
----

 In the libg++/g++include/string.h, written as this.

----
// NOTE: If you get a error message from g++ that this declaration
// conflicts with a <built-in> declaration of strlen(), that usually
// indicates that __SIZE_TYPE__ is incorrectly defined by gcc.
// Fix or add SIZE_TYPE in the appropriate file in gcc/config/*.h.
----

 So, I think, on both systems, size_t should be defined as "long int".

                                Kiyotaka Sakai(ksakai@mtl.t.u-tokyo.ac.jp)
From: kab@eecs.cs.pdx.edu (Ken Baker)
Newsgroups: gnu.gcc.help
Subject: gprof startfiles
Summary: startupfiles for gprof
Keywords: gprof crt0.0
Date: 27 Jan 93 05:37:47 GMT
Article-I.D.: pdxgate.6766

Dear NetNewsReaders,
	I am trying to get gprof working on the Motorola 88k with gcc
version 2.2.2. I am not the original person who installed the gcc
compiler but I have access to all of it's sources. I did retrieve
gprof from prep and compiled it ok. When I try to compile a program
with the -pg option I get an error saying the loader cannot find
gcrt0.o.
	I cannot find any references to how these startup files are built
and then where they reside so the linker can find them.

Please email me any enlightenment you may have on the subject!
Thanks!
Ken A. Baker
kab@cs.pdx.edu
Newsgroups: gnu.gcc.help
From: coei@prodhp.us.oracle.com (Chris Oei)
Subject: symbol __objc_class_name_Object undefined
Organization: Oracle Corp., Redwood Shores CA
Date: Thu, 28 Jan 1993 18:00:49 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.


When I try to use gcc-2.3.3 on AIX 3.2, I got the following:


amnesia> gcc -c m.m
Assembler:
/tmp/ccUOMDM2.s: line 175: 1252-023 The symbol __objc_class_name_Object is not d
efined.
/tmp/ccUOMDM2.s: line 175: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.

The file in question is

#include <stdio.h>
#include <Object.h>

@interface A : Object {
        int x;
}

- show;
@end

@implementation A : Object {
        int x;
}

-show
{
        printf("%d\n",x);
}

@end

I also got the same error using gcc-2.3.1 on SunOS 4.1

Anyone have any ideas what's wrong?

If anyone has gotten the objective-c part of gcc to work properly on either
machine, I'd be interested in hearing about it.  At least I'd know there
exists some way of getting it to work.

Help!

(please?)

Thanks,
Chris
coei@oracle.com
From: csc_ted@uhdvx3.dt.uh.edu (TED KOUBIAR)
Newsgroups: gnu.gcc.help
Subject: Installing gcc.2.3.3 on  mips-ultrix4.2   (Decstation 5000/25)
Date: 25 Jan 1993 15:48 CST
Organization: University of Houston-Downtown
Distribution: world
NNTP-Posting-Host: uhdvx3.dt.uh.edu
X-Lunar-Date: 0 days, 5 hours, 21 minutes since the new moon
News-Software: VAX/VMS VNEWS 1.41A   

Hello:

I am trying to install [ gcc ] on a DECstation 5000/25.   I ran configure
and the target is [ mips-ultrix4.2 ].  It creates the Makefile and when I 
run make it does a lot of work and during the installation i get an error
message.  The details are listed below:


please let me know if there is a solution.

thanks
---
Ted Koubiar

ted@dt.uh.edu

*******************************************************************************
>>>configure --target=mips-ultrix4.2

Linked `config.h' to `./config/xm-mips.h'
Linked `tm.h' to `./config/mips.h'
Linked `md' to `./config/mips.md'
Linked `aux-output.c' to `./config/mips.c'
Linked `tconfig.h' to `./config/xm-mips.h'
Linked `hconfig.h' to `./config/xm-mips.h'
Merged x-mips.
Merged t-mips.
Created `Makefile'.
Links are now set up for target mips-mips-ultrix4.2.

now running make..........


cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g     -I. -I. -I./config    
       -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/mips-ultrix4.2/`sed -e 
       's/.*\"\([^ \"]*\)[ \"].*/\1/' < ./version.c`/include\"    
       -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/g++-include\"    
       -DLOCAL_INCLUDE_DIR=\"/usr/local/include\"    -DCROSS_INCLUDE_DIR=\"
       /usr/local/lib/gcc-lib/mips-ultrix4.2/`sed -e 's/.*\"\([^ \"]*\)[ \"].*/\1/'
       < ./version.c`/sys-include\"    -DTOOLDIR=\"/usr/local/mips-ultrix4.2/\"
       -c `echo ./cccp.c | sed 's,^\./,,'`
cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g     -I. -I. -I./config -c 
	./cexp.c
cc -Wf,-XNg1500 -Olimit 3000 -O1 -c  -DIN_GCC   -g     -I. -I. -I./config 
	version.c
cc -Wf,-XNg1500 -Olimit 3000 -O1 -c  -DIN_GCC   -g     -I. -I. -I./config 
	obstack.c
cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g   -o cccp cccp.o cexp.o 
	version.o obstack.o ` case "cc -Wf,-XNg1500 -Olimit 3000 -O1" in "cc -Wf,
	-XNg1500 -Olimit 3000 -O1") echo  ;; esac `  -lmld
*** Error code 1
ld:
Can't locate file for: -lmld

stop

*******************************************************************************
From: rms@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.gcc.help
Subject: gcc for the mac?
Date: 23 Jan 1993 16:57:51 -0500
Organization: GNUs Not Usenet
Distribution: gnu

If Apple just drops its look and feel lawsuit and
says it won't do that again, that would certainly
be enough reason to drop the boycott (assuming they don't start
some new outrage that we don't foresee).
Newsgroups: gnu.gcc.help
From: ayre@fraser.sfu.ca (David Ayre)
Subject: Memory fault when making gcc
Keywords: help gcc genattr ncr
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 27 Jan 1993 02:24:02 GMT

When trying to make gcc-2.3.3 I get a memory falt when "genattr" is executed?

configure was set to "tower-32-sysv3"

Error message as follows:

	./genattr md > tmp-attr.h

sh:11651 Memory falt - core dump
*** Error code -117

Stop.

Any Idea's?

Thanks in advance!


Storm D. J. Petersen
~~~~~~~~~~~~~~~~~~~~
email: ayre@sfu.ca    attn: Storm P.

Newsgroups: gnu.gcc.help,comp.os.vms
From: rbp@netcom.com (Bob Pasker)
Subject: problem report of toupper() in GCC 1.42 on VMS
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 22 Jan 1993 17:12:57 GMT

GNU_CC_INCLUDE:[000000]ctype.h has the following utterly useless
definition of toupper():

	#define toupper(c)      ((c)-'a'+'A')

since there exists a properly functioning routine in the RTL, the
proper definition is:

	char toupper(char);

or, if you don't like the CALLS, roll yer own #define that makes
(toupper('A') == toupper('a')) be a true value.

tolower() is similarly brain dead.

-- 
-- 
-- bob pasker
-- rbp@netcom.com
--
Newsgroups: gnu.gcc.help
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: gcc for the mac?
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 21 Jan 1993 23:18:42 GMT

In article <C17L6C.CEI@javelin.sim.es.com> WPORTER@130.187.170.178 (WENDELL PORTER) writes:
>Does GCC exist for the Macintosh, and if so, where can I find it?

Uh oh... I can just hear FSF now... "Slowly I turned... Inch by inch, step by
step I crept..." But that's another humorous skit.

Unless you can find a way to get apple to 1) stop making software patents,
2) stop suing on the basis of look-and-feel and 3) make a commitment that
they won't ever do it again, there will be no ports of GCC to the Macintosh
supported by GCC's authors. Even if apple does all three above, there _still_
might not be an officially supported port.

To FSF: _Exactly_ what else will it take?

Newsgroups: gnu.gcc.help