Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: pointer size (Was: Re: "void **" : Is it valid and what does it mean?) Message-ID: <6037@goanna.cs.rmit.oz.au> Date: 30 May 91 05:57:19 GMT References: <6001@goanna.cs.rmit.oz.au> <6218@tellab5.tellabs.com> Distribution: comp Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 59 In article <6218@tellab5.tellabs.com>, toth@tellabs.com (Joseph G. Toth Jr.) writes: > In article <6001@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > > But void*, int*, and float* need not even be the same _size_, let > > alone use the same physical representation. > Maybe, on different machines. > [Appel //e, IBM PCs w/ Microsoft C, HP9000/300 use fixed-size pointers] Well, bully for you. But what I wrote is correct, nevertheless. > On a single machine, the size of the pointer is based upon the > addressable range of memory, and is always the same _size_. I'm sorry, but I really do think you ought to think before you post. The statement above is simply NOT TRUE. The subject has been beaten to death on comp.lang.c, and is explained in the FAQ. Everyone should read the FAQ list at least once a year. The size of a pointer is NOT necessarily based on the addressable range of memory. For example, I used to use (and still like) a machine where the addressable range of memory was 2^20 *words*, but a pointer was 48 bits. If I remember correctly, and it has been a long time, a pointer was . There was no such thing in that machine as a bare address. After that, I used a machine where int* values were 32 bits and char* values were 48 bits. (Actually, I had to program that one in Fortran and Assembler, not C.) > If it weren't, malloc and all of the other memory allocation functions > would be meaningless, and a source of the 'blood-sucking insect (bug)' > stated below. This is also an incorrect statement. But I'll leave the correction for the computer architecture and/or programming language implementation courses and books you have yet to take advantage of. > Just look at printf ans scanf (and all their associated functions). > The list of remaining values is effectively an array on the stack > where the elements may or may not even be pointers. Like, Wow. This character doesn't understand argument passing any better than addresses. What makes you think there is a stack in memory which can be addressed like an array? It Ain't Necessarily So, and on quite a lot of machines It Simply Isn't True. (On a Prime, for example, the procedure call mechanism ensures that what you get _is_ an array of pointers. No hardware pass by value on that machine! On a VAX, the arguments are an array, but they need not be on the stack. On a SPARC, the arguments are not in memory.) I have to admit that I wrote a version of printf() for a machine where the vendor's one had some bugs, and my company really loved me when they ported it to another machine and it broke, because the arguments on that machine were NOT "effectively an array on the stack". In short, before you criticise someone else's answers, make sure you understand the problem. Computer architectures _in use today_ are a lot stranger than many people realise. -- Should you ever intend to dull the wits of a young man and to incapacitate his brains for any kind of thought whatever, then you cannot do better than give him Hegel to read. -- Schopenhauer.