Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!julius.cs.uiuc.edu!rpi!uupsi!vmp!sonyd1.Broadcast.Sony.COM!blilly.UUCP!balilly.UUCP!bruce
From: bruce@balilly.UUCP (Bruce Lilly)
Newsgroups: comp.mail.sendmail
Subject: Re: Sendmailv5.65+IDA problem
Message-ID: <1990Nov21.224037.3309@blilly.UUCP>
Date: 21 Nov 90 22:40:37 GMT
References: <1990Nov13.173733@ap.co.umist.ac.uk> <1990Nov14.215011.4610@comp.vuw.ac.nz> <1990Nov15.110911@ap.co.umist.ac.uk>
Sender: news@blilly.UUCP (News Administrator)
Organization: Bruce Lilly, Flushing, NY
Lines: 28

In article <1990Nov15.110911@ap.co.umist.ac.uk> jf@ap.co.umist.ac.uk (John Forrest) writes:
>In article <1990Nov14.215011.4610@comp.vuw.ac.nz>, Andy.Linton@comp.vuw.ac.nz (Andy Linton) writes:
>|> 
>|> This could be the same problem that I came against and posted details of
>|> a few days ago. On our MOREbsd HP boxes there is/was a bug in routine
>|> doprnt() which is called by printf() and co. The bug is exercise by the
>|> new version of putline() in util.c
>
>This has indeed turned out to be the problem. The old 5.61 putline works fine on
>our Apollo system, the new one does not. I'm not sure why it has changed, anyway
>- on a cursorary glance, the expected behaviour seems identical, and I don't
>believe the new complicated printf's are necessarily more efficient than the
>previous fputs calls.

I submitted the newer version of putline() due to incompatibility of the
old code with some compilers, such as gcc, which put quoted strings in the
(read-only) text section of the executable file.  The old version of
putline() tried to write into such strings, causing a memory fault and
termination of sendmail due to a segmentation violation. The new version
works fine with non-broken doprnt()'s, although a further revision was
posted here (by me) in response to an earlier detection of the HP printf()
problem. Consult your archives or send email for further details.

Aside from avoiding the memory faults - which prevented sendmail from
working at all - the newer version is easier to read and understand
(IMHO).  ``Efficiency'' was not a consideration.
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM