HDTenEightyP/NetNews huggingface dataset:
From: drg@candidus.ma30.bull.com (Daniel R. Guilderson)
Newsgroups: gnu.gcc.bug
Subject: Minor Problem building GCC 2.3.3 on SCO systems
Date: 26 Jan 1993 22:14:28 -0500
Organization: GNUs Not Usenet
Distribution: gnu

I just recently retrieved the gcc-2.3.2-2.3.3 patch.  In case you have
forgotten I am the guy who had some problems building gcc-2.3.2 on SCO
UNIX 3.2v4.  The new patch is great.  I have only one minor problem to
report.  The default CFLAGS for the bootstrap compile contains a '-g'
to enable debugging.  This caused the Microsoft C compiler to become
confused.  It somehow thought it was compiling Xenix code and
apparently tried to convert OMF files.  Here is an example of the
output.

cc -nointl  -DIN_GCC -D__STDC__=0  -g     -I. -I. -I./config -c ./cexp.c
./cexp.c
/usr/bin/.cvtomf: fatal error -- No input file specified

I solved the problem by redefining CFLAGS so that the '-g' flag was
turned off during the bootstrap.

Thanks.

Daniel R. Guilderson                 Zenith Data Systems / Bull
508-294-6612                         300 Concord Road    MS 853A
drg@candidus.ma30.bull.com           Billerica, MA 01821

semper liberi
From: aas@rosmer.nr.no (Gisle Aas)
Newsgroups: gnu.gcc.bug
Subject: CPP expands macro parameters with newlines wrong
Date: 22 Jan 1993 21:13:23 -0500
Organization: Norwegian Computing Centre, Oslo, Norway
Distribution: gnu
Reply-To: Gisle.Aas@nr.no

------------------------------------
#define macro(a) a a a
macro(foo
bar)
------------------------------------
becomes when run though gcc -E:

foo
bar foobar foobar 

--
Gisle Aas               |  snail: Boks 114 Blindern, N-0314 Oslo, Norway
Norsk Regnesentral      |  X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no
voice: +47-2-453561     |  inet:  Gisle.Aas@nr.no
From: pls@spotlight.ATt.COM
Newsgroups: gnu.gcc.bug
Subject: gcc -pic
Date: 25 Jan 1993 20:29:31 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Is there a version of gcc that supports the -pic (position independent
code) option for the sparc?  I need to use gcc (for the ansi definitions)
to build a sparc shared library.  I currently have Version 1.39.

Please respond through pls@pixels.att.com, since my current return path
does not work.

	Thank you,
	Pete Segal
	Spotlight Graphics
	(908) 530-8484
From: cote@iro.umontreal.CA (Marcel Cote)
Newsgroups: gnu.gcc.bug
Subject: BUG
Date: 22 Jan 1993 21:08:05 -0500
Organization: GNUs Not Usenet
Distribution: gnu

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. 


struct S1 {
   char *s;
   int i;
   struct S1 *s1p;
};

main()
{
   static struct S1 a[] = {
      { "abcd", 1, a+1 },
      { "efgh", 2, a+2 },
      { "ijkl", 3, a }
   };
   
   printf("%c\n",++a[0].s[3]);
}
From: jason@jarthur.claremont.edu (Jason Merrill)
Newsgroups: gnu.gcc.bug
Subject: Prototype handling bug(?) in 2.3.3
Date: 21 Jan 1993 18:06:39 -0500
Organization: Minimal
Distribution: gnu

When compiling ckufio.c from the C-Kermit 5A(188) distribution, I get this
error:

ckufio.c:390: conflicting types for `getpwuid'
ckufio.c:390: An argument type that has a default promotion
ckufio.c:390: can't match an empty parameter name list declaration.
/usr/include/pwd.h:27: previous declaration of `getpwuid'

A condensation of the file being compiled would be:

-----
typedef unsigned short uid_t;

struct passwd* getpwuid();
struct passwd* getpwuid(uid_t);
-----

And indeed that fragment reproduces the bug (misfeature)?  I was under the
impression that you could pass anything you darn well pleased through ().
I suppose the error means that the compiler would have to convert the
argument being passed to unsigned short before passing it, but this machine
is little-endian, so passing an int straight through wouldn't hurt.

Perhaps this is proper behavior; what do you think?

--
Jason Merrill					jason@jarthur.claremont.edu
From: rolandp@sv.gpsemi.COM (Paul Roland)
Newsgroups: gnu.gcc.bug
Subject: GCC novice user problem...
Date: 21 Jan 1993 18:20:17 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Hello,
	Sorry for the novice question...

	We've just put GCC 014 up on our VAX and the install appears to have
gone fine.  We can invoke GCC and begin a compile, however all the #include
statements produce errors indicating files not present:

		(c-file) :54: descrip: no such file or directory

	The GNU_CC_INCLUDE logical is set up in standard fashion (to the
GCC [.INCLUDE.] tree) and the files DO exist.

	What am I doing wrong?

						Thanks,
						Paul Roland
						GEC Plessey Semics.
From: ian@cygnus.com (Ian Lance Taylor)
Newsgroups: gnu.gcc.bug
Subject: Minor Problem building GCC 2.3.3 on SCO systems
Date: 26 Jan 1993 22:18:13 -0500
Organization: GNUs Not Usenet
Distribution: gnu

   Date: Tue, 26 Jan 93 13:25:28 -0500
   From: drg@candidus.ma30.bull.com (Daniel R. Guilderson)

   I just recently retrieved the gcc-2.3.2-2.3.3 patch.  In case you have
   forgotten I am the guy who had some problems building gcc-2.3.2 on SCO
   UNIX 3.2v4.  The new patch is great.  I have only one minor problem to
   report.  The default CFLAGS for the bootstrap compile contains a '-g'
   to enable debugging.  This caused the Microsoft C compiler to become
   confused.  It somehow thought it was compiling Xenix code and
   apparently tried to convert OMF files.  Here is an example of the
   output.

   cc -nointl  -DIN_GCC -D__STDC__=0  -g     -I. -I. -I./config -c ./cexp.c
   ./cexp.c
   /usr/bin/.cvtomf: fatal error -- No input file specified

   I solved the problem by redefining CFLAGS so that the '-g' flag was
   turned off during the bootstrap.

I don't understand why this happened.  I just tried it again, and it
didn't happen to me.  I don't even have a program /usr/bin/.cvtomf.
Does this mean that you can never run ``cc -g''?  That seems peculiar.

Ian Taylor
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Newsgroups: gnu.gcc.bug
Subject: Infinite loop in cc1plus caused by simple code.
Date: 25 Jan 1993 21:11:16 -0500
Organization: GNUs Not Usenet
Distribution: gnu

On a SUN4, SunOS 4.1.1, gcc 2.3.3 (built with 2.3.1) libg++ 2.3, & SUN
libc.so.1.6.1 


#include<iostream.h>
#include<String.h>

// A very simple class consisiting of a String, int pair

class Collection
{
	String name;
	int id_number;
public:
	Collection(String& s, int p):name(s),id_number(p){}

	// constructor does nothing exciting

	operator String(){return name;}

	// conversion operator similarly dull

	ostream& print(ostream& a)
		{
			a<<"name: "<<name<<"\n"
				<<"id_number: "<<id_number<<"\n";
			return a;
		}

	// output

	String& GetName()
		{
			return name;
		}
	// .. and access
};

// a trivial example function ... but could just as well have been
// a class member function for this problem

void DoSomething(String& s)
{
	cout<<"ya boo sucks: "<<s<<"\n";
}

int main()
{
	Collection guanaco("llama", 42);

//	DoSomething(guanaco.GetName());		// This works fine

	DoSomething(guanaco);			// Compiler never exits...

	guanaco.print(cout)<<"\n";

	return 0;
}

/*

----------------------------------------------------- 


Above is an example of code that compiles without error on the
departmental compiler and causes 2.3.3 to hang.

NB 2.3.3 copes if the commented DoSomething() invocation is used
instead.

I think there may be some other bugs in the error recovery department
i.e. a parse error gets reported sometimes and the compiler hangs. But
I will try to provide a separate example of this.



D.Critchley
-------------------------------------------------------------

*/


