t-iaind@microsoft.UUCP (Iain Davidson) (05/26/89)
..
Something that went un-noticed in a few messages:
char a[33]
is not an array of 33*sizeof (int) but really 34 slots !!!!!
Remember C is start base 0 not 1.
0..33 = 34 slots of int's.
char a[9] holds 10 characters !!!!
(mistake me if I'm wrong, as i'm sure you will.... via flame-mail :)
-----------------------------------------------------------------
Iain Davidson, formally of Bellingham, WA's BelAmi! Fame
UUCP: {uucp|uw-beaver}!microsof!t-iaind (How did he move that "t" ???)
BITNET: microsof!t-iaind@beaver.cs.washington.edu
for really smart mailers: t-iaind@microsoft.BITNET or .CSNET or .UUCP
*** Disclaimer: ***
My employer and fellow employees will (have, has) disclaim anything I say
past, future, or present...... so there !!!!.... :)
-----------------------------------------------------------------chris@mimsy.UUCP (Chris Torek) (05/26/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: >char a[33] > >is not an array of 33*sizeof (int) This much is true (it is size 33*sizeof(char), or 33) ... >but really 34 slots !!!!! > >Remember C is start base 0 not 1. > >0..33 = 34 slots of int's. > >char a[9] holds 10 characters !!!! C is not BASIC. `char a[9]' holds nine characters, numbered a[0] through a[8] inclusive. (Actually, BASICs tend not to be consistent about allowing a[0].) And people wonder why microsoft's compilers are buggy :-) Actually, there is a grain of truth in all this. Given an array declaration type-name array-name '[' integral-constant-expression ']' ';' or T a[N]; the address &a[N] must be computable. This sometimes means that array objects need an extra byte---so that int b[K]; actually sets aside K*sizeof(int)+1 bytes, rather than just K*sizeof(int). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
tneff@bfmny0.UUCP (Tom Neff) (05/26/89)
I don't mean to dump on this poster in particular, but would readers
of this newsgroup *PLEASE* read a book on *C* before posting here??!!
For some reason there has been a spate of very SILLY novice questions
here in the past couple of weeks. It's expensive and inefficient to
post to the net instead of picking up K&R or Harbison & Steele.
--
Tom Neff UUCP: ...!uunet!bfmny0!tneff
"Truisms aren't everything." Internet: tneff@bfmny0.UU.NETarrom@aplcen.apl.jhu.edu (Ken Arromdee) (05/26/89)
>Something that went un-noticed in a few messages: >char a[33] >is not an array of 33*sizeof (int) but really 34 slots !!!!! >Remember C is start base 0 not 1. >0..33 = 34 slots of int's. Boy are you going to get flamed.... -- "Do you know what this is????" "No, what?" "I don't know either..." -- Who said it, what story? Kenneth Arromdee (UUCP: ....!jhunix!ins_akaa; BITNET: g49i0188@jhuvm; INTERNET: arromdee@crabcake.cs.jhu.edu) (please, no mail to arrom@aplcen)
ark@alice.UUCP (Andrew Koenig) (05/27/89)
In article <5819@microsoft.UUCP>, t-iaind@microsoft.UUCP (Iain Davidson) writes: > Something that went un-noticed in a few messages: > char a[33] > is not an array of 33*sizeof (int) but really 34 slots !!!!! No, it's 33 slots. > Remember C is start base 0 not 1. Yes. > 0..33 = 34 slots of int's. Yes, but whan you say `char a[33];' you're declaring 0..32, not 0..33 > char a[9] holds 10 characters !!!! No, char a[9] holds 9 characters. -- --Andrew Koenig ark@europa.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/27/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: >char a[33] >0..33 = 34 slots of int's. Wrong.
paulc@microsoft.UUCP (Paul Canniff 2/1011) (05/27/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: > >Something that went un-noticed in a few messages: >char a[33] >is not an array of 33*sizeof (int) but really 34 slots !!!!! >Remember C is start base 0 not 1. >0..33 = 34 slots of int's. >char a[9] holds 10 characters !!!! >(mistake me if I'm wrong, as i'm sure you will.... via flame-mail :) I have sent the requested flame-mail. I, along with his employer and probably all his friends, appreciate his disclaimer. Please ignore the above posting. Thank you. -------------- I also have a wonderful disclaimer that absolves Microsoft from all my actions and vice-versa, but this is so much nicer and lets me send the above short reply in spite of the mailer's stupid line-counting. Phew!
t-stephp@microsoft.UUCP (Stephen Poole) (05/27/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: >char a[9] holds 10 characters !!!! >(mistake me if I'm wrong, as i'm sure you will.... via flame-mail :) Lordy Heavens! I'm sending the flame mail right after this. I think all of that was a big typo. Yeah, that's it. -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
rampson@nbires.nbi.com (Michael Rampson) (05/27/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: >.. > >Something that went un-noticed in a few messages: > >char a[33] > >is not an array of 33*sizeof (int) but really 34 slots !!!!! Me thinx not. Whatsa slot (sizeof(slot) = ?) and shouldn't there be 33 of them? > >Remember C is start base 0 not 1. Atleast this is right. >0..33 = 34 slots of int's. a[33] holds 33 char's whose indices range from 0..32. > >char a[9] holds 10 characters !!!! Does not! It holds 9 characters !!!! > > >(mistake me if I'm wrong, as i'm sure you will.... via flame-mail :) You were right (about this anyway ;-)! > My employer and fellow employees will (have, has) disclaim anything I say >past, future, or present...... so there !!!!.... :) I'm sure usoft will... ;-) I N E W S F O D D E R Michael T. Rampson rampson@nbires || nbires\!rampson NBI, Inc. Boulder, Co. -- Exxon - A greek word meaning "Whoops". -- David Letterman
karl@haddock.ima.isc.com (Karl Heuer) (05/27/89)
In article <17763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <5819@microsoft.UUCP> microsoft!t-iaind (Iain Davidson) writes: >>[incorrectly states that char a[33] has 34 elements.] Prepare for a flood of replies. Time to update your kill files, folks. >Actually, there is a grain of truth in all this. Given an array declaration > T a[N]; >the address &a[N] must be computable. This sometimes means that >array objects need an extra byte---so that > int b[K]; >actually sets aside K*sizeof(int)+1 bytes, rather than just K*sizeof(int). This is true, but could be misleading to much of the audience, so I'll rephrase it. It is required that the overlast element of the array be addressible, but there need not be any storage reserved for it, unless this is necessary for addressiblity. For example, given two declarations int a[4]; int b[7]; it is perfectly legal for the compiler to allocate exactly 11*sizeof(int) bytes, and to have &a[4] be the same address as &b[0]. Similarly, &b[7] could legally be at the end of memory, pointing to nothing dereferencable; all that's required is that &b[7] can be computed and stored in a pointer variable (and that the usual laws of pointer arithmetic are obeyed). On some architectures, the end of all memory (or of a segment) does not satisfy this rule; in this case only, the compiler must insert a shim. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint (Btw, there is no reason to suppose that a and b are adjacent in memory, or that a precedes b. That was just an example of a legal implementation.)
t-iaind@microsoft.UUCP (Iain Davidson) (05/27/89)
In article <5819@microsoft.UUCP> you write: >.. >Something that went un-noticed in a few messages: >char a[33] >is not an array of 33*sizeof (int) but really 33 (0..32) slots !!!!! >Remember C is start base 0 not 1. >0..32 = 33 slots of int's. >char a[9] holds 9 characters (0..9) !!!! >(mistake me if I'm wrong, as i'm sure you will.... via flame-mail :) >----------------------------------------------------------------- >Iain Davidson, formally of Bellingham, WA's BelAmi! Fame > >UUCP: {uucp|uw-beaver}!microsof!t-iaind (How did he move that "t" ???) >BITNET: microsof!t-iaind@beaver.cs.washington.edu > for really smart mailers: t-iaind@microsoft.BITNET or .CSNET or .UUCP >*** Disclaimer: *** > My employer and fellow employees will (have, has) disclaim anything I say >past, future, or present...... so there !!!!.... :) >----------------------------------------------------------------- I never pretend that I know about "C", but..... Ooooppppsss, The caffine haze has come again. Please ignore the above message. I was trying to make a point, but the numbers were all WRONG... all wrong... all wrong... (-1) That's what I get posting in a group that I rarely post in--and posting at 2 am in the morning..... argghhhh.... Wrong words/numbers, right idea. :-< Iain o o L _---_
envbvs@epb2.lbl.gov (Brian V. Smith) (05/27/89)
In article <17763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: [ some stuff] >Similarly, &b[7] could legally be at the end of memory, pointing to nothing >dereferencable; all that's required is that &b[7] can be computed and stored ^^^^^^^^^^^^^^ Please excuse my ignorance, but I've seen this word many times now, and it's not in Webster's. What does "dereferencable" mean? I could see "referencable", meaning "can be referenced", but de-referencable? _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
evan@plx.UUCP (Evan Bigall) (05/28/89)
In article <2737@helios.ee.lbl.gov> envbvs@epb2 (Brian V. Smith) writes: >In article <17763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>Similarly, &b[7] could legally be at the end of memory, pointing to nothing >>dereferencable; all that's required is that &b[7] can be computed and stored > ^^^^^^^^^^^^^^ >Please excuse my ignorance, but I've seen this word many times now, and it's >not in Webster's. >be referenced", but de-referencable? >What does "dereferencable" mean? I could see "referencable", meaning "can Informally, remember that addresses are often called pointers. The verb "to derefrence" referrs to the action of `following' the pointer to see what it points at. ie: what is the contents of that particular address in memory. From a more formal perspective * is the derefrence operator in C. From K&R 89 The unary operator * treats its operand as the address of the ultimate target, and accesses that address to fetch the contents. So, what Chris means (imho) is that it is possible to have a legal pointer that points to the end of memory (or just the end of a segment) but have * fail (coredump). Does that help? -- Evan Bigall, Plexus Computers, San Jose, CA (408)943-2283 ...!sun!plx!evan "I barely have the authority to speak for myself, certainly not anybody else"
gorpong@telxon.UUCP (Gordon C. Galligher) (05/28/89)
In article <5819@microsoft.UUCP> t-iaind@microsoft.UUCP (Iain Davidson) writes: >.. > >Something that went un-noticed in a few messages: > >char a[33] > >is not an array of 33*sizeof (int) but really 34 slots !!!!! > >Remember C is start base 0 not 1. > >0..33 = 34 slots of int's. ^^^^^^^^^^^ int foo[33] :==> 0..32, not 0..33. K&R1: Page 20 1.6 Arrays ... The declaration int ndigit[10]; declared ndigit to be an array of 10 integers. Array subscripts always start at zero in C (rather than 1 as in Fortran or PL/1), so the elements are ndigit[0], ndigit[1], ..., ndigit[9]. [**] K&R2: Page 22 is exactly the same excluding the part in parentheses. -- Gordon. -- Gordon C. Galligher <|> ...!uunet!telxon!gorpong <|> gorpong@telxon.uucp.uu.net Telxon Corporation <|> "Before they warped out of orbit I beamed the whole kit Akron, Ohio, 44313 <|> and kabootle into their engine room." - Scotty (216) 867-3700 (3512)<|> (Trouble with Tribbles)
karl@haddock.ima.isc.com (Karl Heuer) (05/28/89)
In article <2737@helios.ee.lbl.gov> envbvs@epb2 (Brian V. Smith) writes: >In article <17763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: That's a misattribution; I wrote the text in question. >>pointing to nothing dereferencable; >What does "dereferencable" mean? In C, unary "&" is the referencing operator; its inverse, unary "*", is the dereferencing operator. To "dereference" is to retrieve what a pointer points to. Certain pointer values, e.g. a null pointer or the overlast element of an array, are not dereferencable. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ (The "overlast" element of an array a of size N is the ficticious element a[N], which, if it existed, would follow the last element, a[N-1]. This is my own terminology.)
aep@ivan (Alex E. Pensky) (05/30/89)
In article <14353@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >[... Would] readers >of this newsgroup *PLEASE* read a book on *C* before posting here??!! >For some reason there has been a spate of very SILLY novice questions >here in the past couple of weeks. I for one am not bothered so much by the novice *questions* as the novice *answers*. If one (by his own admission) does not know C, then he should not try to answer questions on it, novice or otherwise. ----------------------------------------------------------------------------- Alex Pensky ...!{cwjcc,decvax,pyramid,uunet}!abvax!aep (216)646-5211 Allen-Bradley Company 747 Alpha Drive, Highland Heights, OH 44143 -----------------------------------------------------------------------------
awd@dbase.UUCP (Alastair Dallas) (06/03/89)
In article <728@abvax.UUCP>, aep@ivan (Alex E. Pensky) writes: > I for one am not bothered so much by the novice *questions* as the novice > *answers*. If one (by his own admission) does not know C, then he should > not try to answer questions on it, novice or otherwise. > Ah, the reverberations from one hasty posting...This is the most interesting thread I've read here in years. I followed proper netiquette; I refrained from responding when I first read a[33] and I've scanned all the replies to date. I have only the following comments to offer and then I'll be quiet: - I've long thought that Microsoft engineers were a tad cocky, all things considered. - "It's not the things you don't know that hurt you; it's the things you do know that ain't so."--Will Rogers, I believe. - As for moderating the net, I think the net approximates working in a big programming shop. There are gurus and there are novices. The gurus are impatient, gruff and usually right and the novices make a lot of noise and are almost always wrong. C'est la vie. (Translated for the net: <shrug>) Ok, back to the general confusion. /alastair/ Disclaimer: Just me, nobody else.