HDTenEightyP/NetNews huggingface dataset:
From: scott@megadata.mega.oz.AU (Scott Humphreys)
Subject: Is "...", instead of ",..." legal ?
Keywords: variable arguments
Organization: Megadata P/L, North Ryde, Sydney, Aust.
Distribution: gnu
Date: Thu, 13 Aug 1992 02:27:51 GMT

In various books describing the expansion to ANSI-C,
one of the differences is described as the inclusion
of the ",..." operator for function prototypes
[ meaning that a variable number of arguments follow-
  e.g. int printf (const char *, ...);  ]

My question is: is this legal : int foo (...);

That is - can I legally declare a function 
with none or many arguments, or does it HAVE to have
at least one argument.

This came up because gcc version 2.2.2 let me do it,
but gave a warning when used with the -pedantic option.
Another tool I used (gnu GCT versxion 1.3) bombed on this construct.

Thanks for your time - I trust this isn't a FAQ...
[individually cross posted to comp.lang.c as well]
-- 
Dad to Jill (6), Hugh (3), Rhett (1), ? (find out in Dec).
email:  scott@megadata.mega.oz.au |        /\          _/_ _/_ 
fax:    (Int'l +61) (02) 887-4847 |       /  )  _. ____/   /   
voice:  (Int'l +61) (02) 805-0899 |      /__/__(__(_) (___<__  

Newsgroups: gnu.gcc.bug
From: cottons@monolith.mit.edu (Cotton Seed)
Subject: gcc 2.2.2 labeled element extension fails to parse in objective C code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 04:39:26 GMT

In article <9208040100.AA04267@slayer.MIT.EDU> mjhostet@slayer.mit.edu (Mathew J. Hostetter) writes:
] I am using gcc 2.2.2 on a 68040 NeXT running NeXTSTEP 3.0 pre-release  
] 1.
] 
] gcc fails to parse an array of labels that uses the "label element"  
] extension when you are in objective-c mode and there is more than one  
] label in the array.  Otherwise it seems to work.  Here's how I tested  
] the enclosed function:
] 
] slayer> gcc -c -x objective-c bad-label.c
] slayer> gcc -c -DLOSE bad-label.c 
] 
] slayer> gcc -c -DLOSE -x objective-c bad-label.c
] bad-label.c: In function `foo':
] bad-label.c:5: parse error before `]'
] 
] 
] Here is bad-label.c:
] 
] void
] foo ()
] {
] #ifdef LOSE
]   static const void *bar[] = { [5] &&label1, [10] &&label1 };
] #else
]   static const void *bar[] = { [5] &&label1 };  /* Only having one  
] elt works! */
] #endif
] 
]  label1:
]   return;
] }
] 
] -Mat

this bug was caused by an error in the objective C yacc grammer file
[objc-parse.y] which failed to include the "initlist, init label
element" construct [hence one label worked, while a list failed].
this is easily fixed by the following diff, which inserts the missing
construct into the grammer file....:

*** objc-parse.y        Sun Aug 16 23:25:15 1992
--- objc-parse.y.orig   Wed Mar 25 15:54:47 1992
***************
*** 878,885 ****
        /* These are for labeled elements.  */
        | '[' expr_no_commas ']' init
                { $$ = build_tree_list ($2, $4); }
-       | initlist ',' '[' expr_no_commas ']' init
-               { $$ = tree_cons ($4, $6, $1); }
        | initlist ',' CASE expr_no_commas ':' init
                { $$ = tree_cons ($4, $6, $1); }
        | identifier ':' init
--- 878,883 ----

and with the patch, the bad-label.c example compiles correctly...:

monolith[NeXT]# ./gcc -B./ -c -x objective-c bad-label.c
monolith[NeXT]# ./gcc -B./ -c -DLOSE -x objective-c bad-label.c
monolith[NeXT]# 

--Cotton Seed [cottons@monolith.mit.edu]
.

Newsgroups: gnu.gcc.bug
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Subject: Abnormal program termination due to erroneous program
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 18:40:57 GMT

The appended (erroneous) program causes cc1 of GCC 2.2.2 for 386 on
emx (under OS/2 2.0) to abort. Further simplification of the program
makes the problem disappear.

gcc -c bug.c
bug.c: In function `fun3':
bug.c.16: warning `return' with a value, in function returning void

Abnormal program termination
core dumped

------------------------------- cut here -------------------------------------
static int var1;

static int __inline__ fun1 (void)
{
  return 0;
}

static int fun2 (void)
{
  return (fun1 ());
}


