Patrick Dughi wrote:
> > > So, a pointer only takes up one box, and describes the address
> > > of other places in memory.
> >
> > Actually the amount of space a pointer takes up is
> > implementation-defined. I think that most modern implementations use 32
> > bit pointers but it could be more, or less. You best bet is to not
> > write code that depends on the size of a pointer.
> >
>
> This i know, that's why i said it was simplified. They're vauge
> ill-defined memory blocks. Not that this refers to all aspects, but size
> doesn't always matter. :)
>
The reason I pointed it out is because the last thing I want to see is
for a newbie to be given the wrong info, no matter how slight. You'd be
absolutely amazed how far they can stretch it and what kind of oddball
coding practices can result.
> > > Now, if we copy the word 'hello' into our s character array, we
> > > get this:
> > >
> > You get a buffer overrun because you allocated space for 5 characters
> > and "hello" actually uses 6 as follows...
> >
> > | 'h' | 'e' | 'l' | 'l' | 'o' | '\0' |
> >
> No. I didn't specifically declare I was copying strings - just 5
> characters. The one thing I did was keep it as simple as possible.
>
Well, again, it's what the newbie will make of it, by saying that you
can "copy the word 'hello'" into a 5 character array a lot of people
will think that you're saying that the following is legal...
char s[5];
strcpy(s, "hello");
Granted that's not what you're saying, but you have to consider what
others might read into it, and the above conclusion does not reauire a
great leap to attain.
> > > The thing is, the variable 's' can be used just like the pointer
> > > up above. It is a pointer after all.
> >
> > no, it's not. it can be used like a pointer in some ways, and in some
> > ways it cannot. For example you cannot change the value of s to make it
> > point to something else
>
> Actually you can. It's just bad form. I know i've done it on a
> few occasions when I didn't specifically declare my strings as constant.
> Least, i'm pretty sure you can. You can make anything point to anything.
> it sucks.
>
Hrmmm, I'm fairly ceartain that gcc will at the very least complain,
I'll have to test it. It will complain for ceartain if you compile with
the -Wall switch, and at any rate it's not a good programming practice.
> > > Just be careful though, if you
> > > pass that s[] variable to a function as a *s, you won't be able to use
> > > your array subscripting to access it. s[] can be converted to *s, but not
> > > the other way around.
> > >
> > It is perfectly valid to access a pointer as an array.
>
> Not in all circumstances. Try accessing a multidimensional array
> that you passed to a function as a single pointer in it's own context.
> It's better to never do this.
>
Your example is of a singledimensional array which can be accessed with
the [] convention just fine, but to give an example of how you can set
up a pointer and access it as a multidimensional array (note this is a
simplified example and leaves out some error checking)...
int i;
char **s = NULL;
s = malloc(sizeof(char *) * 5);
for (i = 0; i < 5; i++)
s[i] = malloc(sizeof(char) * 10);
strcpy(s[0], "zero");
strcpy(s[1], "one");
strcpy(s[2], "two");
strcpy(s[3], "three");
strcpy(s[4],"four");
printf("%c%c%c%c%c\n", s[0][0], s[1][1], s[2][2], s[3][3], s[4][1]);
The output of the above would be...
znoef
There are also other ways that you can mix arrays with pointers by
having arrays of pointers, pointers that have arrays mixed in, etc. The
things that you can do with this stuff is virtually limitless as long as
you can keep yourself within the rules and keep things documented and
structured well enough so as to avoid having the whole thing blow up in
your face.
> > > If you allocate memory for them though, it will still work.
> > > However, that pointer of 'to_victim[max_string_length]' which points to a
> > > max_string_length size of allocated memory will be blown away - it will
> > > quickly be set to point not to that memory, but the static string.
> >
> > Actually it won't even compile because the compiler won't let you change
> > the location where it points to.
> >
> *sniff* I'm pretty sure i've overwritten static strings all the
> time. Just not const static strings, at least not directly.
The memory is not const, just the pointer. you can overwrite the memory
that it points to but you can't change the pointer itself, it's pretty
similar to...
char const *s;
but not...
const char *s;
> Maybe it was
> just that hp compiler. Stupid piece of crap. Hm. Well, I know i've done
> it in assembler - but there, it was called 'optimization' :)
>
Well golly, if you can do it in assembler, why that makes all the
difference in the world. ;P
Oh well, sorry if I came out strong, it's just that I felt that a
correction needed to be made so as to prevent anyone from getting the
wrong conclusions and possibly drawing thier own, worse conclusions
based on those gotten from an incorrect post.
Regards, Peter
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT