how can i get the address of buf which defined as char buf[] = "abcde";

[baumann.Pan]

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);
thanks

baumann@pan

[Artie Gold]

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);
thanks

baumann@pan

1) There is no such function as strsep() in standard C.
2) To use it, you'd have to do something like:

char buf[] = "abcde";
char *p = buf;
char *q = strsep(&p, "c");

HTH,
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

[pete]

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);

The address of buf is &buf.

strsep(&buf, pointer to token);

The pointer to the string is buf,

strsep(buf, pointer to token);

.... depending on what you really want.

--
pete

[Artie Gold]

pete wrote:

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);

The address of buf is &buf.

strsep(&buf, pointer to token);

That's true -- but useless, as `buf' is immutable.
The pointer to the string is buf,

strsep(buf, pointer to token);

... depending on what you really want.

[The signature is:

char *strsep(char **stringp, const char *delim);

--hence the problem.]

--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

[pete]

Artie Gold wrote:

pete wrote:

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);

The address of buf is &buf.

strsep(&buf, pointer to token);

That's true -- but useless, as `buf' is immutable.

What difference does it make that buf is immutable?

--
pete

[baumann]

pete wrote:

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);
The address of buf is &buf.

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

buf is the pointer to the location of the string "abcde".

it seems if buf defined as above, there is no way to acquire the
address of buf itself.

it needs the 3rd variable for the purpose?

strsep(&buf, pointer to token);

The pointer to the string is buf,

strsep(buf, pointer to token);

... depending on what you really want.

--
pete

[baumann]

Artie Gold wrote:

pete wrote:

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);

The address of buf is &buf.

strsep(&buf, pointer to token);

That's true -- but useless, as `buf' is immutable.

buf is mutable, if buf is defined as char * buf ="abcde"; then you are
right;

The pointer to the string is buf,

strsep(buf, pointer to token);

... depending on what you really want.

[The signature is:

char *strsep(char **stringp, const char *delim);

--hence the problem.]

yes it is defined in linux conforms to bsd4. not conforms to ansi C.
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

[pete]

pete wrote:

Artie Gold wrote:

pete wrote:

ba*********@gmail.com wrote:

>hi all,
>
>i want to get the address of buf, which defined as
>
>char buf[] = "abcde";
>
>so can call
>strsep(address of buf, pointer to token);
The address of buf is &buf.

strsep(&buf, pointer to token);

That's true -- but useless, as `buf' is immutable.

What difference does it make that buf is immutable?

That's OK.
I googled strsep, so now I know what it is.

--
pete

[pete]

baumann@pan wrote:

pete wrote:

ba*********@gmail.com wrote:

hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);

The address of buf is &buf.

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

What do you think &buf is?

--
pete

[baumann]

pete wrote:

baumann@pan wrote:

pete wrote:

ba*********@gmail.com wrote:
>
> hi all,
>
> i want to get the address of buf, which defined as
>
> char buf[] = "abcde";
>
> so can call
> strsep(address of buf, pointer to token);

The address of buf is &buf.
no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

no, buf ,&buf and &buf[0] is the address of "abcde", not address of
variable buf. i think we can not get the address of buf itself.
What do you think &buf is?

--
pete

[baumann]

pete wrote:

baumann@pan wrote:

pete wrote:

ba*********@gmail.com wrote:
>
> hi all,
>
> i want to get the address of buf, which defined as
>
> char buf[] = "abcde";
>
> so can call
> strsep(address of buf, pointer to token);

The address of buf is &buf.
no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

assume "abcde" starts at the address of 0 and ends at address 5;

then buf = 0; &buf = 0 too.

we don't know what's address of buf itself.

What do you think &buf is?

--
pete

[pete]

baumann@pan wrote:

pete wrote:

baumann@pan wrote:

pete wrote:
> ba*********@gmail.com wrote:
> >
> > hi all,
> >
> > i want to get the address of buf, which defined as
> >
> > char buf[] = "abcde";
> >
> > so can call
> > strsep(address of buf, pointer to token);
>
> The address of buf is &buf.

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

no

You don't know what you're talking about.

--
pete

[pete]

baumann@pan wrote:

pete wrote:

baumann@pan wrote:

pete wrote:
> ba*********@gmail.com wrote:
> >
> > hi all,
> >
> > i want to get the address of buf, which defined as
> >
> > char buf[] = "abcde";
> >
> > so can call
> > strsep(address of buf, pointer to token);
>
> The address of buf is &buf.

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.
Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

assume "abcde" starts at the address of 0 and ends at address 5;
then buf = 0; &buf = 0 too.

If that were true then (buf == "abcde") would be true also,
but it isn't.
we don't know what's address of buf itself.

One of us does.

What do you think &buf is?

Seriously, what do you think (&buf) means?

Get your compiler into conforming
mode and compile the following program.
What diagnostic message does your compiler have to give you?

int main(void)
{
char buf[] = "abcde";

return &buf - buf;
}
--
pete

[Chris Torek]

>> ba*********@gmail.com wrote:

