Re: [C] strcat() question (ongoing)

From: thides (swatts_at_globalserve.net)
Date: 01/23/04 

Date: Fri, 23 Jan 2004 03:52:32 -0500

It took me a couple of days but here goes:

"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.58-035.0401201808160.32655@unix43.andrew.cmu.edu...
>
> On Tue, 20 Jan 2004, thides wrote:
> >
>
> My turn to be confusingly pedantic! ;-)
>
> > "Martijn Lievaart" <m@remove.this.part.rtij.nl> wrote...
> > > On Mon, 19 Jan 2004 21:25:07 -0500, thides wrote:
> > > >
> > > > That would be addresses cause each byte would fit into an address
> > > > unless we are only talking about one byte.
> > >
> > > I'm not following you here.
> >
> > I am trying to say that each address holds (stores) one byte of data.
>
> At the machine level, yes, basically (depending on your definition
> of "byte").

byte = 8 bits
bits = 0 or 1 (on/off; pos/neg ...)
What other definition is there?

> At the level of the C and C++ programming languages, no.

OK I think you mean address as in the byte and we dont have that in C/C++.
We can only "PUT" data in / or assign data to variables such as an int or
char and other various data types.

> An "address" in C [or C++, but I'll just leave you to infer that from
> now on] is just that -- a kind of a "street address" for an object
> (i.e., a blob of bytes) that tells you *where to find* that object.

Object -- a collection of variables and functions related to that particular
object.

> Addresses do not "store" anything, any more than 123 Main Street
> "stores" a house. 123 Main Street is an *address* that tells you
> where to *find* a house, yes, but it's just an address. The house,
> in C terms, is an "object," and it's not really "stored" anywhere
> either -- it just *is* somewhere.

Not stored until it is created or an instance of the object is created
(instantiated).

>When talking about C, I don't
> use the term "stored" in any technical sense.
>
> Example [tell me if it's too difficult for you]:
>
> struct FooStruct {
> int i;
> int j;
> } foo;

No I understand stuff like this now.

> Now, 'foo' is an object. So are 'foo.i' and 'foo.j'.

foo is an object? Object is a term reserved for classes so I thought. Even
though structures can behave similar to classes I never quite thought of
them as objects but I guess they are. foo.i and foo.j are objects of the
int data type. Oh an foo is an object of the FooStruct structure. Ok so
far.

> In the
> street-addresses analogy, 'foo' is like an apartment complex, and
> 'foo.i' and 'foo.j' are like individual apartments in that building.
> '&foo' is the address of 'foo'. In fact, in my opinion it's a
> little bit more than just an address, because '&foo' has a *type*;
> it's of type 'pointer to FooStruct'.

foo.i and foo.j are suites in the aptartment called foo. &foo -- address of
....
Address would be a location in memory.

> '&foo.i' is the address of 'foo.i', and has type 'pointer to int'.
> Now, here's the interesting thing: This is the *same address* as
> '&foo'! [The address of 'foo' is the same as the address of its
> first member, guaranteed.] But in neither case do we see any 'bytes'
> being involved on the C programming level: in one case, the thing
> we find at that address is 'foo' (a FooStruct), and in another case,
> we find 'foo.i' (an int).

Yes ok but C represents an int with 4 bytes of memory usage. A char has one
byte of memory usage. And a foo (FooStruct user data type) would have 8
bytes of memory usage.

>
> Maybe clearer: An 'address' tells you *where* to find something.
> Add a type to that address, and that will tell you *what* you will
> find. For example,
>

Ok. Yes for now.
Where = location
What = object

> void *p = &foo; /* p stores the address of 'foo' (and 'foo.i') */

Where = &foo
What = address

*p stores the value of foo.

>
> *(struct FooStruct *)p; /* Go find 'foo'! */

May we say find the value of foo... * is value of the variable.
Casting? Assuming p is a object of FooStruct. Isnt

*(struct FooStruct *)p == p;

If foo.i is delcared as a int. Then:

foo.i == (int) foo.i;

and

(struct FooStruct ) *p == *p;

> *(int *)p; /* Go find 'foo.i'! */
>
Stop!!... very interesting concept.

What about foo.j ?

*(int * ++) p; // I know this wont compile
*(int *)(p++) == foo.j // ?;

>
> > > At the machine level, there are no types. I should not have said
integer
> > > values, that was not correct. You have blobs of bytes that can
represent
> > > different things. It is up to the (assembly) programmer to apply the
> > > correct machine instructions to the different blobs.
> >
> > Right and the compiler does this for you in C/C++ depending on the data
> > type or instructions in the code.
>
> Right!
>
> > > Contrast this with C or C++, where every blob of bytes has an
assiociated
> > > type. The programmer can only circumvent it by using a cast. Thi is
> > > directly opposite to what happens at the machine level.
> >
> > So at the machine level there are no data types just address with
values.
>
> Right, except that 'address' at the machine level means something
> very subtly different [and so does 'value'], so here in this newsgroup
> you should always assume we're talking about the C [or C++] meaning
> of 'address', which is roughly "a description of where to find something."
>
>
> > > I know I understood pointers much better once I
> > > understood what happened on the machine level.
> >
> > I am hoping :)
>
> I agree with Martijn; however, I learned assembly language essentially
> unconnected with C, so I really never got confused between machine-level
> "pointers" and C pointers. If you just learn the machine-level stuff
> separately, and then think about how C does what it does, rather than
> trying to learn both at the same time, I think you'll do better.
>

