Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: pointer size Message-ID: <16306@smoke.brl.mil> Date: 30 May 91 03:16:05 GMT References: <6001@goanna.cs.rmit.oz.au> <6218@tellab5.tellabs.com> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 37 In article <6218@tellab5.tellabs.com> toth@tellabs.com (Joseph G. Toth Jr.) writes: >On a single machine, the size of the pointer is based upon the >addressable range of memory, and is always the same _size_. Wrong. The most common architectural cause of use of different sizes for pointers to different types is a word-oriented machine where it takes additional bits to select a byte within a word, so "char *" is then implemented as a larger size than other object pointer types. ("void *" is represented the same as "char *".) Another such situation occurs when it takes more bits to fully represent function (I-space) addresses that it does for data object (D-space) addresses. >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. There is no problem, if you use malloc()/free() correctly, for example if you make sure it is properly declared before you invoke it, so it is not treated as returning int. >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. This is entirely wrong. A stack need not be used, but if it is, the sizes of the arguments can vary from one argument to the next. The definition of the function uses the format specifiers to decide how to pick up each argument, and a portable implementation will use or to do that. The va_arg() macro takes a type argument, specifically so it can pick up the correct amount of data in the correct format from the set of arguments. >This should also include; > "force him to program in 'C', a pseudo-high level assembly language" Maybe if you didn't treat C as an assembly language you might better appreciate how to use it properly.