static void fun3 (void)
{
  return (var1++);
}
------------------------------- cut here -------------------------------------

Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug
From: jrussell@watson.ibm.com (Jim Russell)
Subject: Extraneous warning w/ -ansi -pedantic
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 04:31:13 GMT

The following program:
    struct goo {
      int i;
    } a, b;

    main()
    {
      int x, y;

      y = ( x ? a : b ).i;
    }

when compiled with "gcc -ansi -pedantic" gets the following warning:
    goo.c: In function `main':
    goo.c:9: warning: ANSI C forbids use of conditional expressions as lvalues

However, ANSI does not requre that the first operand of the . operator be
an lvalue.  In fact, they even give an example (sec 3.3.2.3, pg 43 line 14)
where the first operand is not an lvalue (it's a function return in their
example).

We got this warning with gcc version 2.2 on the RS/6000, and gcc version
2.2.2 on the Sparc.

- Jim


Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2 diagnoses each initialized parameter twice
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 20:57:24 GMT

For the erroneous program

	int main(argc) int argc = 0; { return 0; }

GCC 2.2.2 outputs the same diagnostic twice:

	t.c:1: parameter `argc' is initialized
	t.c:1: parameter `argc' is initialized

Here is a patch.

Thu Aug 13 20:53:00 1992  Paul Eggert  (eggert@twinsun.com)

	* c-decl.c (grokdeclarator): Remove duplicate diagnostic for
	initialized parameters; start_decl already does this.

===================================================================
RCS file: c-decl.c,v
retrieving revision 2.2.2.3
diff -c -r2.2.2.3 c-decl.c
*** c-decl.c	1992/08/11 19:43:13	2.2.2.3
--- c-decl.c	1992/08/13 20:53:00
***************
*** 3950,3958 ****
  	    volatilep = constp = 0;
  	  }
  
- 	if (initialized)
- 	  error ("parameter `%s' is initialized", name);
- 
  	decl = build_decl (PARM_DECL, declarator, type);
  	if (size_varies)
  	  C_DECL_VARIABLE_SIZE (decl) = 1;
--- 3950,3955 ----

Newsgroups: gnu.gcc.bug
From: jonas@beppe.ericsson.SE (Jonas Nygren)
Subject: template, constructor call
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Distribution: gnu
Date: Mon, 17 Aug 1992 08:14:40 GMT

Having a class X

class X { public: class X(X&) {} };

and a template

template<class T> class Y {
	T *p;
public:
	void set(T &r) { p->T::T(r); }
};

the following wont work

Y<X> yx;
X x;

yx.set(x);

gcc will complain 'no function T in X'.

/jonas



Newsgroups: gnu.gcc.bug
From: 75030.631@compuserve.COM (Gail Slemon)
Subject: gcc optimization bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 16:34:14 GMT

To: >Internet:bug-gcc@prep.ai.mit.edu
Hi!
	Found an optimizer bug and isolated it using
the following code.  This was done on a Sun SPARC
using gcc-2.2.2 and libg++-2.1.  The code works
when compiling without the "O" or "O2" switches
but does not work with optimization.  It seems
that the non-virtual function, printa, is
treated as a virtual function and the program
does a core dump when a nil pointer tries to
invoke the function.
---------------------
#include <iostream.h>
#define nil 0

class temp {
public:
	int a;
	temp();
	virtual void testa (temp*);

	void printa(ostream& os);
};

temp::temp(){
	a=0;
}

void temp::testa(temp* tmp){
	cout << tmp->a;
	cout << "Survived test\n";
}

void temp::printa(ostream& os){
	os << "this is a test";

	if (this == nil) {
		os << "This is nil\n";
	}
	else
	{
		this -> testa(this);
		os << "This is not nil\n";
	}
}

main(){
	temp aa;
	temp* aptr = nil;

	aa.printa(cout);
	aptr->printa(cout);
}
-----------------------
Is there a way to be on your mailing list with
my compuserve address?

     Thanks again!!!
     Gail Slemon, Expersoft
     phone #s: (619) 546-4100
               (800) 755-7011




Newsgroups: gnu.gcc.bug
From: A.APPLEYARD@fs1.mt.umist.ac.UK
Subject: Gnu C++ bugs in classes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 09:57:00 GMT

BUG REPORT: In Gnu C version 2.0, static members of classes are not allocated
storage space, and thus the linker complains that these symbols are missing if
I use them.
This bug was not present in the last version of Gnu C which I had (1.39?).
Herewith a C++ program, and its translation into assembler by Gnu C++.
Notice that there is no assembler line 'comm __12mousecatcher$mice,4'.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
class mousecatcher{public:
int cat,ferret,owl,trap;
static int mice;};
int i,j,k; mousecatcher Tom;
main(){i=Tom.cat; j=Tom.ferret; k=Tom.mice;}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	.file	"t$$.cc"
gcc2_compiled.:
.text
	.align 2