I am only trying to relearn C/C++

> > > > Ok we have a *p that is in one address and it points to the first
> > > > address of the string which is a <space>
> > >
> > > No, it does not point to an address. The variable p stores [an]
> > > address that points to a string. The expression *p is a space,
> > > you've lost the pointer by dereferencing it.
> >
> > Ok got you. *p is the value.
> > But I thought p stores [an] address that points to the address
> > containing <space>
>
> Notice that I've fixed Martijn's typo, and yours ('n' for 'an').
> I hope you weren't confused about that 'n'!
> Again, it's a problem of terminology. First of all, you can't
> "point to" an address, any more than I can give you the street
> address of "123 Main Street." You 'point to' an 'object'; I *can*
> give you the street address of "Bob's house," which is the address
> "123 Main Street."

Yes terminology...
Where -- &p -- the address of the variable p
What -- *p store the address of p.
hmmmmm...

Ok I have done some futher reading as I have gone through this message. p
is the position in the string. So:

p +1 the position of 'W'. *(p + 1) would be the value of the position of
'W'.

> Secondly, it's not usual to say, "This address points to..." You
> should say, "This is the address of..." or "This pointer points to..."

Good good!!!

> or "This pointer object contains the address of..." It's just the
> way we say things in English.
> "*p is an expression that evaluates to <space>. p is a pointer

*p uses the value of operator... to access the value in the address pointed
to by the pointer p
ok so its not the value of operator but the "dereference" operator. -- Its
important I get this right.

p is a pointer? p is an object ok objects can point....

> object that contains the address of the first character in the
> string. p points to a character with the value <space>."
>
> > Like if p was stored in address 0001 and <space> was stored in
> > address 0003
> > 0001 would contain the address 0003 (the value <space>)...
>
> Yes, except that by mixing it up with assembly-language notation,
> you're... well... you're mixing it up. I would write the example
> using real-world "data types" and the street-address metaphor:
>

I am not all that good with metaphors but I'll give it a chance

> p is a house at 0001 Main Street.
>
> Taped to the refrigerator in p's kitchen is a note reading,
> "0003 Main Street."
>
> Taped to the microwave in the kitchen of the house at 0003
> Main Street is a note reading, "<space>."
>
> Now, replace "house" by "blob of bytes."
> Replace "Main Street" by "virtual memory space."
> Replace "note reading 0003 Main Street" with "pointer with the
> 'typeless integer' value 0003" -- that's what Martijn meant back
> there: 0003 is certainly an integer, but it's not supposed to
> be treated like one -- it's supposed to be a pointer. See how
> the "Main Street" analogy makes that more obvious?

Let me see if I got it... Main Street it the virtual memory space
I dont care about the blobs of bytes except that it is a house, or an int,
char or float.
0003 in this virual memory space has no C type but is in itself an integer
value not to be confused with the C-type int which is too an integer. 0003
infact only has meaning to the neighbourhood or operating system.

I think I am beginning to understand a little better.

> Replace "note reading <space>" with "the value 0x20, or whatever
> typeless integer value your computer uses to represent the

0x20 is an integer?

