eichin@athena.mit.edu (Mark W. Eichin) (12/15/88)
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'' chet@pirate.CWRU.EDU (Chet Ramey) (12/16/88)
In article <8457@bloom-beacon.MIT.EDU> eichin@athena.mit.edu (Mark W. Eichin) writes:
=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.
Well, you could try opening the file for writing (unless that was just a
typo above), with an fdopen(s,"r+") or fdopen(s,"w"). I don't know why the
fputs is working now, though -- maybe it doesn't do the checking that
fprintf does?
= Mark Eichin
= <eichin@athena.mit.edu>
= SIPB Member & Project Athena ``Watchmaker''
Chet Ramey chet@cwjcc.CWRU.EDU
Network Management Group chet@alpha.CES.CWRU.EDU
Andrew R. Jennings Computing Center chet@pirate.CWRU.EDU
Case Western Reserve Universitydave@micropen (David F. Carlson) (12/16/88)
In article <8457@bloom-beacon.MIT.EDU>, eichin@athena.mit.edu (Mark W. Eichin) writes: > Strange problem: I have a mail-fetch program which uses authenticated > 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); > Mark Eichin Regardless of why the fputs works correctly (g*d only knows why), you should not make use of *writing* to a FILE * that you show you opened for *read* only. Yes, you have a non-NULL FILE * but it is not correct to write to it. inews fodder inews fodder inews fodder inews fodder inews fodder -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
eichin@athena.mit.edu (Mark W. Eichin) (12/16/88)
=Me =where f=fdopen(s, "r") earlier (and is not NULL...) The catch: If I >>chet@cwjcc.CWRU.EDU >>Well, you could try opening the file for writing (unless that was just a >>typo above), with an fdopen(s,"r+") or fdopen(s,"w"). I don't know why the Oops, typo. Actually, `s' was a socket() and it was then fdopen()ed for "r" and "w", and the fprintf is going to the one opened for write. Sorry for the confusion. Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker''
eichin@athena.mit.edu (Mark W. Eichin) (12/22/88)
Thanks to Carl Smith <cs@sun.com> for the following suggestion: >>Try attaching a buffer to it with setbuf or setvbuf after the fdopen >>but before the fprintf. Adding a setbuf(sfo,NULL); after the sfo=fdopen(s,"w"); solved the problem. If we ever get sources to libc maybe I can debug the problem, but at least I can now read my email from the Mac. Progress... Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker''