Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!eichin
From: eichin@athena.mit.edu (Mark W. Eichin)
Newsgroups: comp.unix.aux
Subject: fprintf() weirdness?
Keywords: portability fprintf core
Message-ID: <8457@bloom-beacon.MIT.EDU>
Date: 15 Dec 88 00:28:52 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: eichin@athena.mit.edu (Mark W. Eichin)
Organization: Massachusetts Institute of Technology
Lines: 25

Strange problem: I have a mail-fetch program which uses authenticated
POP to talk to a mail server and retrieve mail. It uses an SMTP-like
protocol, ie. commands are text with \r\n at the end of each line.

It runs perfectly on the VAX and IBM PC/RT under 4.3BSD. When I
compile it under A/UX and run it, I get a core dump in the first

	fprintf(f, "%s\r\n", buf);

where f=fdopen(s, "r") earlier (and is not NULL...) The catch: If I
change the fprintf to a

	fputs(buf,f); fputs("\r\n",f);

it works. The core dump in fprintf (according to adb) is the result of
calling bcopy(0,buf,0xB) which appears to be from the FILE structure
remaining uninitialized. As I said, it works perfectly under 4.3, and
the code gives no warnings under Saber (a C interpreter which catches
far more than lint does, specfically bounds checks.) Any suggestions
as to what these symptoms might be? Not having source (insert standard
FLAME here) makes it hard to debug fprintf. I suspect there is some
SysV idiom I am missing here, though.

				Mark Eichin
			<eichin@athena.mit.edu>
		SIPB Member & Project Athena ``Watchmaker''