mechjgh@tness7.UUCP (Greg Hackney ) (02/01/89)
FYI We hired someone to configure the networking on our Pyramid, and he left this memo. This is relating to OSx4.1. -- Greg > I have found what I think is the problem with the FTP user agent not > understanding the "binary" command. It turns out that the code is > _heavily_ dependent on the stack for argument passing - it uses a > dummy first argument as a pointer to the rest of the arguments in > variable-argument functions. This code breaks on the Pyramid. > Pyramid apparently fixed the bug in a function "command", but there is > another function, "call", which does the same thing, which they didn't > fix. As a result, things break when the commands "binary", "tenex", > etc are run, yet we can still run them via "type binary", "type > tenex", etc. I suspect that there are other bugs in other BSD and > AT&T programs stemming from this stupidity in programming style (it's > like they don't know varargs exists!).
hassler@ASD.WPAFB.AF.MIL (Barry D. Hassler,,,) (02/03/89)
> > (it's like they don't know varargs exists!). > > I'm sure I'll be corrected if I'm wrong, but it's quite > possible that when the code was actually written varargs > did not exist. There are comments in my latest set of PTFs for NSP (nsp-890109a) that indicate this problem was fixed in the December 88 timeframe (A very quick trial here verified that both "binary" and "type binary" seem to work). Call your local RTOC for more details, and possibly to receive your very own PTF. -BDH Barry D. Hassler hassler@asd.wpafb.af.mil Control Data Corp. Integrated Information Services
aglew@mcdurb.Urbana.Gould.COM (02/03/89)
> (it's like they don't know varargs exists!).
I'm sure I'll be corrected if I'm wrong, but it's quite
possible that when the code was actually written varargs
did not exist.csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/05/89)
In article <9924@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney ) writes: >> I have found what I think is the problem with the FTP user agent not >> understanding the "binary" command. It turns out that the code is >> _heavily_ dependent on the stack for argument passing - it uses a >> dummy first argument as a pointer to the rest of the arguments in >> variable-argument functions. This code breaks on the Pyramid. Old bug. Talk to RTOC for a fix. The actual "bug" here is amusing. You can do VAX-style argument-list traversal on a Pyramid, if all the arguments are integral scalars or pointers, and you have no more than 13 arguments. This is because the register stack is memory addressable. The problem is that the compiler grabs "unused" registers in the call-from window (the 'P' registers) for scratch space. So, if the function in question only declares one argument and tries to get the rest by traversal, you end up getting compiler scratch values overwriting your argument list. If you simply declare the function to have 13 arguments, then the compiler puts its scratch variables in local 'L' registers, and the parameter list traversal works. This was the fix I used for FTP. varargs was too much work. :-) (I *did* put a warning in the sources and RCS comments about an "ugly non-portable hack.") I noticed in OSx 5.0 that the compiler now puts scratch variables in the call- to register window (the 'T' registers), which neatly avoids the problem. Some- how, though, I don't think the compiler group quite had my kind of hacking in mind when they made that change.... <csg>
wendyt@pyrps5 (Wendy Thrash) (02/07/89)
In article <57894@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >The problem is that the compiler grabs "unused" registers in the call-from >window (the 'P' registers) for scratch space. So, if the function in question >only declares one argument and tries to get the rest by traversal, you end up >getting compiler scratch values overwriting your argument list. If you simply >declare the function to have 13 arguments, then the compiler puts its scratch >variables in local 'L' registers, and the parameter list traversal works. > >I noticed in OSx 5.0 that the compiler now puts scratch variables in the call- >to register window (the 'T' registers), which neatly avoids the problem. Some- >how, though, I don't think the compiler group quite had my kind of hacking in >mind when they made that change.... I suspect it's a bit early to be talking about what the OSx 5.0 compiler does, so you should probably ignore anything you hear about it. You should particularly take what Carl tells you about it with a grain of salt, though everything else he's ever written is absolutely true. :-) As the alleged perpetrator of the hypothetical register allocator that may someday appear in a Pyramid compiler, perhaps even in OSx 5.0 if there should ever be such a release of OSx, I assure you that you can't count on this hypothetical allocator to spare the PRs. If such a piece of software did exist, I'm quite sure it would cram as much as it could into TRs and LRs, but would happily use PRs if it deemed that to be necessary. Moreover, if one attempted to fool this (hypothetical) allocator by declaring dummy arguments that were never used, I'm sure the allocator would notice that they were never used and would blithely overwrite those PRs if it felt like it. I'm sure, though, that kindly compiler writers would provide some sort of mechanism, perhaps in the form of a #pragma, to prevent those registers from being used. I suspect they would even document the behavior of the allocator in the release notes. So, if Pyramid should ever release OSx m.n with m > 4 or m == 4 and n > 4, then clever programmers might want to read the release notes to see what (ahem) advances in compiler technology might do to their clever code.
hack@merkin.UUCP (Greg Hackney) (02/08/89)
In article <58126@pyramid.pyramid.com> wendyt@pyrps5.UUCP (Wendy Thrash) writes:
[...]
So *you're* the one that writes the manual sections...