.globl _main
_main:
	pushl %ebp
	movl %esp,%ebp
	call ___main
	movl _Tom,%edx
	movl %edx,_i
	movl _Tom+4,%edx
	movl %edx,_j
	movl __12mousecatcher$mice,%edx
	movl %edx,_k
	xorl %eax,%eax
	jmp L1
	.align 2,0x90
	jmp L1
	.align 2,0x90
L1:
	leave
	ret
.comm _i,4
.comm _j,4
.comm _k,4
.comm _Tom,16

Newsgroups: gnu.gcc.bug
From: jonas@beppe.ericsson.SE (Jonas Nygren)
Subject: constructor, destructor for fundamental type
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Distribution: gnu
Date: Mon, 17 Aug 1992 08:06:05 GMT

I tried the following in gcc-2.2.1:

	int *p;
	p->int::~int();

and the compiler complained. According to the ARM this construct is legal, page 280.

Neither did p->int::int(1) work which I assume it should in analogy with the destructor. It
is legal to write int i = int(1), so a constructor or othe construct must be available.

/jonas


Newsgroups: gnu.gcc.bug
From: TRANLE@intellicorp.com (Minh Tran-Le)
Subject: Re: Installing gcc-2.0 on AIX/PS/2
Reply-To: tranle@intellicorp.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 15 Aug 1992 23:46:57 GMT

|Date: Sat, 15 Aug 92 08:16:53 -0500
|From: james@bigtex.cactus.org (James Van Artsdalen)
|
|Did you ever get a fix for this problem?
|
|> Date: 8 Apr 92 13:00:32 GMT
|> From: koch@tmipi6.telematik.informatik.uni-karlsruhe.de (Gernot Koch)
|
|> The gcc-Compiler uses pseudo-ops, which the PS/2-Assembler doesn't know.
|> These are '.section .init' and '.section .fini'. Which changes in the 
|> source-code of gcc-2.0 are necessary to force the Compiler to omit these
|> pseudo-ops?
|> 
|> The AIX/PS/2-version is 1.2.1
|> 
|> Gernot Koch
|> koch@telematik.informatik.uni-karlsruhe.de
|---
|James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
|Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789
|

There is no easy and simple fix for that problem.  It require to use a 
modified version gas-1.92.3 that can generate COFF and understand .init
sections and a small patch for gcc-2.2.2 that I posted a new week ago.

I can mail the diff to gcc-2.2.2 to who ever wants it but as the gas-1.92.3
compress tar file is rather big (1.5MB) I can only ftp it to somewhere
so that people can grab it.

Minh Tran-Le.
-------

Newsgroups: gnu.gcc.bug
From: toddb@nvr.com (Todd Brunhoff)
Subject: core dump in cc1
Reply-To: toddb@nvr.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 12:23:54 GMT

