bill@hao.ucar.edu (Bill Roberts) (04/02/89)
Below is a simple code segment that I was trying to use on a Mac+ using
LSC 3.0. The problem is that the printed value of ptr never increments. It
always stays the same! I move this code over to a Sun4 and it works as one
would expect! What gives? Anyone else run into this problem?
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
#include <stdio.h>
#include <unix.h>
#include <storage.h>
main()
{
char *ptr;
int max= 400;
if ((ptr= (char *)malloc(500)) == NULL){
fprintf (stderr,"ERROR: malloc() \n");
exit();
}
while (max--)
fprintf (stderr,"ptr= %d\n", ptr++);
}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
--Bill
UUCP: {nbires, noao}!ncar!hao!bill
CSNET: bill@ncar.csnet
ARPA: bill%ncar@CSNET-RELAY.ARPA
INTERNET: bill@hao.ucar.edu
"... the Eagle Wing palace of the Queen Chinee'"ewing@tramp.Colorado.EDU (EWING DAVID JAMES) (04/02/89)
You've committed one of the standard C portability errors. You've assumed
that a pointer is the same sizeof() as an int. Not true. LSC (and many
other 680x0 compilers) has int's taking up 16 bits instead of 32. Try
changing your fprintf :-).
while (max--)
fprintf (stderr,"ptr= %ld\n", ptr++);
Perhaps this is slightly more portable. (ah, for a %p :->)
-dave-
| Dave Ewing | ewing@tramp.colorado.EDU |
| 4437 Clipper Ct. | AppleLink: D2408 |
| Boulder, CO 80301 | GEnie: D.EWING1 |
| | Compu$erve: 73447,1726 |oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/02/89)
In article <1704@ncar.ucar.edu> bill@hao.ucar.edu (Bill Roberts) writes: >#include <stdio.h> >#include <stdio.h> >#include <unix.h> >#include <storage.h> >main() { > char *ptr; > int max= 400; > > ptr= (char *)malloc(500); > while (max--) > fprintf (stderr,"ptr= %d\n", ptr++); > >} This is _not_ legal C. The correct program follows: #include <unix.h> #include <storage.h> main() { char *ptr; int max= 400; ptr= (char *)malloc(500); while (max--){ fprintf (stderr,"ptr= %d\n", (int) ptr); ptr++; } } The Think C manual clearly says that int == short. The Sun compiler has int == long. Both are legal choices for compiler authors to make. In printf, %d prints an int. In Lightspeed C, it only sees the high word of the pointer, so you see no change. Lightspeed C isn't wrong, Sun isn't wrong, the original program is.
fiver@cup.portal.com (Kevin D Dack) (04/03/89)
> This is _not_ legal C. The correct program follows: > > #include <unix.h> > #include <storage.h> > main() { > char *ptr; > int max= 400; > > ptr= (char *)malloc(500); > while (max--){ > fprintf (stderr,"ptr= %d\n", (int) ptr); > ptr++; > } > > } Actually, it's more likely to be portable if "malloc" is declared first, rather than allowed to default to "int" and then cast. The way it is above, you're liable to get the lower 16 bits of the return value sign-extended. (I got bit by this in someone else's code that I was porting from a 386 to a 286. Gack, I know, but this was at work and I had no choice--at least it was Xenix and not MS-DOS...) Kevin Dack fiver@cup.portal.com
kah120@ihlpe.ATT.COM (452is-Heitke) (04/03/89)
In article <1704@ncar.ucar.edu>, bill@hao.ucar.edu (Bill Roberts) writes: > Below is a simple code segment that I was trying to use on a Mac+ using > LSC 3.0. The problem is that the printed value of ptr never increments. It > always stays the same! I move this code over to a Sun4 and it works as one > would expect! What gives? Anyone else run into this problem? > > #include <stdio.h> > #include <unix.h> > #include <storage.h> > main() > { > char *ptr; > int max= 400; > > if ((ptr= (char *)malloc(500)) == NULL){ > fprintf (stderr,"ERROR: malloc() \n"); > exit(); > } > while (max--) > fprintf (stderr,"ptr= %d\n", ptr++); > > } The ptr is actually a 32 bit variable and the %d in the printf format will only print the value of a 16 bit quantity. In this case it happens to be the upper 16 bits of the address which doesn't change. To print the actual pointer value use %ld or %lx (for hex). > > --Bill Ken Heitke
pollock@usfvax2.EDU (Wayne Pollock) (04/04/89)
I think you should complain about the Sun, because your example shouldn't
work. A pointer is *not* an integer. It is meaningless to try to print
out pointers this way-- next time cast the pointer as an integer first, or
use one of the ANSI C features that lets you print a pointer with a \p
(incidently, this conflicts with current use of \p to indicate a pascal
type string--I hope at least a warning will be generated in future LSC).
I'm only guessing, but I think that on a mac, malloc generates a handle
to some storage, not a simple pointer. So the thing you kept decrementing
was "*ptr", not"ptr". Naturally "ptr" doesn't change each time. (Any-
body know if this is right?)
In any case, you really should check these things out before calling some
product "brain damaged". There are nice, polite ways to ask about a
possible bug in software. I'm no lawyer but someday someone might
want to sue you for such statements made publicly. How would you like
people to start calling your product "Brain damaged"? What if it wasn't
your product's fault but sales started to slip anyway?
The right to freedom of speech entails certain responsibilites. Think twice
before posting derogatory comments! Think C may have bugs but I really
don't think you can consider it brain damaged. I think its a terrific
product, and so do may others who have posted here previously.
Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu
Usenet: ...!{uflorida, codas}!usfvax2!pollock
GEnie: W.POLLOCKdwb@sticks.apple.com (David W. Berry) (04/04/89)
In article <1259@usfvax2.EDU> pollock@usfvax2.UUCP (Wayne Pollock) writes: >I think you should complain about the Sun, because your example shouldn't >work. A pointer is *not* an integer. It is meaningless to try to print >out pointers this way-- next time cast the pointer as an integer first, or >use one of the ANSI C features that lets you print a pointer with a \p >(incidently, this conflicts with current use of \p to indicate a pascal >type string--I hope at least a warning will be generated in future LSC). Actually, there shouldn't be a conflict. \p is used to generate a pascal style string and %p is used to print a pointer. > >I'm only guessing, but I think that on a mac, malloc generates a handle >to some storage, not a simple pointer. So the thing you kept decrementing >was "*ptr", not"ptr". Naturally "ptr" doesn't change each time. (Any- >body know if this is right?) Nope, malloc still generates a simple pointer. The problem, as pointed out earlier, is that only the upper order bytes of the pointer were being printed out, and they didn't ever change. Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry (A/UX Toolbox Engineer) dwb@apple.com 973-5168@408.MaBell AppleLink: berry1