HDTenEightyP/NetNews huggingface dataset:
From: oliva@dcc.unicamp.br (Alexandre Oliva)
Subject: Bug (?) in gcc-2.2.2's preprocessor
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 02:09:38 GMT

I am using gcc 2.2.2 in a SPARC Station running SunOS 4.1.1, writing a
program which needs some ioctl commands for magnetic tape control.

When I use the system's C compiler, the program works. When I use gcc,
or even g++ (I began writing it in C++), it does not work any more.

I found the reason. The constant MTIOCGET, which is defined in a
system include file, is understood differently by gcc's cpp and Sun's
cpp.

in /usr/include/sys/mtio.h, there is this line:

#define	MTIOCGET	_IOR(m, 2, struct mtget)	/* get tape status */

and in /usr/include/sys/ioccom.h, there is this line:

#define	_IOR(x,y,t)	(_IOC_OUT|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)

I noticed that Sun's cpp changes the 'x' to 'm', but gcc's does not.
Which one is correct?  What can I do to fix the problem, so that I can
be sure my program can by compiled in other Unix systems?

Thanks in advance.

Alexandre Oliva
oliva@dcc.unicamp.br
Depto de Ciencia da Computacao
DCC - IMECC - UNICAMP
Campinas SP Brazil



Newsgroups: gnu.gcc.bug
From: jonathan@gondor.math.columbia.edu (Jonathan Lennox)
Subject: gcc 2.2.2, DECstation, Ultrix 4.2, unaligned access
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 26 Sep 1992 11:16:04 GMT

  This is a re-send of a previous bug report.  I got a bounce sending
to bug-gcc@prep.ai.mit.edu before; I hope it works this time.  If you
have seen this before, I apologize.

  gcc 2.2.2 died on an unaligned access error when compiling the file
gsmain.c in ghostscript 2.5.1, recently (9-18-92) ftp'd from /pub/gnu
on prep.ai.mit.edu.

  The problem only occurs with both debugging and optimization turned
on.

  This is on a DECstation 3100, running Ultrix 4.2.

------------
# make gsmain.o
gcc -o genarch genarch.c
 ./genarch arch.h
gcc  -g -O  -c gsmain.c
pid 22790 (cc1) was killed on an unaligned access, at pc 0x46cb34
gcc: Internal compiler error: program cc1 got fatal signal 10
*** Error code 1

Stop.
# gcc -c gsmain.c
# gcc -g -c gsmain.c
# gcc -O -c gsmain.c
# gcc -g -O2 -c gsmain.c
pid 22824 (cc1) was killed on an unaligned access, at pc 0x46cb34
gcc: Internal compiler error: program cc1 got fatal signal 10
# gcc -O2 -c gsmain.c
#
--------------

I hope this supplies all the information necessary to track down this
bug (if, indeed, you have not already encountered and fixed it.)  I
hope it will be fixed in gcc 2.3; if you need any further information
to help isolate it, please let me know.

Jonathan Lennox
jonathan@math.columbia.edu


Newsgroups: gnu.gcc.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: bad warnings with sparc <stdarg.h> and -Wcast-align (gcc 2.2.2)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 19:01:32 GMT

The following short program generates four warnings of the form
"warning: cast increases required alignment of target type" when
compiled with sparc gcc 2.2.2 -Wcast-align:

	#include <stdarg.h>

	void
	foo(char *arg1, ...)
	{
		va_list ap;
		char *p;
		va_start(ap, arg1);
		p = va_arg(ap, char *);		/* warnings flagged here */
	}

The errors come from the definition of va_arg in <va-sparc.h>.  Since the
usage here is correct, the errors should be suppressed, which can be done
by casting the offending pointers to (void *).  Simply making pvar be a
"void *" fails since we need the increment-by-one property of "char *"
in va_arg().  The generated code is the same (not surprisingly).