Runs with output:

porridge:gjoly/c++/2.x[76] a.out
ya boo sucks: llama
name: llama
id_number: 42

porridge:gjoly/c++/2.x[77]


Snapshot with "error"

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
 9845 gjoly     82    0 32424K 14256K run     1:17 74.04% 73.83% cc1plus

Gordon.


Gordon Joly      Phone  +44 71 387 7050 ext 3703      FAX  +44 71 387 1397
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT
From: adda@acri.FR (Serge Adda)
Newsgroups: gnu.gcc.bug
Subject: My fix for my previous bug report
Date: 22 Jan 1993 21:44:31 -0500
Organization: Advanced Computer Research Institute
Distribution: gnu

Thu Jan 21 18:12:49 1993  Serge Adda  (adda@soft01)

    * expmed.c (emit_store_flag): get the new value of icode
    using the returned comparison.

*** expmed.c.old	Thu Jan 21 18:06:45 1993
--- expmed.c	Thu Jan 21 18:08:37 1993
***************
*** 2755,2761 ****
  	      && (STORE_FLAG_VALUE 
  		  == (HOST_WIDE_INT) 1 << (GET_MODE_BITSIZE (mode) - 1)))))
      {
!       rtx subtarget = target;
  
        /* If the result is to be wider than OP0, it is best to convert it
  	 first.  If it is to be narrower, it is *incorrect* to convert it
--- 2755,2761 ----
  	      && (STORE_FLAG_VALUE 
  		  == (HOST_WIDE_INT) 1 << (GET_MODE_BITSIZE (mode) - 1)))))
      {
!       subtarget = target;
  
        /* If the result is to be wider than OP0, it is best to convert it
  	 first.  If it is to be narrower, it is *incorrect* to convert it
***************
*** 2805,2810 ****
--- 2805,2814 ----
  		: normalizep == 1 ? const1_rtx
  		: normalizep == -1 ? constm1_rtx
  		: const_true_rtx);
+ 
+       /* Comparison opernads could have been swapped;
+ 	 so get the new comprison code.  */
+       icode = setcc_gen_code[(int) GET_CODE (comparison)];
  
        /* Get a reference to the target in the proper mode for this insn.  */
        compare_mode = insn_operand_mode[(int) icode][0];

Serge Adda - A.C.R.I. Compiler Team
email: adda@acri.fr
From: laegner@platon.emi.GReco-prog.FR (LARS LAEGNER)
Newsgroups: gnu.gcc.bug
Subject: Bug
Date: 26 Jan 1993 21:43:55 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Try to compile the hsearch()-Funktion with gcc.
every time segmentation-fault()
but won with cc and g++
file: standard-exemple of hsearch-funktion is enough
system: sparc-sun-stations
version: gcc 1.39
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Newsgroups: gnu.gcc.bug
Subject: Internal error in cc1plus (signal 4) - simple string class example.
Date: 25 Jan 1993 21:14:15 -0500
Organization: GNUs Not Usenet
Distribution: gnu

On a SUN4, SunOS 4.1.1, gcc 2.3.3 (built with 2.3.1) libg++ 2.3, & SUN
libc.so.1.6.1 


#include<iostream.h>
#include<String.h>

// A very simple class consisiting of a String, int pair

class Collection
{
	String name;
	int id_number;
public:
	Collection(String& s, int p):name(s),id_number(p){}

	// constructor does nothing exciting

	operator String(){return name;}

	// conversion operator similarly dull

	ostream& print(ostream& a)
		{
			a<<"name: "<<name<<"\n"
				<<"id_number: "<<id_number<<"\n";
			return a;
		}

	// output

	String& GetName()
		{
			return name;
		}
	// .. and access
};

// a trivial example function ... but could just as well have been
// a class member function for this problem

void DoSomething(String& s)
{
	cout<<"ya boo sucks: "<<s<<"\n";
}

int main()
{
	Collection guanaco("llama", 42);

//	DoSomething(guanaco.GetName());		// This works fine

	DoSomething(guanaco);			// Compiler never exits...

	guanaco.print(cout)<<"\n";

	return 0;
}

/*

----------------------------------------------------- 


Above is an example of code that compiles without error on the
departmental compiler and causes 2.3.3 to hang.

NB 2.3.3 copes if the commented DoSomething() invocation is used
instead.

I think there may be some other bugs in the error recovery department
i.e. a parse error gets reported sometimes and the compiler hangs. But
I will try to provide a separate example of this.



D.Critchley
-------------------------------------------------------------

*/


Runs with output:

porridge:gjoly/c++/2.x[76] a.out
ya boo sucks: llama
name: llama
id_number: 42

porridge:gjoly/c++/2.x[77]


Snapshot with "error"

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
 9845 gjoly     82    0 32424K 14256K run     1:17 74.04% 73.83% cc1plus


Followed by

porridge:gjoly/c++/2.x[79]
/cs/research/coside/local/croissant/bin/gcc: Internal compiler
error: program cc1plus got fatal signal 4

porridge:gjoly/c++/2.x[79]
porridge:gjoly/c++/2.x[79]


Gordon.


Gordon Joly      Phone  +44 71 387 7050 ext 3703      FAX  +44 71 387 1397
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT
From: fn@trinity.do.open.DE (Frank Nobis)
Newsgroups: gnu.gcc.bug
Subject: Possible bug in gcc 2.3.3 on 386BSD
Date: 21 Jan 1993 18:07:47 -0500
Organization: GNUs Not Usenet
Distribution: gnu

I think I have discovered a bug in gcc 2.3.3.

I am running 386BSD without a 80387.

The old gcc 1.39 produce correct values.


Script started on Wed Jan 20 23:55:44 1993
ttyp2 </tmp> 1 > gcc -v a.c
Reading specs from /usr/local/lib/gcc-lib/i386-bsd/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/i386-bsd/2.3.3/cpp -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386 -D____386BSD____ -D__386BSD__ -DBSD_NET2 -D__unix__ -D__i386__ -D____386BSD____ -D__386BSD__ -D__BSD_NET2__ -D__unix -D__i386 -D____386BSD____ -D__386BSD__ -D__BSD_NET2 a.c /var/tmp/cc004497.i
GNU CPP version 2.3.3 (80386, BSD syntax)
 /usr/local/lib/gcc-lib/i386-bsd/2.3.3/cc1 /var/tmp/cc004497.i -quiet -dumpbase a.c -version -o /var/tmp/cc004497.s
GNU C version 2.3.3 (80386, BSD syntax) compiled by GNU C version 2.3.3.
 as -o /var/tmp/cc0044971.o /var/tmp/cc004497.s
 /usr/local/lib/gcc-lib/i386-bsd/2.3.3/ld /usr/lib/crt0.o -L/usr/local/lib/gcc-lib/i386-bsd/2.3.3 -L/usr/local/lib /var/tmp/cc0044971.o -lgcc -lc -lgcc
ttyp2 </tmp> 2 > a.out
-2147483648
8
8.000000
ttyp2 </tmp> 3 > cat a.c

#include <stdio.h>
#include <math.h>

int main()
{
  double	a = 7.6;

  printf ("%d\n", (int) 7.6);
  printf ("%d\n", (int) a);
  printf ("%f\n", a);

  return (0);
}
ttyp2 </tmp> 4 > exit

Script done on Wed Jan 20 23:56:55 1993


regards
       Frank
--
 fn@trinity.do.open.de   WARNUNG: Kinder! Es kann gefaehrlich sein, mit dem
 +49 231 103640 Voice    Weltuntergang zu spielen. Ihr solltet ihn besser nicht
 4600 Dortmund 1,        im eigenen Heim heraufbeschwoeren.
 Grosse Heimstr. 50      (Terry Pratchett, Ein gutes Omen)
From: ross@cs.wisc.edu (Ross Johnson)
Newsgroups: gnu.gcc.bug
Subject: optimizer bug
Date: 25 Jan 1993 20:10:29 -0500
Organization: GNUs Not Usenet
Distribution: gnu

/* This program illustrates a bug in the gcc optimizer, version 2.3.3
 * on a DECstation 3100.  Normal execution should return without printing
 * anything and this is the result when compiled without optimization.
 * However, when the -O2 flag is used, this program prints the error message.
 *
 * Ross Johnson (ross@cs.wisc.edu)
 */

void
Init(int *var)
{
  *var = 0;
}

void
main()
{
  int stuff, count, x = 0;
  char word[] = "c";

  Init(&stuff);
  word[count = 0] = (stuff == 0 ? (x=1, 'a') : (x=2, 'b'));
  /* if compared with 'c', the optimized program returns without ERROR */
  if (word[count] == 'a')
    return;
  printf("ERROR: prefix `%s' %d\n", word, x);
}
From: hogend@nlr.NL (hogendoorn r.a.)
Newsgroups: gnu.gcc.bug
Subject: gcc 2.3.3 bug or feature ?
Date: 21 Jan 1993 18:13:31 -0500
Organization: GNUs Not Usenet
Distribution: gnu

The problem concerns the inlining of 'friend' functions declared inside 
class scope. 
If optimization is turned off, no inlining takes place. The generated
procedures, however, are 'static' so they cannot be referenced outside
file scope. At least, this was the situation with gcc 2.2.2.
With gcc 2.3.3, this no longer holds true for 'friend' functions,
declared inside class scope. These generate procedures that are globally
visible and generate, for instance, 'ld' and 'ar' warnings "ignoring second
definition of <bwurp> in archive" if the class declaration is used in
more than one source file.
Obviously, the problem disappears if optimization is turned on, but it also
disappears if the 'friend' function is explicitly qualified 'inline'.
According to ARM, the qualification is not needed.

The compiler is gcc 2.3.3 [MM 33] installed with mips-sysv on a MIPS
running RISCos4.0.

A simple example:

class X {
	int xvalue;
public:
	X () : xvalue (0) {};
	X (const int i) : xvalue (i) {};

	int value () const {return xvalue;};

	X operator * (const int i) const {return X (xvalue * i);};

// and this one causes the trouble

	friend X operator * (const int i, const X x) {return x * i;};
};

regards, Rene Hogendoorn
From: h.b.furuseth@usit.uio.NO (Hallvard B Furuseth)
Newsgroups: gnu.gcc.bug
Subject: Re: gcc 2.3.3's handling of setjmp like functions
Date: 26 Jan 1993 22:24:26 -0500
Organization: University of Oslo, Norway
Distribution: gnu

In article <9301220819.AA21461@mole.gnu.ai.mit.edu> rms@gnu.ai.mit.edu (Richard Stallman) writes:

> 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?

Isn't that what __attribute__ is intended for?
Add __attribute__((setjmp)).

Another way:  Register or auto.
    register int setjmp (jmp_buf);
    register volatile void longjmp (jmp_buf, int);


However, one problem with such extensions is that they fill our header
files with '#if __GNUC__ &&!__STRICT_ANSI__' directives.  So the best
*syntax* may be something like
	int setjmp (jmp_buf) /*ATTRIBUTE:(SETJMP)*/;
which cpp would modify to __attribute__((setjmp)), just as cpp -lint.
--

Hallvard
From: martin@cs.unc.edu (Kevin Martin)
Newsgroups: gnu.gcc.bug
Subject: unterminated character constant
Date: 26 Jan 1993 22:04:58 -0500
Organization: The University of North Carolina at Chapel Hill
Distribution: gnu

Compiling the following code segment (no compiler options):

	#if 0
	   This is a test of an if
	   This line isn't going to work
	   But this line will, as will the first line
	#endif

with GCC 2.3.3 under Linux 0.99pl3 (i486), SunOs 4.1.1 (Sparc), and
Ultrix 4.2 (DEC 5000) yields an the error:

	a.c:3: unterminated character constant

The problem is the single quote.  It also happens if you use an #ifdef,
but doesn't happen if you put the text inside a comment.

Kevin
___
Kevin E. Martin               University of North Carolina at Chapel Hill
martin@cs.unc.edu                          Department of Computer Science
From: MTROY@optics.ps.uci.edu (Mitchell Troy, (714) 856-8280)
Newsgroups: gnu.gcc.bug
Subject: GCC and libraries
Date: 22 Jan 1993 21:45:03 -0500
Organization: GNUs Not Usenet
Distribution: gnu

I am not sure if this is the correct place to post this or not.  We are
using gcc Version 2.3.2 on a SUN 330.  We are trying to create a library out
of a group of c porgrams.  In the past we have used the following makefile,
however, it usses cc to compile the programs.  How do we make it use gcc or
is there a different type of makefile we should be using?

CFLAGS = -g

nrlib.a: nrlib.a(	nrutil.o	)
	ar rv $@ $?
	ranlib $@

nrlib.a(%.o): %.o
	@true

Here ntutil.c is the routine and nrlib.a is the library

					Thanks,
					Mitchell Troy
					(714) 476-0800
From: corrigan@weber.ucsd.edu (Michael J. Corrigan)
Newsgroups: gnu.gcc.bug
Subject: libg++-2.3/gcc-2.3.3.u3 core dump on 7xx and 8x7
Date: 22 Jan 1993 21:15:37 -0500
Organization: University of California, San Diego
Distribution: gnu

This example (excerpted from Stroustrup, 2nd edn p.88 ) creates a 20 MB
core dump on hppa1.1 systems ( 7xx and 8x7).
libg++-2.3 is built using gcc-2.3.3.u3 from Utah sand the most recent patches
posted for building libg++-2.3 on the hp700.

--------------CUT---------------------
#include <strstream.h>
int main(int argc,char *argv[]) {
	cin = *new istrstream(argv[1],strlen(argv[1]));
}
--------------CUT---------------------
The compile will complete successfully if the cast is made:

	cin = (istream) *new istrstream(argv[1],strlen(argv[1]));

(P.S. make CFLAGS="-O" LANGUAGES="c" to make the gcc stage1 compiler doesn't
work on the 8x7 as the time to compile c-decl.c is inordinate, although
it apparently does work on the 7xx ==> bug in -O on the 8x7 )

Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D_HPUX_SOURCE -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D___HPUX_SOURCE__ -D__hppa -D__hp9000s800 -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -D___HPUX_SOURCE -D__hp9000s700 -D_PA_RISC1_1 -D__hp9000s700 -D_PA_RISC1_1 bug.cc /tmp/cca19829.i
GNU CPP version 2.3.3 (hppa)
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/cc1plus /tmp/cca19829.i -quiet -dumpbase bug.cc -version -o /tmp/cca19829.s
GNU C++ version 2.3.3 (hppa) compiled by GNU C version 2.3.3.
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/as -o bug.o /tmp/cca19829.s
From: jason@jarthur.claremont.edu (Jason Merrill)
Newsgroups: gnu.gcc.bug
Subject: Re: Prototype handling bug(?) in 2.3.3
Date: 25 Jan 1993 20:44:23 -0500
Organization: GNUs Not Usenet
Distribution: gnu

>>>>> bof@midget.saar.de (Patrick Schaaf) writes:

> In gnu.gcc.bug you write:
>>And indeed that fragment reproduces the bug (misfeature)?  I was under the
>>impression that you could pass anything you darn well pleased through ().

> No, you can't. Assume the following code:

> short a, b;

> void foobar();

> foobar(a,b); /*1*/

> void foobar(short bla, short fasel);

> foobar(a,b); /*2*/

> In the first call to foobar, the shorts will be promoted to int by the
> default promotion rules (the same way floats are converted to doubles),
> thus (on a machine with 2 byte shorts and 4 byte ints) 8 bytes are passed
> to foobar.
> The second call, with the prototype in scope, will not apply default
> promotion rules, and thus passes only the 4 bytes for the 2 shorts.

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.


> You can't write function foobar to correctly accept both types of call.
> IMHO, the compiler is a good one if it warns you about this possible pitfall.

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.

Hmm...I just looked at the getpwuid man page, and evidently it takes an int
parameter.  I guess the compiler does know best...but I still think it
should be a warning, not an error.

Jason