Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!fletcher From: fletcher@cs.utexas.edu (Fletcher Mattox) Newsgroups: news.software.nntp Subject: Re: Nntpxmit error 0 (I have the answer & fix) Message-ID: <16367@cs.utexas.edu> Date: 31 Dec 90 19:50:58 GMT References: <16363@cs.utexas.edu> Organization: Dept of Computer Sciences, UTexas, Austin Lines: 22 In article emv@ox.com (Ed Vielmetti) writes: >In article <16363@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: > The messages which passed through here actually had the eighth > bit turned on, 0xff. This appears as DEL, 0x7f, in many pagers > and editors. Some (broken) versions of putc() will extend the > sign and return -1. > >There's comments in the ultrix (mips) 4.1 stdio.h saying that putc() >was changed in 09 Nov 1989 to properly handle this case; I take that >to mean that early mips ultrix might have had it broken (I'm fuzzy on >dates). It would be useful to know some more details of the systems >where nntp fails (name, os level and release date, etc.) Here's an example of a broken, sign-extending, putc: #define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x))):_flsbuf((unsigned)(x),p)) As best I can tell, this was present in early BSD stdio.h and was fixed between 4.2 and 4.3. I'm not sure how quickly it found its way into other vendors' BSDish products, but I notice it was fixed as far back as SunOS 3.2, and that it was broken in Dynix 3.0.4, and fixed in Dynix 3.0.14.