jf@ap.co.umist.ac.uk (John Forrest) (11/14/90)
I'm going to be accused of crying wolf for this. We've compiled sendmailv5.65+IDA in a mode which was supposed to be compatible with our old v5.61 [as an upgrade step, to see if the new binary works in practice]. The differences between that and the standard are almost all related to canonical name lookups, together with a few minor fixes to get it to run/compile on our Apollo 10.1 system. Now we reach a real problem. Each time mail is ``delivered'' (each time it passes through this sendmail) a new blank line is added to blank lines in the original. Has anybody got any ideas about this? The relevant mailer lines in the .cf file are: Mtcpld, P=[IPC], F=mDFMueXLC, S=17, R=27, A=IPC $h, E=\r\n and Mlocal, P=/bin/mail, F=rlsDFMmn, S=10, R=20, A=mail -d $u The tests were done by sending mail through the IPC gateway and back - thus passing through the sendmail twice. Sending to a user the other side of the gateway resulted in blank lines doubling. The .cf files are derived from the 5.61 Berkeley distribution. John Forrest Dept. of Computation UMIST
Andy.Linton@comp.vuw.ac.nz (Andy Linton) (11/15/90)
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
You can check whether this bug is present in your doprnt() routine by
the following:
#include <stdio.h>
main()
{
printf("doprnt() is %.0scorrect\n", "NOT ");
}
The old version of putline() could be used to further check for the
prescence of this bug.jf@ap.co.umist.ac.uk (John Forrest) (11/15/90)
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 |> |> You can check whether this bug is present in your doprnt() routine by |> the following: |> |> #include <stdio.h> |> |> main() |> { |> printf("doprnt() is %.0scorrect\n", "NOT "); |> } |> |> The old version of putline() could be used to further check for the |> prescence of this bug. 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. John Forrest Dept of Computation UMIST.
Andy.Linton@comp.vuw.ac.nz (Andy Linton) (11/19/90)
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 |> |> |> |> You can check whether this bug is present in your doprnt() routine |> by |> |> the following: |> |> |> |> #include <stdio.h> |> |> |> |> main() |> |> { |> |> printf("doprnt() is %.0scorrect\n", "NOT "); |> |> } |> |> |> |> The old version of putline() could be used to further check for |> the |> |> prescence of this bug. |> |> 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 hope someone at HP/Apollo is listening though because there is a bug in doprnt(). I haven't looked at the efficiency either but the *correct* answer is not to install the old version of putline() but to fix the bug in doprnt().I
bruce@balilly.UUCP (Bruce Lilly) (11/22/90)
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