*** 1.1	1992/10/07 02:53:12
--- va-sparc.h	1992/10/07 02:53:43
***************
*** 53,64 ****
  ({ TYPE __va_temp;						\
     ((__builtin_classify_type (__va_temp) >= 12)			\
      ? ((pvar) += __va_rounded_size (TYPE *),			\
!        **(TYPE **) ((pvar) - __va_rounded_size (TYPE *)))	\
      : __va_rounded_size (TYPE) == 8				\
      ? ({ union {TYPE d; int i[2];} u;				\
! 	 u.i[0] = ((int *) (pvar))[0];				\
! 	 u.i[1] = ((int *) (pvar))[1];				\
  	 (pvar) += 8;						\
  	 u.d; })						\
      : ((pvar) += __va_rounded_size (TYPE),			\
!        *((TYPE *) ((pvar) - __va_rounded_size (TYPE)))));})
--- 53,64 ----
  ({ TYPE __va_temp;						\
     ((__builtin_classify_type (__va_temp) >= 12)			\
      ? ((pvar) += __va_rounded_size (TYPE *),			\
!        **(TYPE **) (void *) ((pvar) - __va_rounded_size (TYPE *)))	\
      : __va_rounded_size (TYPE) == 8				\
      ? ({ union {TYPE d; int i[2];} u;				\
! 	 u.i[0] = ((int *) (void *) (pvar))[0];			\
! 	 u.i[1] = ((int *) (void *) (pvar))[1];			\
  	 (pvar) += 8;						\
  	 u.d; })						\
      : ((pvar) += __va_rounded_size (TYPE),			\
!        *((TYPE *) (void *) ((pvar) - __va_rounded_size (TYPE)))));})

--
			Chris Metcalf, MIT Laboratory for Computer Science
			metcalf@cag.lcs.mit.edu   //   +1 (617) 253-7766

Newsgroups: gnu.gcc.bug
From: jeff@uaboeing.ua.edu (Jeff A. Earickson)
Subject: gcc 2.2.2 and groff 1.06 (fixincludes)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 09:22:37 GMT

Y'all,
   I am trying to compile groff 1.06 with version 2.2.2 of gcc on a Sun4
running SunOS 4.1.1.  My version of gcc has the included "gcc.patch" from
groff put into cp-parse.y, and I did the install-fixincludes.

   Gcc barfs when it tries to use the fixincludes version of stdlib.h,
because the arguments to the function prototypes are commented out.
Observe:
Making all in include
Making all in libgroff
gcc -v -O -I. -I. -I../include -I./../include -DHAVE_UNISTD_H=1
-DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1
-DHAVE_CC_LIMITS_H=1 -DLONG_FOR_TIME_T=1 -DHAVE_MMAP=1 -DHAVE_VFORK_H=1
-DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1 -DWCOREFLAG=0200 -g 
-c fatal.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v
-DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1
-DHAVE_CC_LIMITS_H=1 -DLONG_FOR_TIME_T=1 -DHAVE_MMAP=1 -DHAVE_VFORK_H=1
-DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1 -DWCOREFLAG=0200 -I.
-I. -I../include -I./../include -undef -D__GNUC__=2 -D__GNUG__=2
-D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__
-D__sparc -D__sun -D__unix -D__OPTIMIZE__ -g fatal.cc /usr/tmp/cca16875.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus
/usr/tmp/cca16875.i -quiet -dumpbase fatal.cc -g -O -version -o
/usr/tmp/cca16875.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h: In
function `void  fatal_error_exit ()':
/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:26: too
many arguments to function `void  exit ()'
fatal.cc:26: at this point in file
*** Error code 1
make: Fatal error: Command failed for target `fatal.o'

The offending line of stdlib.h looks like:

extern void exit(/* int status */);

If the "int status" is uncommented, the problem goes away.  This fatal
error occurs many more times with groff 1.06 -- fixincludes needs to be
fixed perhaps?

/*------------------------------------------------------------------------*/
/* Jeff A. Earickson                         e-mail: jeff@uaboeing.ua.edu */
/* Cray/nCUBE/Sun Consultant,                  Work Phone: (205) 348-3969 */
/* Alabama Supercomputer Network                 Work Fax: (205) 348-3993 */
/* Boeing Computer Services                                               */
/* Address: PO Box 870346, University of Alabama, Tuscaloosa, AL 35487    */
/* "A technical book without an index is called a novel."                 */
/*------------------------------------------------------------------------*/


Newsgroups: gnu.gcc.bug
From: moss@cs.umass.edu (Eliot Moss)
Subject: Re: DECstation lui vs. li usage
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Distribution: gnu
Date: Mon, 28 Sep 1992 15:23:11 GMT

>>>>> On 24 Sep 92 16:03:52 GMT, glenn@curie.ces.cwru.edu (Glenn Crocker) said:

Glenn> gcc 2.2.2 on a decstation
Glenn> The basic question is:  why does this:

Glenn> 	li	$4,10000000

Glenn> become this:

Glenn>         lui     $4,(0x00980000)>>16     # Here's the source of my question.
Glenn>         ori     $4,$4,0x967f            # Why's it doing this instead of

Well, I can't say why one set of flags writes it out one way and the other
writes it a different way, but the MIPS cannot load a constant bigger than 16
bits in a single instruction. The li is a pseudo-op that expands to two
instructions, probably a lui followed by an ori as suggested in the MIPS
architecture book. I suspect that the pseudo-op is expanded when you request
instruction scheduling so as to admit the possibility of separating the two
instructions if that should be worthwhile. For example, a load of a different
register might be started earlier, and the ori put in the load instruction's
delay slot. Have no fear; both forms are doing the same thing at the machine
level.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu


Newsgroups: gnu.gcc.bug
From: cohrs@thumper.bellcore.com (Dave Cohrs)
Subject: gcc 2.2.2 compiler bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 18:08:47 GMT

I believe I have found a syntax checking bug in gcc 2.2.2.
That is, if my understanding about prototypes is right...

This bug is an ANSI-ism and appears to be the converse of the "char
prototype" point that you make in the Bugs section of gcc.info.

My understanding is that if you declare a function in the "old" style,
but also specify prototypes, you must widen the parameter declarations
in the prototypes to "int" from char or short.

However, gcc -Wall, says the following prototype doesn't match the
declaration in the following program:

---- start
typedef unsigned short  Dimension;

int foo(unsigned int);

int foo(x)
	Dimension x;
{
	return x + 1;
}
---- end

If I remove the word "unsigned" from the foo prototype, gcc compiles
this program happily, however, my understanding is that "unsigned"
can't just widen to a signed type.

Just to be specific, here's the output of gcc -v:

Reading specs from /usr/local/lib/gcc/mips-dec-ultrix4.2/2.2.2/specs
gcc version 2.2.2

dave cohrs

Newsgroups: gnu.gcc.bug
From: mauro@fec.unicamp.br (Engenharia Civil)
Subject: using gcc with xview
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 16:31:08 GMT

Dear sir,

We are having dificulty for running gcc compiled programs linked with
xview. A program which runs fine with cc won't run after being compiled
with gcc, after fixing a problem of declaration incompatibility between
sun.h (of xview) and stdlib.h (of gcc).

Is there a catch? Is this a "known" problem?

Awaiting your answer with interest.

Philippe Devloo

Newsgroups: gnu.gcc.bug
From: kevin@tamri.com (Kevin Dalley)
Subject: Inefficiency in once-only include files in cpp
Reply-To: kevin@tamri.com
Organization: TOSHIBA America MRI, South San Francisco, CA
Distribution: gnu
Date: Tue, 29 Sep 1992 02:12:17 GMT

I'm using the version of gcc that has been distributed for use with
Interviews, gcc.xtar.Z, though this problem probably appears in the
standard release gcc-2.2.2.  I configured gcc with "./configure
mips-sgi-irix4".  It's running on an SGI 4D/35 running Irix 4.0.1.


cpp in gcc-2.2.2 is supposed to efficiently handle multiple includes of header
files that are wrapped with conditionals like this:

     #ifndef __FILE_FOO_SEEN__
     #define __FILE_FOO_SEEN__
     
     THE ENTIRE FILE
     
     #endif /* __FILE_FOO_SEEN__ */

as long the "#ifndef" is at the beginning.  The preprocessor
successfully skips over many types of white space and comments, but
some white space is not skipped over.  I apoligize for the form feeds,
but it's part of the bug, so here goes.  I hope it's readable.

Here two files, ethel.c and
fred.h that show the inefficiency with the cpp.

ethel.c:
#include "fred.h"
#include "fred.h"

**************************************************
fred.h:

#ifndef FRED_H__
#define FRED_H__
#endif /* FRED_H__ */
**************************************************

where ^L is a form-feed.
fred.h should only be included once, but in fact it is included twice.
I ran cpp as "cpp -v ethel.c" and received the following output:
GNU CPP version 2.2.2 [AL 1.1, MM 24] Silicon Graphics Mips
# 1 "ethel.c"
# 1 "fred.h" 1




# 1 "ethel.c" 2

# 1 "fred.h" 1




# 2 "ethel.c" 2

**************************************************
If I remove the '^L' from fred.h I receive this output:
GNU CPP version 2.2.2 [AL 1.1, MM 24] Silicon Graphics Mips
# 1 "ethel.c"
# 1 "fred.h" 1




# 1 "ethel.c" 2


**************************************************
which seems more reasonable and in line with the once-only include philosophy.
I tentatively identify the problem as being in do_xifdef in cccp.c in
the following section of code:

  /* Detect a #ifndef at start of file (not counting comments).  */
  if (ip->fname != 0 && keyword->type == T_IFNDEF) {
    U_CHAR *p = ip->buf;
    while (p != directive_start) {
      char c = *p++;
      switch (c) {
      case ' ':
      case '\t':
      case '\n':
	break;
      case '/':
	if (p != ip->bufp && *p == '*') {
	  /* Skip this comment.  */
	  int junk;
	  U_CHAR *save_bufp = ip->bufp;
	  ip->bufp = p + 1;
	  p = skip_to_end_of_comment (ip, &junk, 1);
	  ip->bufp = save_bufp;
	}
	break;
      default:
	goto fail;
      }
    }
    /* If we get here, this conditional is the beginning of the file.  */
    start_of_file = 1;
  fail: ;
  }
**************************************************

The only forms of white space that are skipped are ' ', '\t', and
'\n'.  As soon as it hits the form feed, it goes to default, which
goes to fail.  It may make more sense to put a SKIP_ALL_WHITE_SPACE
(or something similar) in here somewhere, since any form of white
space should be able to precede the "#ifndef".





--
Kevin Dalley
Toshiba America MRI, Inc.
kevin@tamri.com



Newsgroups: gnu.gcc.bug
From: bob@snuffy.dracut.ma.US (Bob Smith)
Subject: cc1 dies with signal 11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 22:23:52 GMT

Hello,

(This is a resubmission because I failed to tell you what machine it
was running on in the first attempt...)

I ran into a problem building xview3 with gcc-1.41 on a Sun 3/60 running
SunOS 3.5 that I've finally isolated to the following condition.

When using -fpcc-struct-return, and compiling a piece of code that calls
a function via a pointer that returns a structure, cc1 dies with a signal
11 (SEGV).

Here's an example piece of code:

----- cut here -----
#include <stdio.h>

struct buffer {
    int a;
    int b;
} _buffer;

struct buffer set_buf();

main()
{
    foo(set_buf);
}

foo(f)
struct buffer (*f)();
{
    struct buffer d;

    d = f();                        /* <- cc1 dies with a SEGV here */
    printf("%d %d\n", d.a, d.b);
}

struct buffer
set_buf()
{
    struct buffer d;

    d.a = 1;
    d.b = 2;
    return d;
}
----- cut here -----

Not using -fpcc-struct-return in this example will let it compile
normally.  But if you know of another work-around, that'd be great...

Thanks, and have a good day!  AND THANKS for such a nice compiler!

-- 
 \ Bob Smith               \ mx: bob@snuffy.dracut.ma.us
  \ 1215 Pawtucket Blvd. #4 \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Lowell, MA. 01854       \ office && voice mail: +1 508 670-6712

Newsgroups: gnu.gcc.bug
From: basti@orthogo.UUCP (Sebastian Wangnick)
Subject: Re: 2.2.2 - Global object constructors called in wrong order
Organization: Orthogon System GmbH, Bremen, Germany
Distribution: gnu
Date: Thu, 1 Oct 1992 07:26:35 GMT

The sequence in which global objects in different source files are initialised is not determined by the language, so gcc is correct.

What we did in our library (which depends on a certain sequence as well):
Put all initialisations in routines <filename>_INIT, run nm $OBJS,
fgrep _INIT, check filename and generate one initialisation routine
in source from this information. Thus we have control over the exact sequence.

-- 
Sebastian Wangnick   Orthogon System GmbH
(basti@orthogo.uucp) Linzer Strasse 4
Tel +49 421 219136   D-2800 Bremen 33
Fax +49 421 213093   Germany

Newsgroups: gnu.gcc.bug
From: rogerr@netcom.com (roger reynolds)
Subject: Why does this need a cast?
Followup-To: poster
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Mon, 28 Sep 1992 21:07:10 GMT

	I am just getting it together as far as switching over to
	ANSI C, and am having a small problem, which I believe is 	
	a bug in gcc, though maybe I am just doing something wrong:
	I am using gcc version 2.2.2

	Here is a function definition:

XtEventHandler
dbSelectRecord(Widget w, FormRecPtr f, XButtonEvent *ev, Boolean *flag)
{
	...
}

	and later on in the same source file, I call XtAddEventHandler as :

XtAddEventHandler (f->selectionText, ButtonPressMask, 
                   FALSE, dbSelectRecord, f);

	My confusion is that I get a warning saying that dbSelectRecord
	is not the right kind of arg for this function.  If I cast it
	to (XtEventHandler)dbSelectRecord,  then all is fine.

	Seems to me like this ain't right.
	Any comments would be quite appreciated,

	rogerr@netcom.com



Newsgroups: gnu.gcc.bug
From: fox@acf5.nyu.edu (David Fox)
Subject: collect2 C output crashes gcc-2.2.2 on a vax running bsd-4.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 08:26:54 GMT

At least, it calls itself bsd-4.3.  A few things seem odd, like
the file /usr/include/machine/param.h is actually named machparam.h.
Is that normal?

Anyway, the output of collect2 contains the line

  extern entry_pt x2 asm ("__GLOBAL_$I$tie__C3ios");

And this line causes cc1 to crash.  Here is a traceback:

(gdb) where
#0  0x25889 in const_binop (code=PLUS_EXPR, arg1=(tree) 0xacdcc, arg2=(tree) 0xacaf0) (fold-const.c line 958)
#1  0x2602a in size_binop (code=PLUS_EXPR, arg0=(tree) 0xacdcc, arg1=(tree) 0xacaf0) (fold-const.c line 1336)
#2  0x249aa in layout_type (...) (...)
#3  0x22816 in build_array_type (...) (...)
#4  0xddad in init_decl_processing (...) (...)
#5  0x1cac0 in compile_file (...) (...)
#6  0x1f019 in main (...) (...)
(gdb) 

Any ideas?

-david

Newsgroups: gnu.gcc.bug
From: bernard@cpio1.FR.mugnet.ORG (Bernard Fouche)
Subject: Trouble using GCC 1.40 and stdarg.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 11:21:36 GMT

Hi.

I have a file named try.c :

#include	<stdarg.h>
void func(char *fmt,...)
{
	va_list	pa;

	va_start(pa,fmt);
	va_end(pa);
}

if I do :

/tmp(!)$ gcc -ansi try.c -c

I have :

try.c: In function func:
try.c:6: parse error before `...'

Everything is okay if I use "cc -Xc" instead of gcc. I'm running Dell
Unix (System V, Release 4.0). Uname -a gives :

cpio1 cpio1 4.0 3.0 EISA i386

Here is /usr/include/stdarg.h provided with my system :

/*	Copyright (c) 1990 UNIX System Laboratories, Inc.	*/
/*	Copyright (c) 1988 AT&T	*/
/*	  All Rights Reserved  	*/

/*	THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF     	*/
/*	UNIX System Laboratories, Inc.                     	*/
/*	The copyright notice above does not evidence any   	*/
/*	actual or intended publication of such source code.	*/

#ifndef _STDARG_H
#define _STDARG_H

#ident	"@(#)head:stdarg.h	1.8"

#if defined(__STDC__)

#ifndef _VA_LIST
#define _VA_LIST
typedef void *va_list;
#endif

#if __STDC__ != 0				/* -Xc compilation */
#define va_start(list, name) (void) (list = \
 	(void *)((char *)&name + ((sizeof(name)+(sizeof(int)-1)) & ~(sizeof(int)-1))))
#else
#define va_start(list, name) (void) (list = (void *)((char *)&...))
#endif 	/* != 0 */

#if u370
#define va_arg(list, mode) ((mode *)(list = \
        (char *) ((int)list + 2*sizeof(mode) - 1 & -sizeof(mode))))[-1]
#else
#define va_arg(list, mode) ((mode *)(list = (char *)list + sizeof(mode)))[-1]
#endif	/* u370 */

extern void va_end(va_list);

#define va_end(list) (void)0

#else	/* not __STDC__ */

#include <varargs.h>

#endif	/* __STDC__ */

#endif 	/* _STDARG_H */


Any idea ? Hope it helps you !

Thank you!

--------------------------------------------------------------------------
Bernard Fouche  VOX   : +(33) (1) 48.04.56.30  FAX :  (33) (1) 48.04.98.95
Email : bernard@cpio1.fr.mugnet.org
Postal Mail : CPIO S.A., 13-15 Rue de la Verrerie, 75004 Paris, France


Newsgroups: gnu.gcc.bug
From: gswang@mayall.cs.unlv.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 15:20:40 GMT

To:bug-gcc@prep.ai.mit.edu
cc:gswang&cs.unlv.edu
Subject:bug
--------

   I am working on a project with G++. When I try to stream 

a object into file, I find some member function of iostrem does 

not  work correctly.

     First I wrote 2 objects into file then read them back.

Everything is wrong. I want know where this bug come from? 

from my code ? or from the compiler?

     Please send me mail and tell me what is wrong ASAP, because I can 

not  make any progress on my project before this is done.

    I appreciate your time!


    the following is the code and output:




