toth@tellabs.com (Joseph G. Toth Jr.) (05/29/91)
In article <6001@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > Yes, void ** is valid, and it means pointer-to-generic pointer. > Note that void ** itself may be represented some other way entirely; > void ** is not itself a generic pointer. > > In article <AJ3U.91May27213633@jade.cs.virginia.edu>, aj3u@jade.cs.virginia.edu (Asim Jalis) writes: > > [original post deleted] > [description of why there was deception, and why there were warnings, deleted] > The compiler is RIGHT. You promised it (oh, you deceiver) that > you would give func() pointers to generic (void*) pointers > (call the representation of generic pointers REPRESENTATION 0) > But you lied (oh, you scoundrel, you). You gave it > -- a pointer to (a pointer to int -- REPRESENTATION 1) > -- a pointer to (a pointer to float -- REPRESENTATION 2) > -- a pointer to (a pointer to char -- REPRESENTATION 0) > char* and void* use the same representation. > But void*, int*, and float* need not even be the same _size_, let > alone use the same physical representation. Maybe, on different machines.o My Apple //e running HyperC uses 16 bit pointers (always). The IBM's we use at work with Microsoft C use the same size pointers as defined in the manual (always). The HP9000/300 series I use at work uses 64 bit pointers (always). On a single machine, the size of the pointer is based upon the addressable range of memory, and is always the same _size_. 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. But it just isn't so. > > > The code itself works fine, And well it should... > > no, there is a bug in there, waiting, like a blood-sucking insect > poised on a bush waiting for a deer to pass by, for an opportunity to bite. > No there isn't. (see above) > > Basically what I want is a type that would coerce to a pointer to a > > pointer to a type, for any type. Sort of one level beyond simple > > "void *". > > Why do you want to do _that_? If you _could_ do it, you would be > throwing away information that the receiver would need in order to > be able to _use_ the thing? What's the context? 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. The functions use either the value (long, int, char, etc.) and use the value (for printf functions only), or the pointer (char *, int *, float *, etc.) in the appropriate way based upon the information in the format string. This is about the most 'bug' prone method of an implementation I've ever seen, yet they are the primary method of I/O. > > -- > 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. This should also include; "force him to program in 'C', a pseudo-high level assembly language" -- ------------------------------------------------+--------------------- Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr. seldom understood. Don't FLAME on me, please. | uunet!tellab5!toth
torek@elf.ee.lbl.gov (Chris Torek) (05/30/91)
>In article <6001@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au >(Richard A. O'Keefe) writes [correctly]: >> But void*, int*, and float* need not even be the same _size_, let >> alone use the same physical representation. In article <6218@tellab5.tellabs.com> toth@tellabs.com (Joseph G. Toth Jr.) writes: >Maybe, on different machines. ... >On a single machine, the size of the pointer is based upon the >addressable range of memory, and is always the same _size_. Where were you last week when this was done to death? Or three weeks ago when it was also done to death? Or eight weeks ago when it was also done to death? Or four months ago when it was also done to death? Or... How many times do we have to tell you? *READ THE FREQUENTLY ASKED QUESTIONS.* [1] On many machines, all pointer types are the same `size and shape' as all other pointer types. These include all the machines you mentioned. [2] On other machines, all pointer types are the same `size' as all other pointer types, but have different `shapes'. One such machine series is the Data General MV series. It has `byte pointers' and `word pointers'. Both are 32 bits, but the bits are IN DIFFERENT POSITIONS in the 32-bit word. [3] On still other machines, the various pointer types are not even the same *size* as each other. One such machine is the IBM PC, where (in mixed models) function pointers and data pointers are different sizes. Or, on some Prime machines, `word pointers' are 32 bits but `byte pointers' are 48 bits. Thus, the statement: void *, int *, and float * are different sizes on different machines. is true but irrelevant. The much stronger statement: void * and int * are different sizes on this machine. is *also* true when one chooses the right referent for `this'. We now return you to your usual netnews babble. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
gwyn@smoke.brl.mil (Doug Gwyn) (05/30/91)
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 <varargs.h> or <stdarg.h> 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.
gwyn@smoke.brl.mil (Doug Gwyn) (05/30/91)
In article <13697@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >Where were you last week when this was done to death? Or three weeks >ago when it was also done to death? Or eight weeks ago when it was also >done to death? Or four months ago when it was also done to death? Or... >How many times do we have to tell you? >*READ THE FREQUENTLY ASKED QUESTIONS.* Chris, maybe it's a law of thermodynamics in action -- entropy (lack of information) is a nondecreasing function of time, no matter what one tries to do about it. This newsgroup used to be a useful tool for the working C programmer, but recently it seems to have degenerated into a vehicle for ignorant people to pester the net instead of going to the trouble to learn the C language themselves. Perhaps we've been contributing to this by helping too much when we should have been saying "GO STUDY THE AVAILABLE INTRODUCTORY C LITERATURE AND DON'T BOTHER US UNTIL YOU UNDERSTAND THE BASICS". I don't think I can justify spending any more time helping out, so I'm unsubscribing from comp.lang.c. If anyone has an INFORMED question about C that they want my help with, they can contact me directly.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/30/91)
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 <size of thing pointed to {4,6,8,48, or 96 bits}, offset from base of array, address of array _descriptor_>. 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.
sjs@gnv.ifas.ufl.edu (05/30/91)
In article <16307@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <13697@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >>Where were you last week when this was done to death? Or three weeks >>ago when it was also done to death? Or eight weeks ago when it was also >>done to death? Or four months ago when it was also done to death? Or... >>How many times do we have to tell you? >>*READ THE FREQUENTLY ASKED QUESTIONS.* Hey! Not everyone knows what subjects have been done to death. Also, some systems delete messages after they are a week or so old. Plus, many people don't know what a FAQ is (or even what the abbreviation means) until one is posted. Maybe the FAQ should be mentioned at the end of more messages, so new readers know what's going on. (I'd like to add how distasteful I find it when a new subscriber asks what certain abbreviations or cryptic references mean, only to be flamed by the clique.) > This newsgroup used to be a useful tool for the working C programmer, > but recently it seems to have degenerated into a vehicle for ignorant > people to pester the net instead of going to the trouble to learn the > C language themselves. Perhaps we've been contributing to this by > helping too much when we should have been saying "GO STUDY THE > AVAILABLE INTRODUCTORY C LITERATURE AND DON'T BOTHER US UNTIL YOU > UNDERSTAND THE BASICS". If someone wants to play censor and decide what questions are worthy of being answered then I will drop this group as well. I have no difficulty skimming the subject lines or going on to the next message if the item is one that can be answered with a little effort on the querent's part. Leave the simple queries be -- it gives the poster a chance to learn the system, and it gives others who might not be experts a chance to learn how to reply. If someone is just being a pest, he will soon stop when he finds he is being ignored, or else he will discover what "flaming" means. > I don't think I can justify spending any more time helping out, so I'm > unsubscribing from comp.lang.c. If anyone has an INFORMED question > about C that they want my help with, they can contact me directly. Like, when you drop out, people will know that you exist, considering these messages will be culled sooner or later. I think USENET works quite well for what it is: FREE. You can't expect all messages to be directed to your level of experience; for that, it is better to subscribe to a C journal. /* For the new folks: FAQ means Frequently Asked Questions; it is a message that is posted at the beginning of every month, and answers questions about pointers and lots of other C-related things. Please download it and use it as a reference. */ There, was that so hard? +---------------------------------------------+ Living in the lamb-light, the | ~~~ Borco | universal sheep; for those who | / \ ~~~ at the Mountains of Madness | wish to bleat ... must put a- | / / \ | side the ram-ifications, get | / / \ Bitnet: sjs@ifasgnv | on with the cotton-uations, | / \ Internet: sjs@gnv.ifas.ufl.edu | the ewe-nifications: the un- +---------------------------------------------+ derlying bleat. -- Rushed
tt@jadbalja.jyu.fi (Tapani Tarvainen) (05/31/91)
In article <16307@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >This newsgroup used to be a useful tool for the working C programmer, >but recently it seems to have degenerated into a vehicle for ignorant >people to pester the net instead of going to the trouble to learn the >C language themselves. Perhaps we've been contributing to this by >helping too much when we should have been saying "GO STUDY THE >AVAILABLE INTRODUCTORY C LITERATURE AND DON'T BOTHER US UNTIL YOU >UNDERSTAND THE BASICS". >I don't think I can justify spending any more time helping out, so I'm >unsubscribing from comp.lang.c. I'm sorry to hear that (and I hope you'll stay around in comp.std.c). Perhaps it would be a good idea to start a moderated group, say, comp.lang.c.gurus or something like that, if only a suitable moderator (or several) could be found (volunteers?). -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
zlsiial@cs.man.ac.uk (05/31/91)
In a recent posting Joseph Toth (toth@tellabs.com) wrote: > On a single machine, the size of the pointer is based upon the > addressable range of memory, and is always the same _size_. This is not true. I work in C on a large number of machines, and one of them has two different pointer sizes (32 and 48 bits). These access addressable memory in different ways. -- Owen
barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) (05/31/91)
In article <1991May30.093453.170@gnv.ifas.ufl.edu>, sjs@gnv.ifas.ufl.edu writes: > Hey! Not everyone knows what subjects have been done to death. Everybody should read the newsgroup for several weeks or months before asking anything. Then they would know. > Also, some systems delete messages after they are a week or so old. > Plus, many people don't know what a FAQ is (or even what the > abbreviation means) until one is posted. The FAQL is posted about once a month, so all newcomers should see it before they post anything. > Maybe the FAQ should be mentioned at the end of more messages, so new > readers know what's going on. (I'd like to add how distasteful I find > it when a new subscriber asks what certain abbreviations or cryptic > references mean, only to be flamed by the clique.) I agree. > Leave the simple queries be -- it gives the poster a chance to learn > the system, and it gives others who might not be experts a chance to > learn how to reply. If someone is just being a pest, he will soon > stop when he finds he is being ignored, or else he will discover what > "flaming" means. The stupid queries are not so bad. It's the stupid and incorrect answers that I hate. > [quoting Doug Gwyn] > > I don't think I can justify spending any more time helping out, so I'm > > unsubscribing from comp.lang.c. If anyone has an INFORMED question > > about C that they want my help with, they can contact me directly. > > Like, when you drop out, people will know that you exist, considering > these messages will be culled sooner or later. There are not many people in this newsgroup who know what they are talking about. Doug Gwyn is (was?) one of them, and his leaving will undoubtedly cause the signal to noise ratio to deteriorate further. --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!quagga!undeed!barrett
bhoughto@hopi.intel.com (Blair P. Houghton) (06/01/91)
In article <TT.91May31082959@jadbalja.jyu.fi> tt@jadbalja.jyu.fi (Tapani Tarvainen) writes: >In article <16307@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: [...wailing and carrying-on deleted for the sake of my lunch...] >I'm sorry to hear that (and I hope you'll stay around in comp.std.c). >Perhaps it would be a good idea to start a moderated group, say, >comp.lang.c.gurus or something like that, if only a suitable >moderator (or several) could be found (volunteers?). The last thing the net needs is another moderated group. Doug's being his usual, overreactive self. He just can't bear to send a little email pointing to the FAQ or even a copy of it, even though it takes ~20 keystrokes[*] in most rn implementations to start mail, enter the editor, include the FAQ, write the temporary file, exit the editor, send the message, and go on to the next posting. And he obviously doesn't remember having to ask the questions that others now ask. --Blair "A 'Flag-Day' it ain't, IMHO." [*] ~100 if you use emacs instead of vi... :-)