> space character."
> Replace "taped to the refrigerator" with "accessed as a pointer
> to char."
> Replace "taped to the microwave" with "accessed as a char."
>
> I hope experts will notice all the little quirks this analogy
> mimics; for example, suppose we write
>
> *(char*)&p;
>
> That means, "Take the address of p, and access the blob of bytes
> there as a char." So we go to 0001 Main Street and go into the
> house and look on the microwave. Now, p doesn't have anything
> taped to the microwave [or maybe it does, but it's nothing useful
> to us]. So we've made a mistake, and we'll probably get demons
> flying out of our noses because of it.
> [Yeesh, that was a mess. I should quit analogies.]
>
> > Oh, brainwave... p would contain address 0003 to the /0 (string
> > terminator) therefore the full string.
>
> I think you're wrong, but it's hard to tell what you mean.

p is the first position in the string.
*p is the value of that position to where the value is /0.

And we are thinking about it in the same way.

> p, the house at 0001 Main Street, has "0003 Main Street" taped
> to its refrigerator.
> Let's suppose we call 'puts(p)'. So, let's take this one step
> at a time and see how the string gets to our screen.
>
> Evaluate p. (We enter the house, access the refrigerator, and
> find the note. "0003 Main Street." Good.)
> Pass that value to 'puts'. (Call up the skywriter and tell him,
> "0003 Main Street" -- the value we got from 'p'. He'll know what
> to do.)
> 'puts' gets called. (The skywriter gets out his little rulebook
> and follows his directions. His directions say, "You have been
> given an address. Go to that house and look on the microwave.
> Write what you see. Go to the next house [in this case, 0004
> Main Street] and repeat the process. Stop only when you find a
> microwave with the null character taped to it.")
> (So the skywriter goes to 0003 Main Street, accesses the microwave,
> and writes <space>. He goes to 0004 Main Street and writes 'w'.
> Then 'o' and 'r' and 'l' and 'd', and then he gets to the house
> at 0009 Main Street and finds the null character taped to the
> microwave. So he stops.)
> (Then the skywriter telephones us back and says, "All done writing;
> it's your turn again." And on we go.)
>
> Notice that if we made a mistake and wrote
>
> puts(&p);
>
> the skywriter would have gone to 0001 Main Street (the address of
> p) instead of 0003 Main Street (the value p contains). And he
> would have found garbage on the microwave, and been really confused.
> That's called "undefined behavior," and it's bad.
>
> > > >> That is why we have
> > > >> high level languages, so we can deal with concepts instead of
bits).
> > > >
> > > > I dont think we store things in just bits in the address I think
> > > > it is in bytes.
>
> Bytes are just blobs of bits. Your statement is like you're
> saying that the English language doesn't use letters, it uses words.
> It's basically the same thing, from our point of view. Bits and bytes
> are just places to keep information.
>
> > I was thinking that an address is a byte. Maybe at machine language we
> > can store things in certain bits but in C/C++ the smallest data type is
> > a char which size is equal to a byte.
>
> Machine-level addresses are almost always multi-byte. In C and C++,
> pointers are almost always multi-byte objects, too. And you *can*
> store things in single bits in C and C++; look up "bit-fields."
> However, you cannot take the address of a bit-field, so it's not
> an object; kind of like you can keep things in different rooms in
> your house, but you can't write down the street address of your
> kitchen or your bedroom. :)
>
<clip>

No but I can read what is on the fridge.
Ya I get it I think. Mostly was terminology.
Thanks Arthur for all your time.

Steve

Relevant Pages

  • Re: call of variadic function
    ... arguments that should be passed to this function are of type int. ... You call foo with more arguments than are ... which is the standard way to access arguments of a variadic function ... Here the else clause of my sentence specifies one of the numerous non- ...
    (comp.lang.c)
  • Re: RISC OS modules with stock gcc?
    ... int bar; ... DCD &ff000004 ... IMPORT bar ... EXPORT foo ...
    (comp.sys.acorn.programmer)
  • Re: call of variadic function
    ... arguments that should be passed to this function are of type int. ... call and the definition of function foo itself does NOT produce any ... which is the standard way to access arguments of a variadic function ... Here the else clause of my sentence specifies one of the numerous non- ...
    (comp.lang.c)
  • Re: Dive Into Java?
    ... So it acts as a casting operator. ... class Foo { ... int _arg; ... Foo(int arg) { ...
    (comp.lang.python)