#include <std.h>
#include <fstream.h>
#include <iostream.h>
class people{
public:
  char name[20];
  long ssn;
  people(char *n,long num){ memset (name,0,20);strcpy(name,n);}
};
int main()
{ people p0("",0);
  people p1("joe",12342);
  people p2("jery",345435);
  ofstream out("file");
  out.write((char *)&p1,sizeof(p1));
  out.write((char *)&p2,sizeof(p2));
  long pos=out.tellp();
  cout<<"position after write 2 people="<< pos<<"\n";
  out.close();

  ifstream input("file");
  input.read((char *)&p0,sizeof(p0));
  cout << "This is what is red from the file :  "<< p0.name <<" "<<p0.ssn<<"\n";
    return 0;
}



mayall% g++ -v cpptest.cc
Reading specs from /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/specs
gcc version 2.1
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/cpp -lang-c++ -v -undef -D__GNUC__=
2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix
__ -D__sparc -D__sun -D__unix cpptest.cc /usr/tmp/cc021848.i
GNU CPP version 2.1 (sparc)
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/cc1plus /usr/tmp/cc021848.i -quiet
-dumpbase cpptest.cc -version -o /usr/tmp/cc021848.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o cpptest.o /usr/tmp/cc021848.s
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/ld -e start -dc -dp /lib/crt0.o -L/
local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/ -L/local/gnu/lib/ cpptest.o -lg++ -l
gcc -lc -lgcc
mayall% a.out
position after write 2 people=0
This is what is red from the file :  jjoe 0
 

    (the position should be a number greater than 0)                     
    (the output "jjoe 0 "should be "joe 12342")

Newsgroups: gnu.gcc.bug
From: jasonl@munta.cs.mu.oz.au (Jason David LEE)
Subject: Infinite loop if typen option error...
Organization: Department of Computer Sci, University of Melbourne
Distribution: gnu
Date: Tue, 6 Oct 1992 04:30:57 GMT

Hello people,

	Just thought i would mention this to see if a fix is around.
	If by mistake when using gcc version's 1.40 and 2.2.2
	you accidently add the option -Wid-clash-len as

	"-Wid-clash-len(some number)"  instead of
	"-Wid-clash-(some number)"

	it seems that the error is caught but also causes an infinite
	loop.

	That is with 1.40 an infinite loop of
		"gcc-cc1: Invalid option `-Wid-clash-len20'"
	occurs and with 2.2.2
		"cc1: Invalid option `-Wid-clash-len20'"

	Please no flame about that it is my mistake etc etc i know that
	but a simple error like this shouldn't cause such a problem
	in my opinion.

__________________________________

 Internet address: jasonl@cs.mu.OZ.AU
 Name : Jason David Lee
-- 
 Internet address: jasonl@cs.mu.OZ.AU
 Name : Jason David Lee
 Phone (home) 336 3910  (hons rm) x6892

Newsgroups: gnu.gcc.bug