ee178acb@sdcc7.UUCP (DARIN JOHNSON) (01/02/86)
I can't seem to get anything to print out to the screen when running the pac-man like `pm'. However, if I redirect output, something is happening. I am on a Pyramid OSx. Any ideas? Darin Johnson (flsbuf.c is greek to me)
cam@bunker.UUCP (Campbell A. Moore) (01/03/86)
In article <228@sdcc7.UUCP> ee178acb@sdcc7.UUCP (DARIN JOHNSON) writes: >I can't seem to get anything to print out to the screen when running >the pac-man like `pm'. However, if I redirect output, something is >happening. I am on a Pyramid OSx. Any ideas? > >Darin Johnson >(flsbuf.c is greek to me) This program has a byte order dependency problem, that is, it passes the address of a variable when writing one byte. The authors machine presumably has low byte first so it works, but on my 68000 system I was always writing the high order 0 until I copied the variable to a new char variable and used its address. When the output is not going to stdout, different code is used. I apologize for not giving you the file name where the problem exists. I have it all at home and am describing it from memory, but I hope this is sufficient to let you find it. Cam Moore Bunker Ramo Information Systems decvax!ittatc!bunker!cam
john@polyof.UUCP ( John Buck ) (01/05/86)
> I can't seem to get anything to print out to the screen when running > the pac-man like `pm'. However, if I redirect output, something is > happening. I am on a Pyramid OSx. Any ideas? > Common problem: declare the variable that is written by the 'write()' call to be type 'char' NOT 'int' on 68000/gould type machines (which arent backwards like the vax) when you do: int c; c = 'A'; write(1, &c, 1); You DO NOT get an 'A', you get a '\0' (NULL character) On a vax it works due to its peculiar byte ordering. Anyway, the fix it make a new var (or change the declaration of 'c'.) int c; char ctmp; c = 'A'; ctmp = c; write(1, &ctmp, 1); Will work. Pm has this bug. The reason it only happens on tty's is that the buffering is single char for ttys, line or block buffered for other things, like redirection and/or pipes. John Buck Polytechnic Inst. of NY Route 110 Farmingdale, NY 11735 decvax!mcnc!{philabs!ron1,rti-sel}!polyof!john
gregg@okstate.UUCP (01/08/86)
It turns out that the problem is not so much ordering as it is the use
of the CVT instruction. By convention, only LONG WORDS are placed on the
stack, so when chars, or shorts are passed to functions, they are first
converted to longs before being placed on the stack. On the function end,
CVT is again useed to convert (if needed) the long word on the stack to the
type of the argument as specified by the declaration of the parameter. This
effectively gives you the problems that you find when INTS are passed to CHARS,
or any other combination of different types.
Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University
UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA: gregg%okstate.csnet@csnet-relay.arpa