i want to get the address of buf, which defined as
char buf[] = "abcde";
[so that I can call the nonstandard strsep() function,

which we see elsethread requires the address of an
object of type "char *"].
pete wrote:

The address of buf is &buf.

This is of course correct. See http://web.torek.net/torek/c/pa.html
for more on the subject. Unfortunately, it is also useless in this
case. (Indeed, it is rarely useful at all.)

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:no, (&buf == buf )&&(buf == &buf[0]) is TRUE.
No: &buf has type "char (*)[6]", because "buf" is an object of
type "array 6 of char". In the above expression, the second
occurrence of "buf" undergoes the transform dictated by The Rule,
and becomes a value of type "char *". A value of type
"char (*)[6]" is not compatible with a value of type "char *",
and a diagnostic is required (after which a compiler can do
as it pleases, including cease compiling forevermore :-) ).
it seems if buf defined as above, there is no way to acquire the
address of buf itself.
Again, this is wrong: you *can* get "the address of buf itself",
but what you get is the address of the entire array. This is not
what you need, because the strsep() function demands the address
of an object of type "char *".
it needs the 3rd variable for the purpose?

This is no doubt the best way.

The strsep() function demands the address of an object of
type "char *".

In order to satisfy the strsep() function -- which, let me repeat,
demands the address of an object of type "char *" -- you must
create an object of type "char *". Once you have created an
object of type "char *", you have an object of type "char *"
whose address you can take, so as to give it to strsep(), which
demands the address of an object of type "char *".

Whenever any function demands the address of an object of type T
-- for any type T -- you must create an object of type T. There
are only two ways to create objects: you can either declare a
variable[%], or you can call malloc(). There are lots of ways to
create values in C, but only two ways to create objects, so use
one of those two. You only need to use malloc() in some special
cases, and until those cases occur, your best bet will be to declare
variables.
-----
[%] A formal parameter to a function also creates an object: in
void f(char *p) { ... }
p acts like a local variable. Some might argue that it is
not a "regular variable", but in most ways, it does qualify
as a regular variable, and I consider these to be ordinary
local variable declarations.
-----

There are many C functions that require the address of an object.
Fortunately, C makes it easy to compute the address of an object,
given a variable of the appropriate type: just write "&var", where
var is a variable of type T, to obtain a value of type "pointer to
T", pointing to the variable in question.

There are also many C funtions that require the address of the
first element of an array of objects, and C has a peculiar rule by
which the name of an array of N objects of type T turns into a
value of type "pointer to T", pointing to the first element of that
array. This rule is arbitrary, and is a special case, no matter
how common it winds up being; one must not allow the fact that
virtually every C program uses this funny rule dozens, hundreds,
thousands, or even millions of times, to distract from its
special-case-ness and mislead one into thinking that it is more
general than it is. Thus, while you need not do anything special
to call (e.g.) the fgets() function to fill in an array, you *do*
need to do something special to obtain the "char *" object that
strsep() demands, to pass the address of that object to strsep():

char buf[] = "some initial contents";
char *bp, *result;
...
buf = &buf[0]; /* or: char *bp = buf; */
result = strsep(&bp, delim);

The "temporary variable" bp really *is* required. (Well, you
could use malloc() instead, but that would be kind of silly.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Artie Gold]

baumann@pan wrote:

Artie Gold wrote:

pete wrote:

ba*********@gmail.com wrote:
hi all,

i want to get the address of buf, which defined as

char buf[] = "abcde";

so can call
strsep(address of buf, pointer to token);
The address of buf is &buf.

strsep(&buf, pointer to token);
That's true -- but useless, as `buf' is immutable.

buf is mutable, if buf is defined as char * buf ="abcde"; then you are
right;

No, the *contents* of buf are mutable, `buf' itself is not.

The pointer to the string is buf,

strsep(buf, pointer to token);

... depending on what you really want.

[The signature is:

char *strsep(char **stringp, const char *delim);

--hence the problem.]

--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

[baumann]

&buf[0] = buf = &buf is __TRUE__ only if we don't consider the data
type, but the value only.

we can cast the three to void * , a pointer.

(void*)&buf[0] has the same value of (void*) &buf and same value of
(void*)buf.

you all should notice

char * buf2 = (char*)mallic(100);

in this case we can get the address of buf2 by &buf2;

but not &buf;

buf is same as buf2 which pointer to the location where the object
lies.


Chris Torek wrote:

ba*********@gmail.com wrote:
i want to get the address of buf, which defined as
char buf[] = "abcde";
[so that I can call the nonstandard strsep() function,

which we see elsethread requires the address of an
object of type "char *"].

pete wrote:

The address of buf is &buf.

This is of course correct. See http://web.torek.net/torek/c/pa.html
for more on the subject. Unfortunately, it is also useless in this
case. (Indeed, it is rarely useful at all.)

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

No: &buf has type "char (*)[6]", because "buf" is an object of
type "array 6 of char". In the above expression, the second
occurrence of "buf" undergoes the transform dictated by The Rule,
and becomes a value of type "char *". A value of type
"char (*)[6]" is not compatible with a value of type "char *",
and a diagnostic is required (after which a compiler can do
as it pleases, including cease compiling forevermore :-) ).

it seems if buf defined as above, there is no way to acquire the
address of buf itself.

Again, this is wrong: you *can* get "the address of buf itself",
but what you get is the address of the entire array. This is not
what you need, because the strsep() function demands the address
of an object of type "char *".

it needs the 3rd variable for the purpose?

This is no doubt the best way.

The strsep() function demands the address of an object of
type "char *".

In order to satisfy the strsep() function -- which, let me repeat,
demands the address of an object of type "char *" -- you must
create an object of type "char *". Once you have created an
object of type "char *", you have an object of type "char *"
whose address you can take, so as to give it to strsep(), which
demands the address of an object of type "char *".

Whenever any function demands the address of an object of type T
-- for any type T -- you must create an object of type T. There
are only two ways to create objects: you can either declare a
variable[%], or you can call malloc(). There are lots of ways to
create values in C, but only two ways to create objects, so use
one of those two. You only need to use malloc() in some special
cases, and until those cases occur, your best bet will be to declare
variables.
-----
[%] A formal parameter to a function also creates an object: in
void f(char *p) { ... }
p acts like a local variable. Some might argue that it is
not a "regular variable", but in most ways, it does qualify
as a regular variable, and I consider these to be ordinary
local variable declarations.
-----

There are many C functions that require the address of an object.
Fortunately, C makes it easy to compute the address of an object,
given a variable of the appropriate type: just write "&var", where
var is a variable of type T, to obtain a value of type "pointer to
T", pointing to the variable in question.

There are also many C funtions that require the address of the
first element of an array of objects, and C has a peculiar rule by
which the name of an array of N objects of type T turns into a
value of type "pointer to T", pointing to the first element of that
array. This rule is arbitrary, and is a special case, no matter
how common it winds up being; one must not allow the fact that
virtually every C program uses this funny rule dozens, hundreds,
thousands, or even millions of times, to distract from its
special-case-ness and mislead one into thinking that it is more
general than it is. Thus, while you need not do anything special
to call (e.g.) the fgets() function to fill in an array, you *do*
need to do something special to obtain the "char *" object that
strsep() demands, to pass the address of that object to strsep():

char buf[] = "some initial contents";
char *bp, *result;
...
buf = &buf[0]; /* or: char *bp = buf; */
result = strsep(&bp, delim);

The "temporary variable" bp really *is* required. (Well, you
could use malloc() instead, but that would be kind of silly.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[baumann]

Chris Torek wrote:

ba*********@gmail.com wrote:
i want to get the address of buf, which defined as
char buf[] = "abcde";
[so that I can call the nonstandard strsep() function,

which we see elsethread requires the address of an
object of type "char *"].

pete wrote:

The address of buf is &buf.

This is of course correct. See http://web.torek.net/torek/c/pa.html
for more on the subject. Unfortunately, it is also useless in this
case. (Indeed, it is rarely useful at all.)

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

No: &buf has type "char (*)[6]", because "buf" is an object of
type "array 6 of char". In the above expression, the second
occurrence of "buf" undergoes the transform dictated by The Rule,
and becomes a value of type "char *". A value of type
"char (*)[6]" is not compatible with a value of type "char *",
and a diagnostic is required (after which a compiler can do
as it pleases, including cease compiling forevermore :-) ).

i mean they are equal by value not by their data type.

it seems if buf defined as above, there is no way to acquire the
address of buf itself.
Again, this is wrong: you *can* get "the address of buf itself",
but what you get is the address of the entire array. This is not

the address of entire array is the address of the object. and in this
it's also address of that variable.


what you need, because the strsep() function demands the address
of an object of type "char *".

it needs the 3rd variable for the purpose?

This is no doubt the best way.

The strsep() function demands the address of an object of
type "char *".

In order to satisfy the strsep() function -- which, let me repeat,
demands the address of an object of type "char *" -- you must
create an object of type "char *". Once you have created an
object of type "char *", you have an object of type "char *"
whose address you can take, so as to give it to strsep(), which
demands the address of an object of type "char *".

Whenever any function demands the address of an object of type T
-- for any type T -- you must create an object of type T. There
are only two ways to create objects: you can either declare a
variable[%], or you can call malloc(). There are lots of ways to
create values in C, but only two ways to create objects, so use
one of those two. You only need to use malloc() in some special
cases, and until those cases occur, your best bet will be to declare
variables.
-----
[%] A formal parameter to a function also creates an object: in
void f(char *p) { ... }
p acts like a local variable. Some might argue that it is
not a "regular variable", but in most ways, it does qualify
as a regular variable, and I consider these to be ordinary
local variable declarations.
-----

There are many C functions that require the address of an object.
Fortunately, C makes it easy to compute the address of an object,
given a variable of the appropriate type: just write "&var", where
var is a variable of type T, to obtain a value of type "pointer to
T", pointing to the variable in question.

There are also many C funtions that require the address of the
first element of an array of objects, and C has a peculiar rule by
which the name of an array of N objects of type T turns into a
value of type "pointer to T", pointing to the first element of that
array. This rule is arbitrary, and is a special case, no matter
how common it winds up being; one must not allow the fact that
virtually every C program uses this funny rule dozens, hundreds,
thousands, or even millions of times, to distract from its
special-case-ness and mislead one into thinking that it is more
general than it is. Thus, while you need not do anything special
to call (e.g.) the fgets() function to fill in an array, you *do*
need to do something special to obtain the "char *" object that
strsep() demands, to pass the address of that object to strsep():

char buf[] = "some initial contents";
char *bp, *result;
...
buf = &buf[0]; /* or: char *bp = buf; */
result = strsep(&bp, delim);

The "temporary variable" bp really *is* required. (Well, you
could use malloc() instead, but that would be kind of silly.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Chris Torek]

[Given:
char buf[N];
for some suitable constant N]

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

&buf[0] = buf = &buf is __TRUE__ only if we don't consider the data
type, but the value only.
If you "don't consider the data type", then 3 == 3.14, and 3 != 3.14.
we can cast the three to void * , a pointer.
We can cast the 3.14 to "long", and then 3 == 3.14.

Or, we can convert (via cast or via ordinary cast-free conversion)
the 3 to "double", and then 3 != 3.14.

This shows that:

IF YOU IGNORE THE TYPE, YOU GET THE WRONG ANSWER.

Never, ever, ignore the type. C is *not* a typeless language!
(void*)&buf[0] has the same value of (void*) &buf
Probably, and perhaps even provably. (It would be hard, and perhaps
impossible, to get the rest of the C Standard's requirements right
while also doing something weird with array addressing that would,
say, encode the size of the array in the result of (void *)&buf,
so that it differs from (void *)&buf[0].) But this just means
that:

If you take value A, of type T1, and value B, of type T2,
and convert both to new values of type T3, the new values
compare equal.

This is also true for (int)3 and (double)3.14. Value A has type
int, value B has type double, and we convert both to new values of
type "char", "short", "int", or "long" -- we have lots of choices
for type T3 -- and they will compare equal.
and same value of (void*)buf.
Yes; this falls out from The Rule about pointers and arrays in C
(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.
Hence:

&buf[0] == buf

is always true -- no casts are required.
you all should notice

char * buf2 = (char*)mallic(100);

in this case we can get the address of buf2 by &buf2;
Yes. "buf2" is an object of type "pointer to char", so &buf2 is
a value of type "pointer to (pointer to char)", pointing to the
object named buf2.
but not &buf;
Here, "buf" is an object of type "array N of T", so &buf is a
value of type "pointer to (array N of T)", pointing to the
(entire) object name buf.
buf is same as buf2 which pointer to the location where the object
lies.

No! Learning this is crucial to becoming a fully competent C
programmer: buf is *not* "the same as" buf2. The object named
"buf" is an array. The object named "buf2" is not an array.
The rules for computing their values therefore differ. The
results of &buf and &buf2 differ. The results of sizeof(buf)
and sizeof(buf2) differ.

The thing that is peculiar is that the *different* rules for
computing the "value" of buf and the value of buf2 can cause
these two different things to have the same value! That is,
after:

char buf[N]; /* for some suitable N */
char *buf2;

buf2 = buf;

the values equal, but the entities differ. The values are equal
because the "value" of an array object is that produced by The Rule
about arrays and pointers in C.

printf("buf = %p, buf2 = %p; but sizeof(buf) = %lu, sizeof(buf2) = %lu\n",
(void *)buf, (void *)buf2,
(unsigned long)sizeof buf, (unsigned long)sizeof buf2);

The different "sizeof" results proves that the two are not identical.
This is why The Rule says: "in a value context". Some operations
-- in particular, unary "&" and sizeof -- are not "value contexts".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Mark McIntyre]

On 5 Jun 2005 22:02:39 -0700, in comp.lang.c , "baumann@pan"
<ba*********@gmail.com> wrote:

Chris Torek wrote:

Again, this is wrong: you *can* get "the address of buf itself",
but what you get is the address of the entire array. This is not

the address of entire array is the address of the object. and in this
it's also address of that variable.

Its worth pointing out to you that Chris Torek is one of THE top gurus
round here. You can almost guarantee he's right, and if he were wrong,
all the other gurus would point it out.

So.... if you're disagreeing with him its almost axiomatic that
you're mistaken.....

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[pete]

Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.

I don't think that what you mean by "value" "in quotes"
is very close to the meaning of value.
That an array should have the same "value" regardless
of it's contents or whether or not it's been initialized,
is too different from the meaning of value, for me.
The value of an object should depend on it's contents.

In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.
The initializing elements are derived from the contents of "ab",
or as I think of it, from the value of the array "ab".

--
pete

[Chris Torek]

>Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.

In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:I don't think that what you mean by "value" "in quotes"
is very close to the meaning of value.
Indeed, this is why it is in quotes. The value of an ordinary
object is the value stored in the object. The "value" of an
array should therefore be the collection of all the values of
all the elements of that array.

This would require that C have "array rvalues", but with one weird
case (functions that return "struct"s that contain arrays), it does
not. Instead, it has The Rule.
In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.

Actually, the thing on the right is merely a special syntactic
construct, which the standard calls a "string literal". It does
*become* an array, but not as an expression, because initializers
for arrays of character types are another special case. (See
§6.1.4, paragraph 5, §6.2.2.1 para 3, and §6.5.8 paragraphs 17 and
18, at least in my C99 draft.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Jens.Toerring]

pete <pf*****@mindspring.com> wrote:

Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.

I don't think that what you mean by "value" "in quotes"
is very close to the meaning of value.
Take 'value' when put in quotes to mean "in a context where the
value of something is taken that doesn't really has a value".
Saying that an array has a value doesn't really make sense when
you think about it. But in C you can use an array in places where
a value is expected (like when you use an array as a function ar-
gument where the function expects a pointer or when you have a
pointer on the left hand side and an unadorned array on the right
of an assignment) anyway and then The Rule kicks in and the arrays
"value" is taken to mean the value of the pointer to it's first
element.
That an array should have the same "value" regardless
of it's contents or whether or not it's been initialized,
is too different from the meaning of value, for me.
The value of an object should depend on it's contents.
Well, define what 'value' of an array should mean. An array has no
single 'value' (except maybe for the degenerate case of an array
with only a single element). The guys that invented C decided to
pick the address of the first element as meaning the 'value' of the
array.
In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.
Definitions are extra tricky. And on the left hand side you actu-
ally don't have an array here but a pointer to a literal string.
The special magic rules for the initialization of char arrays allow
this and make sure that a) the array on the left hand side will
be made large enough to hold a copy of the literal string and
b) what the pointer to literal string points to gets copied to
the array. And such an assignment doesn't work when you try it
somewere else than an initialization, e.g.

char array[ 3 ];
array = "ab";

is a syntax error.
The initializing elements are derived from the contents of "ab",
or as I think of it, from the value of the array "ab".

Then you assign a different meaning to "value of an array" than it
has in C by definition. If things would work line this, then

int a[ 3 ] = { 1, 2, 3 };
int b[ 3 ];
b = a;

should probably be legal and would assign the values of the elements
of array 'a' to the ones of array 'b'. But I guess you will have pro-
blems getting your C compiler to create code for you that does that.
To make things more interesting, something like this works with e.g.
structures, even though you also can't say that a structure has a
value in the normal sense. So structures don't "decay" to a pointer
to the structure (or it's first member) in value context while arrays
do. C can sometimes be a little strange, admittedly;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[baumann]

Chris Torek wrote:

[Given:
char buf[N];
for some suitable constant N]

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

&buf[0] = buf = &buf is __TRUE__ only if we don't consider the data
type, but the value only.
If you "don't consider the data type", then 3 == 3.14, and 3 != 3.14.

we can cast the three to void * , a pointer.

We can cast the 3.14 to "long", and then 3 == 3.14.

Or, we can convert (via cast or via ordinary cast-free conversion)
the 3 to "double", and then 3 != 3.14.

This shows that:

IF YOU IGNORE THE TYPE, YOU GET THE WRONG ANSWER.

Never, ever, ignore the type. C is *not* a typeless language!

(void*)&buf[0] has the same value of (void*) &buf

Probably, and perhaps even provably. (It would be hard, and perhaps
impossible, to get the rest of the C Standard's requirements right
while also doing something weird with array addressing that would,
say, encode the size of the array in the result of (void *)&buf,
so that it differs from (void *)&buf[0].) But this just means
that:

If you take value A, of type T1, and value B, of type T2,
and convert both to new values of type T3, the new values
compare equal.

This is also true for (int)3 and (double)3.14. Value A has type
int, value B has type double, and we convert both to new values of
type "char", "short", "int", or "long" -- we have lots of choices
for type T3 -- and they will compare equal.

and same value of (void*)buf.

Yes; this falls out from The Rule about pointers and arrays in C
(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.
Hence:

&buf[0] == buf

is always true -- no casts are required.

you all should notice

char * buf2 = (char*)mallic(100);

in this case we can get the address of buf2 by &buf2;

Yes. "buf2" is an object of type "pointer to char", so &buf2 is
a value of type "pointer to (pointer to char)", pointing to the
object named buf2.

but not &buf;

Here, "buf" is an object of type "array N of T", so &buf is a
value of type "pointer to (array N of T)", pointing to the
(entire) object name buf.

buf is same as buf2 which pointer to the location where the object
lies.

No! Learning this is crucial to becoming a fully competent C
programmer: buf is *not* "the same as" buf2. The object named
"buf" is an array. The object named "buf2" is not an array.
The rules for computing their values therefore differ. The
results of &buf and &buf2 differ. The results of sizeof(buf)
and sizeof(buf2) differ.

the result *buf and *buf2 is the same, but not *buf++ which i think
buf is constant , can not be modified , and *buf2++.
i think &buf is the address of buf according to the fact,

if we define a local variable in a func body.

most compiler generate asm code like

push ebp
mov ebp, esp
sub esp, NNN

then the buf 's value would in the range from ebp-n to ebp,this also is
the address of buf.

The thing that is peculiar is that the *different* rules for
computing the "value" of buf and the value of buf2 can cause
these two different things to have the same value! That is,
after:

char buf[N]; /* for some suitable N */
char *buf2;

buf2 = buf;

the values equal, but the entities differ. The values are equal
because the "value" of an array object is that produced by The Rule
about arrays and pointers in C.

printf("buf = %p, buf2 = %p; but sizeof(buf) = %lu, sizeof(buf2) = %lu\n",
(void *)buf, (void *)buf2,
(unsigned long)sizeof buf, (unsigned long)sizeof buf2);

The different "sizeof" results proves that the two are not identical.
This is why The Rule says: "in a value context". Some operations
-- in particular, unary "&" and sizeof -- are not "value contexts".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

Je***********@physik.fu-berlin.de writes:

pete <pf*****@mindspring.com> wrote:

Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.

I don't think that what you mean by "value" "in quotes"
is very close to the meaning of value.

Take 'value' when put in quotes to mean "in a context where the
value of something is taken that doesn't really has a value".
Saying that an array has a value doesn't really make sense when
you think about it.

I disagree. A struct has a composite value, consisting of the values
of its members. An array has a composite value, consisting of the
values of its elements. I've used languages where arrays values can
be assigned and even compared using the same syntax that's used for
scalars. It's really no more strange than saying than a complex
number has a value.

Of course, C rarely lets you do anything with an array "value", but it
still exists.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[baumann]

Chris Torek wrote:

[Given:
char buf[N];
for some suitable constant N]

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

&buf[0] = buf = &buf is __TRUE__ only if we don't consider the data
type, but the value only.
If you "don't consider the data type", then 3 == 3.14, and 3 != 3.14.

&buf is a pointer to something,

buf in this case can also be considered as pointer , right?

since they are both pointer, they will occupy 32bits in 32-bit cpu.

so i can compare the 2 32-bit values.

no 3 == 3.14 would occur.
#include <string.h>
#include <stdio.h>
int main(void)
{
char buf[] = "abcdefghijklmn";
char *token = "l";
char *text = buf;
char * d = (char*)malloc(100);

char * p = strsep((char**)&text,token);
printf("d:%p\t &d:%p\n",d, &d);
printf("buf:%p,&buf:%p,&buf[0]:%p\n", buf, &buf,&buf[0]);
printf("p:%s\n",p);
free(d);
return 0;
}

compiled in redhat 9, outputs

d:0x80496c8 &d:0xbfffee04
buf:0xbfffee10,&buf:0xbfffee10,&buf[0]:0xbfffee10
p:abcdefghijk
you see buf &buf[0] and &buf have the same value:0xbfffee10.

so i mean the three in equal by value, what do you call this situation?

array is strange or exactly special thing ,i think, few variable of
other type and the address of them could be same ( i think it is mostly
because other type variable could not be taken as pointer , while
variable[] can be, so the comparision between the other type variable
and their address would have no meaning).

we can cast the three to void * , a pointer.

We can cast the 3.14 to "long", and then 3 == 3.14.

Or, we can convert (via cast or via ordinary cast-free conversion)
the 3 to "double", and then 3 != 3.14.

This shows that:

IF YOU IGNORE THE TYPE, YOU GET THE WRONG ANSWER.

Never, ever, ignore the type. C is *not* a typeless language!

(void*)&buf[0] has the same value of (void*) &buf

Probably, and perhaps even provably. (It would be hard, and perhaps
impossible, to get the rest of the C Standard's requirements right
while also doing something weird with array addressing that would,
say, encode the size of the array in the result of (void *)&buf,
so that it differs from (void *)&buf[0].) But this just means
that:

If you take value A, of type T1, and value B, of type T2,
and convert both to new values of type T3, the new values
compare equal.

This is also true for (int)3 and (double)3.14. Value A has type
int, value B has type double, and we convert both to new values of
type "char", "short", "int", or "long" -- we have lots of choices
for type T3 -- and they will compare equal.

and same value of (void*)buf.

Yes; this falls out from The Rule about pointers and arrays in C
(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.
Hence:

&buf[0] == buf

is always true -- no casts are required.

you all should notice

char * buf2 = (char*)mallic(100);

in this case we can get the address of buf2 by &buf2;

Yes. "buf2" is an object of type "pointer to char", so &buf2 is
a value of type "pointer to (pointer to char)", pointing to the
object named buf2.

but not &buf;

Here, "buf" is an object of type "array N of T", so &buf is a
value of type "pointer to (array N of T)", pointing to the
(entire) object name buf.

buf is same as buf2 which pointer to the location where the object
lies.

No! Learning this is crucial to becoming a fully competent C
programmer: buf is *not* "the same as" buf2. The object named
"buf" is an array. The object named "buf2" is not an array.
The rules for computing their values therefore differ. The
results of &buf and &buf2 differ. The results of sizeof(buf)
and sizeof(buf2) differ.

The thing that is peculiar is that the *different* rules for
computing the "value" of buf and the value of buf2 can cause
these two different things to have the same value! That is,
after:

char buf[N]; /* for some suitable N */
char *buf2;

buf2 = buf;

the values equal, but the entities differ. The values are equal
because the "value" of an array object is that produced by The Rule
about arrays and pointers in C.

printf("buf = %p, buf2 = %p; but sizeof(buf) = %lu, sizeof(buf2) = %lu\n",
(void *)buf, (void *)buf2,
(unsigned long)sizeof buf, (unsigned long)sizeof buf2);

The different "sizeof" results proves that the two are not identical.
This is why The Rule says: "in a value context". Some operations
-- in particular, unary "&" and sizeof -- are not "value contexts".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Je***********@physik.fu-berlin.de wrote:

pete <pf*****@mindspring.com> wrote:

Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.

In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.

Definitions are extra tricky. And on the left hand side you
actually don't have an array here but a pointer to a literal string.
The special magic rules for the initialization of char arrays allow
this and make sure that a) the array on the left hand side will
be made large enough to hold a copy of the literal string and
b) what the pointer to literal string points to gets copied to
the array. And such an assignment doesn't work when you try it
somewere else than an initialization, e.g.

There is no pointer there.

N869
6.3.2.1 Lvalues and function designators

[#3] Except when

it is the operand of the sizeof operator or
the unary & operator,

or is a string literal used to initialize an array,

an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

--
pete

[baumann]

pete wrote:

Je***********@physik.fu-berlin.de wrote:

pete <pf*****@mindspring.com> wrote:

Chris Torek wrote:

> (<http://web.torek.net/torek/c/expr.html#therule>). The "value"
> of an array object is a pointer to the array's first element. In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.

Definitions are extra tricky. And on the left hand side you
actually don't have an array here but a pointer to a literal string.
The special magic rules for the initialization of char arrays allow
this and make sure that a) the array on the left hand side will
be made large enough to hold a copy of the literal string and
b) what the pointer to literal string points to gets copied to
the array. And such an assignment doesn't work when you try it
somewere else than an initialization, e.g.

There is no pointer there.

N869
6.3.2.1 Lvalues and function designators

[#3] Except when

it is the operand of the sizeof operator or

"operand of the sizeof"???

the unary & operator,

or is a string literal used to initialize an array,

an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

--
pete

[pete]

Chris Torek wrote:

Chris Torek wrote:

(<http://web.torek.net/torek/c/expr.html#therule>). The "value"
of an array object is a pointer to the array's first element.
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:

In this kind of an array definition:
char array[] = "ab";
the expressions on both sides of the equal sign are array types.

Actually, the thing on the right is merely a special syntactic
construct, which the standard calls a "string literal". It does
*become* an array, but not as an expression, because initializers
for arrays of character types are another special case. (See
§6.1.4, paragraph 5, §6.2.2.1 para 3, and §6.5.8 paragraphs 17 and
18, at least in my C99 draft.)

I can't find those numbers in N869.
Is there any text I can search for?

This part shown here, makes an exception for an
expression that has type ``array of type'',
refering to a string literal in an initialization.

N869
6.3.2.1 Lvalues and function designators

[#3] Except when

it is the operand of the sizeof operator or
the unary & operator,

or is a string literal used to initialize an array,

an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

--
pete

[pete]

baumann@pan wrote:

pete wrote:

Je***********@physik.fu-berlin.de wrote:

pete <pf*****@mindspring.com> wrote:
> Chris Torek wrote:

>> (<http://web.torek.net/torek/c/expr.html#therule>). The "value"
>> of an array object is a pointer to the array's first element.

> In this kind of an array definition:
> char array[] = "ab";
> the expressions on both sides of the equal sign are array types.

Definitions are extra tricky. And on the left hand side you
actually don't have an array here
but a pointer to a literal string.
The special magic rules for the initialization
of char arrays allow
this and make sure that a) the array on the left hand side will
be made large enough to hold a copy of the literal string and
b) what the pointer to literal string points to gets copied to
the array. And such an assignment doesn't work when you try it
somewere else than an initialization, e.g.

There is no pointer there.

N869
6.3.2.1 Lvalues and function designators

[#3] Except when

it is the operand of the sizeof operator or

"operand of the sizeof"???

the unary & operator,

or is a string literal used to initialize an array,

an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

((sizeof "abcdef") == 7) is true
--
pete

[baumann]

what's N869?

and

when sizeof does not need () and when sizeof need ()? thanks
pete wrote:

baumann@pan wrote:

pete wrote:

Je***********@physik.fu-berlin.de wrote:
>
> pete <pf*****@mindspring.com> wrote:
> > Chris Torek wrote:
>
> >> (<http://web.torek.net/torek/c/expr.html#therule>). The "value"
> >> of an array object is a pointer to the array's first element.

> > In this kind of an array definition:
> > char array[] = "ab";
> > the expressions on both sides of the equal sign are array types.
>
> Definitions are extra tricky. And on the left hand side you
> actually don't have an array here
> but a pointer to a literal string.
> The special magic rules for the initialization
> of char arrays allow
> this and make sure that a) the array on the left hand side will
> be made large enough to hold a copy of the literal string and
> b) what the pointer to literal string points to gets copied to
> the array. And such an assignment doesn't work when you try it
> somewere else than an initialization, e.g.

There is no pointer there.

N869
6.3.2.1 Lvalues and function designators

[#3] Except when

it is the operand of the sizeof operator or

"operand of the sizeof"???

the unary & operator,

or is a string literal used to initialize an array,

an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

((sizeof "abcdef") == 7) is true
--
pete

[pete]

baumann@pan wrote:

what's N869?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

It's the final public last draft.
It's not completely accurate.
when sizeof does not need () and when sizeof need ()?

sizeof takes two kinds of operands:
1 expressions of object type (sizeof 0)
2 an object type in parentheses (sizeof (int))

--
pete

[Keith Thompson]

"baumann@pan" <ba*********@gmail.com> writes:

Chris Torek wrote:

[Given:
char buf[N];
for some suitable constant N]

In article <11**********************@g43g2000cwa.googlegroups .com>
baumann@pan <ba*********@gmail.com> wrote:

>&buf[0] = buf = &buf is __TRUE__ only if we don't consider the data
>type, but the value only.
If you "don't consider the data type", then 3 == 3.14, and 3 != 3.14.

&buf is a pointer to something,

buf in this case can also be considered as pointer , right?

Sort of. buf is the name of an array object, but like any expression
of array type, it's implicitly converted (in most contexts) to a
pointer to its first element. In this case, &buf is of type pointer
to array of N chars, and buf (after the implicit conversion) is of
type pointer to char.
since they are both pointer, they will occupy 32bits in 32-bit cpu.
How do you know that? It happens to be true on many implementations,
but the standard doesn't guarantee it. In particular, it doesn't
guarantee that different pointer types are the same size. Whether
they're the same size or not, they're certainly different types.
so i can compare the 2 32-bit values.
Did you try it? In your program below, you print their values (but
incorrectly; read on), but you don't compare them.

You can have two 32-bit objects, both set to all-bits-zero, that
compare equal -- but if one of them is of type int and the other is of
type float, the fact that they compare equal is just happenstance.
They're of different types, just as the different pointers are of
different types.

Try this:

#include <stdio.h>
int main(void)
{
char buf[5];
if (buf == &buf) {
printf("They're equal\n");
}
else {
printf("They're not equal\n");
}
return 0;
}

When I compile this with gcc in strict mode, it prints "They're equal",
but only after issuing a diagnostic:

tmp.c:5: warning: comparison of distinct pointer types lacks a cast
no 3 == 3.14 would occur.
#include <string.h>
#include <stdio.h>
int main(void)
{
char buf[] = "abcdefghijklmn";
char *token = "l";
char *text = buf;
char * d = (char*)malloc(100);

char * p = strsep((char**)&text,token);
printf("d:%p\t &d:%p\n",d, &d);
printf("buf:%p,&buf:%p,&buf[0]:%p\n", buf, &buf,&buf[0]);
printf("p:%s\n",p);
free(d);
return 0;
}

compiled in redhat 9, outputs

d:0x80496c8 &d:0xbfffee04
buf:0xbfffee10,&buf:0xbfffee10,&buf[0]:0xbfffee10
p:abcdefghijk
you see buf &buf[0] and &buf have the same value:0xbfffee10.

so i mean the three in equal by value, what do you call this situation?
I call it undefined behavior. A printf with a "%p" format expects an
argument of type void*. If you give it a pointer to an array, it may
work as you expect, but the standard doesn't guarantee it.
array is strange or exactly special thing ,i think, few variable of
other type and the address of them could be same ( i think it is mostly
because other type variable could not be taken as pointer , while
variable[] can be, so the comparision between the other type variable
and their address would have no meaning).

What's special about arrays is that an array expression is implicitly
converted to a pointer to its first element (*not* a pointer to the
array) unless it's the operand of a unary "&" or sizeof operator.

Read section 6 of the C FAQ.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

"baumann@pan" wrote:

what's N869?

Haven't you learned not to top-post yet? See the reference marked
(C99) below. It is the last public draft of the C standard before
release.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

[schwarzb]

On 5 Jun 2005 20:45:59 -0700, "baumann@pan" <ba*********@gmail.com>
wrote:

pete wrote:

baumann@pan wrote:

>
> pete wrote:
> > ba*********@gmail.com wrote:
> > >
> > > hi all,
> > >
> > > i want to get the address of buf, which defined as
> > >
> > > char buf[] = "abcde";
> > >
> > > so can call
> > > strsep(address of buf, pointer to token);
> >
> > The address of buf is &buf.
>
> no, (&buf == buf )&&(buf == &buf[0]) is TRUE.

Without a cast, (&buf == buf) is undefined.

&buf is most definitely the address of buf.

no, buf ,&buf and &buf[0] is the address of "abcde", not address of
variable buf. i think we can not get the address of buf itself.

While all three expressions have the same value, the second has a
different type than the other two. It has type pointer to array of
char while the others have type pointer to char. Therefore, the
expression &buf == bug requires a diagnostic since there is no implicit
conversion between the two types.

Since buf is an array and not a pointer, all three expressions evaluate
to the address of the aggregate object buf.