I have a generated C file, containing only data.  But it is quite
large: 66375 lines, or 1139291 bytes.  The problem is that when
compiled with gcc, it core dumps a file that is 447271344 bytes
(yes, that's 400+ megabytes!) although it has holes in it and really
only occupies 45 megabytes.

I'm certain that this is not kosher behavior :-)

You can ftp a sanitized, able-to-be-compiled-all-on-its-own file
from ~ftp/tmp/gccbug.c at nvr.com (192.82.231.50)

This is gcc 2.2.2.  The compile line is gcc -c gccbug.c.  Thanks.
---------------
internet: toddb@nvr.com                                             c--Q Q
US:       Todd Brunhoff; North Valley Research;                         `
          15262 NW Greenbriar Pkwy; Beaverton, OR  97006                -
Phone:    (503) 531-5707
Fax:      (503) 690-2320

Newsgroups: gnu.gcc.bug
From: lopatin@inp.nsk.SU (LOPATIN)
Subject: Init of static members inside class def
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 19:34:00 GMT

	I admire how your gcc 2.1 works on my DECstation 5000/200 (Ultrix 4.2),
but it seems to be erroneous not to reject initialization of the static member
inside class definition. Let me illustrate it by example:

[ 191 > cat one.C
#include <iostream.h>

struct item {
    static int y = 1;
};

main(){
    item x;
    cout << x.y <<"\n";
}

[ 192 > cat two.C
struct item {
    static int y;
};

int item::y = 2;

[ 193 > g++ one.C two.C
[ 194 > a.out
2

	For those who only red the first edition of Stroustrup's book
it is not obvious that "one.C" is invalid,  so it is very suitable to
report error on this, like Borland C++ does.
  
	Sincerely yours, Sergei V.Lopatin.



Newsgroups: gnu.gcc.bug
From: fletch@vnet.ibm.com (Andrew L. Gross)
Subject: Template problem with gcc 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 00:57:49 GMT

I am having a problem with templates on gcc 2.2.2.  One of the problem
arises when I have a "const" method inside my template.  Removing the
"const" gets rid of the problem.

Another problem occurs when I use "static" member functions.  This problem
will also go away when the "static" is removed, but this changes the
entire program.

The error that comes up for both is
[filename]: template for methode `[method name]' doesn't match any in class
    `[Template Name]<[Instance Name]>'

Lastly, I got a
: method `__opP *13' not found in class `Template<XXX>'

Any ideas?

                                   Andy

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

Andrew L. Gross                             ADSTAR
Internet: fletch@vnet.ibm.com               63S/071-2
Phone: (602) 799-3459                       9000 S. Rita Road
Tie Line:    321-3459                       Tucson, AZ  85744

Newsgroups: gnu.gcc.bug
From: lauten@feynman.t30.physik.tu-muenchen.de (Markus Lautenbacher)
Subject: gcc code dumpes core, other compilers do not
Reply-To: lauten@feynman.t30.physik.tu-muenchen.de
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 11:57:32 GMT

Dear Sir,

whether this really is a bug report or not I am not a computer expert
enough to decide. So let me just bring the following to your attention.

I am writing right now a C program to get some theoretical predictions
for an experimentally measured quantity in particle physics.
Numerically this basically means to solve for the eigensystem of real,
non-symmetric matrices. Compiling my C-sources (basically K&R I style)
with various compilers, in particular GNU gcc, I have run into the
following problem:

--------------------------------------------------------
  Compiler  |                    Flags 
            |  default  |    -g    |    -O    |    -g-O
--------------------------------------------------------
Turbo-C 1.0 |     OK    |          |          |
    cc      |           |    OK    |    OK    |
  gcc-1.40  |           |    OK    |    OK    |
  gcc-2.1   |           |    OK    |    CD    |    CD
  gcc-2.2.2 |           |    CD    |    CD    |    CD

where OK means "compiles and links fine, runs and produces sensible
data" and CD means "compiles and links fine, but dumps core".
The workstation I am using is a Sun SPRCstation 1+ running SunOS 4.1.2.
The PC with the Turbo-C is a standard AT 286/7 clone under DOS 3.3.

I have found out that the problem is in a routine I have copied from
the program-listing disk of the wellknown "Numerical Recipes" book. So
it seems unlikely that I have made a programming error that now causes
the core dump. Strange enough the problem has come about with the
major release change 1.* -> 2.* and there first only in optimized code,
but now with the latest gcc in any kind of code.

Do you want me to send you my sources (in *.tar.Z form) to have a look
at the problem ? If you're interested let me know (please not that you
probably won't be able to reach me from 22/8/92 until 22/9/92 since I
am abroad for a research visit during that period).


Best regards,
             MARKUS

-----
MARKUS E. LAUTENBACHER,
Technical University Munich,    | phone:    +49/89/3209-2398
Physics Dept.-Theo. Physics T31,| Internet:
D-8046 Garching, FRG.           | lauten@feynman.t30.physik.tu-muenchen.de

Newsgroups: gnu.gcc.bug
From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: gcc dumps in asm
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Distribution: gnu
Date: Fri, 21 Aug 1992 21:04:39 GMT

gcc 2.2.2 on a sun4 (sparc) running SunOS 4.1.1 dump
core trying to compile this:

main()
{
    int comp ; 
    __asm__("mov %0, %i0;ret;restore %0, 0, %%i1"::"r" (comp));
}

I know there's a bug (can't use %0 twice), but is it really
necessary to dump core?
-- 
/Tommy Thorn, another LPF member. Terminate software patents.
Join The League for Programming Freedom, mail league@prep.ai.mit.edu.
XT350 '88 - You either make dust, or you eat it.

Newsgroups: gnu.gcc.bug
From: amos@sol.acs.unt.edu (Amos A. Gouaux)
Subject: gcc-2.2.2 and extended class scope operator
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 16:16:13 GMT

