eap@bucsb.bu.edu.UUCP (Eric Pearce) (07/06/87)
Anybody else have this problem with Nathan Glasser's "Centipede" ?
% make
cc -O -c cent.c
cc -O -c stuff.c
cc -O -c input.c
cc -O -c interrupts.c
cc -O -c score.c
cc -O -c move.c
cc -O -c rand.c
cc -O -c save.c
"save.c", line 133: Cannot take the address of this object
*** Error code 1
Stop.
Line 133 is: read(fd,&ch,1);
(the only changes I made were to paths in 'sys_dep.c', as per instructions)
(doing this on Encore Multimax runnning 4.2 BSD )
--
*******************************************************************************
* UUCP : ..!harvard!bu-cs!bucsb!eap |-+-+ +-+-+-+-+-+-+-+\ /-+-+-+-+-+-+-+-+*
* ARPANET: eap@bucsb.bu.edu | > : : : - @ - | g *
* CSNET : eap%bucsb@bu-cs |-+-+-+-+-+-+-+-+-+-+/ \ +-+-+ +-+-+ +-+*
* BITNET : cscc8vc@bostonu | | Blasted by ZAXXON | ; | *
*******************************************************************************dpz@soliloquy.rutgers.edu (David P. Zimmerman) (07/06/87)
> From: eap@bucsb.bu.edu.UUCP (Eric Pearce) > Anybody else have this problem with Nathan Glasser's "Centipede" ? > "save.c", line 133: Cannot take the address of this object 109c109 < register char ch; --- > register char *ch; 133c133 < read(fd,&ch,1); --- > read(fd,ch,1); 135c135 < ch != MAGICNUM) --- > *ch != MAGICNUM) dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu
brisco@caip.rutgers.edu (Thomas Paul Brisco) (07/06/87)
] Anybody else have this problem with Nathan Glasser's "Centipede" ?
]
]"save.c", line 133: Cannot take the address of this object
]*** Error code 1
]
]Stop.
]
]Line 133 is: read(fd,&ch,1);
]
](the only changes I made were to paths in 'sys_dep.c', as per instructions)
](doing this on Encore Multimax runnning 4.2 BSD )
]
The problem is that "ch" is defined as a "register char" --
remove the "register" part and it will compile. My compiler
complained, but did not barf, on this. It is really not a wise idea
to take the address of a register (they typically live at address 1 or
thereabouts). I got two of these messages overall, so you may run into
another.
Tp.
--
----------------------------------------------------------
- ARPA: Brisco@rutgers -
- UUCP: (ihnp4!ut-sally, allegra!packard) !caip!brisco -
----------------------------------------------------------dpz@soliloquy.rutgers.edu (David P. Zimmerman) (07/06/87)
> From: dpz@soliloquy.rutgers.edu (David P. Zimmerman) > 109c109 > > register char *ch; > 135c135 > > *ch != MAGICNUM) Sorry about that premature message - change that first *ch to ch[1]. You may also want to change the second *ch to ch[1], but it works ok here (Sun 3.2). dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/07/87)
In article <758@soliloquy.rutgers.edu> dpz@soliloquy.rutgers.edu (David P. Zimmerman) writes:
-109c109
-< register char ch;
----
-> register char *ch;
-133c133
-< read(fd,&ch,1);
----
-> read(fd,ch,1);
-135c135
-< ch != MAGICNUM)
----
-> *ch != MAGICNUM)
NO! What is `ch' pointing to?dpz@soliloquy.rutgers.edu (David P. Zimmerman) (07/07/87)
> From: dpz@soliloquy.rutgers.edu (David P. Zimmerman) > You may also want to change the second *ch to ch[1], but it works ok > here (Sun 3.2). Yeeps. Foot in mouth time. Make that "You may ... ch[0], ..." dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu
dgy@cald80.UUCP (dgy) (07/07/87)
In article <1031@bucsb.bu.edu.UUCP> eap@bucsb.UUCP (EAP) writes: > Anybody else have this problem with Nathan Glasser's "Centipede" ? ... > cc -O -c save.c >"save.c", line 133: Cannot take the address of this object >*** Error code 1 > >Stop. > >Line 133 is: read(fd,&ch,1); If you look at the top of the routine you'll see that the variable 'ch' is a 'register char.' Get rid of the word 'register' and it should work fine. Dave Yearke Sigma Systems Technology, Inc. seismo!kitty!sunybcs!cald80!sigmast!dgy decvax!sunybcs!cald80!sigmast!dgy
guy@gorodish.UUCP (07/07/87)
> Sorry about that premature message - change that first *ch to ch[1]. > You may also want to change the second *ch to ch[1]... No, you won't. If "ch" is a one-element array, "ch[1]" is an expression whose meaning is not defined. You may want to change the second "*ch" to "ch[0]", but that would only be for aesthetic reasons; "*ch" and "ch[0]" mean exactly the same thing in this case. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
tsmith@milano.UUCP (07/08/87)
In article <1031@bucsb.bu.edu.UUCP>, eap@bucsb.bu.edu.UUCP (Eric Pearce) writes: > > Anybody else have this problem with Nathan Glasser's "Centipede" ? > > > % make > cc -O -c cent.c > cc -O -c stuff.c > cc -O -c input.c > cc -O -c interrupts.c > cc -O -c score.c > cc -O -c move.c > cc -O -c rand.c > cc -O -c save.c > "save.c", line 133: Cannot take the address of this object > *** Error code 1 > > Stop. > > Line 133 is: read(fd,&ch,1); > I changed the declaration: register char ch; to char ch; and the error message went away. -- Thomas J. Smith @ MCC Software Technology tsmith@mcc.com sally!im4u!milano!tsmith
herman@ti-csl.CSNET (Herman Schuurman) (07/09/87)
in article <4287@caip.rutgers.edu>, brisco@caip.rutgers.edu (Thomas Paul Brisco) says: > > . . . . . It is really not a wise idea > to take the address of a register (they typically live at address 1 or > thereabouts). . . . . . . > According to K&R page 89: "It is also illegal to take the address of a register variable."
nathan@eddie.MIT.EDU (Nathan Glasser) (07/12/87)
In article <25245@ti-csl.CSNET> herman@ti-csl.CSNET (Herman Schuurman) writes: >in article <4287@caip.rutgers.edu>, brisco@caip.rutgers.edu (Thomas Paul Brisco) says: >> . . . . . It is really not a wise idea >> to take the address of a register (they typically live at address 1 or >> thereabouts). . . . . . . >According to K&R page 89: > "It is also illegal to take the address of a register variable." About this register variable stuff: At some point I probably made ch a register variable (why not), not realizing that I was already using the expression &ch somewhere. Since I was doing this on 4.xBsd Unix on a Vax, the compiler didn't complain. I probably still wouldn't know about it. if people hadn't started trying it on other systems. -- Nathan Glasser nathan@mit-eddie.uucp (usenet) fnord nathan@xx.lcs.mit.edu (arpa) "A tribble is the only love that money can buy."
amos@nsta.UUCP (Amos Shapir) (07/13/87)
In article <6284@eddie.MIT.EDU> nathan@eddie.MIT.EDU writes: >Since I was doing this on 4.xBsd Unix on >a Vax, the compiler didn't complain. I probably still wouldn't know >about it, if people hadn't started trying it on other systems. Or if you had run 'lint' on it, as decency requires you should have done before posting it! -- Amos Shapir National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261 amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N
davidp@csadfa.oz (David Purdue) (07/15/87)
in article <758@soliloquy.rutgers.edu>, dpz@soliloquy.rutgers.edu (David P. Zimmerman) says:
]
]> From: eap@bucsb.bu.edu.UUCP (Eric Pearce)
]
]> Anybody else have this problem with Nathan Glasser's "Centipede" ?
]
]> "save.c", line 133: Cannot take the address of this object
]
] 109c109
] < register char ch;
] ---
]> register char *ch;
] 133c133
] < read(fd,&ch,1);
] ---
]> read(fd,ch,1);
] 135c135
] < ch != MAGICNUM)
] ---
]> *ch != MAGICNUM)
THIS PATCH IS NOT GOOD PROGRAMMING! It is not even guaranteed to work
(and in most cases I suspect it won't). You see, by changing ch to *ch,
you are only allocating storage for a POINTER to the char, not for the
char (note the absence of a malloc()). The better fix is to drop
the 'register' from 'register char ch' and put up with the (slight)
(noticable??) degredation in performance.
DavidP
----
Mr. David Purdue Phone ISD: +61 62 68 8165
Dept. Computer Science Telex: ADFADM AA62030
University College ACSNET/CSNET: davidp@csadfa.oz
Aust. Defence Force Academy UUCP: ...!seismo!munnari!csadfa.oz!davidp
Canberra. ACT. 2600. ARPA: davidp%csadfa.oz@SEISMO.CSS.GOV
AUSTRALIA JANET: davidp@oz.csadfa
"Perversity Rules, C.Q.!"oleg@quad1.quad.com (Oleg Kiselev) (07/24/87)
Change of >] < register char ch; to >]> register char *ch; >THIS PATCH IS NOT GOOD PROGRAMMING! [... AND THE GOOD REASONS WHY ] >char (note the absence of a malloc()). The better fix is to drop >the 'register' from 'register char ch' and put up with the (slight) >(noticable??) degredation in performance. How about: char xxx; register char *ch = &xxx; then you can keep register access speed improvements (if any). -- Oleg Kiselev -- oleg@quad1.quad.com -- {...!psivax|seismo!gould}!quad1!oleg DISCLAIMER: All grammatical and spelling errors are inserted deliberately to test the software I am developing. In fact, that is the only reason I am posting. Yeah, that's the ticket! All my postings are just test data! Yeah!!