i'm sending an uudecoded file called bug.tar.Z.  it includes a Makefile with
the targets good, bad, and clean.  the sources contained demonstrate what
i believe is a bug.  when i have a non-template class nested inside of a
template class, it seems that i cannot use the extended class scope operator
to define methods for that nested class.  could someone take a peek and
see if i'm doing something silly?

amos


-- 
amos@unt.edu                   Amos A. Gouaux                   (817) 565-4161
-= Academic Computing Services, University of North Texas, Denton, TX, USA. =-

Newsgroups: gnu.gcc.bug
From: gsk@carrara.bos.marble.com (Geoffrey S. Knauth)
Subject: GCC 2.2.2, tiny spelling mistake
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 17:33:26 GMT

[file INSTALL, line 122]

    `--with-gnu-as'
          On certain systems, you must specify whether you want GNU CC
          to work with the usual compilation tools or with the GNU
          compilation tools (including GAS).  Use the `--with-gnu-as'
          argument when you run `configure', if you want to use the GNU
          tools.  (Specify `--with-gnu-ld' as well, since on these
          systems GAS works only with the GNU linker.)  The systems
-->       were this makes a difference are `i386-ANYTHING-sysv',
	  ^^
	  where

Newsgroups: gnu.gcc.bug
From: gregor@kafka.saic.com (gregg hanna)
Subject: g++ and groff's c++test.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 07:03:17 GMT

Hi,

  I was trying to build groff but it didn't pass the c++
compiler test in c++test.c, which is:

#include <stdio.h>

struct A {
  A() { fputs("A\n", stdout); }
  ~A() { fputs("~A\n", stdout); }
};

A a;

main()
{
  return 0;
}


I thought maybe the optimizer trashed it, but I tried it
several different ways.  It appears that g++ does not call
the creator for statically declared variables.  Is this
correct behavior?  The following, however, works fine:

#include <stdio.h>

struct A {
  A() { fputs("A\n", stdout); }
  ~A() { fputs("~A\n", stdout); }
};

main()
{
  A a;
  return 0;
}


If this is not a bug, perhaps the groff people should
be notified, since groff-1.05 currently will not compile
if it fails the c++test.  By the way, the groff people
expect the output of the program to be:
A
~A

                                            gregg hanna
                                            gregor@kafka.saic.com

Newsgroups: gnu.gcc.bug
From: scs@iti.org (Steve Simmons)
Subject: i960 gcc and "static" memory initialization
Reply-To: jak@aisinc.com (Jeff Kraudelt)
Organization: Industrial Technology Institute
Distribution: gnu
Date: Wed, 19 Aug 1992 15:22:56 GMT

We are having an interesting problem with the i960 gcc compiler/linker,
version 1.37 of gcc, Intels release 2.0.

When there are variables declared in the form:

int i = 4 ;

main()
{
	printf( "Value of i is %d\n", i ) ;
	i = 5 ;
}

we have some problems when debugging.  On the first debug pass thru
the program, everything is fine.  If we rerun the program without
refreshing the core image (ie, re-downloading), the initial value
of i is 5.

This is correct performance (or rather, allowed performance) under
ANSI C.  Nonetheless it makes debugging hell.  We'd rather not have
to rewrite the code to dynamically initialize all the variables.  Is
there a set of switches or mod package that will handle this?

Please reply to jak@aisinc.com (Jeff Kraudelt).  He has email access
but not news access.
-- 
"If life were fair, the acquisition of a large bosom or a massive inheritance
 would have no bearing on your ability to attract the opposite sex, and Dan
 Quayle would be making a living asking runny-nosed children, `Do you want
 fries with that?'"     -- John Cleese, "Corporate Computing" magazine

Newsgroups: gnu.gcc.bug
From: scott@megadata.mega.oz.AU (Scott Humphreys)
Newsgroups: gnu.gcc.bug
Subject: Is "...", instead of ",..." legal ?
Date: 13 Aug 92 20:46:43 GMT
Distribution: gnu
Organization: GNUs Not Usenet

In various books describing the expansion to ANSI-C,
one of the differences is described as the inclusion
of the ",..." operator for function prototypes
[ meaning that a variable number of arguments follow-
  e.g. int printf (const char *, ...);  ]

My question is: is this legal : int foo (...);

That is - can I legally declare a function 
with none or many arguments, or does it HAVE to have
at least one argument.

This came up because gcc version 2.2.2 let me do it,
but gave a warning when used with the -pedantic option.
Another tool I used (gnu GCT version 1.3) bombed on this construct.

Thanks for your time - I trust this isn't a FAQ...
[individually cross posted to comp.lang.c as well]

			Regards, Scott
Newsgroups: gnu.gcc.bug