Velocity Reviews > string buffer

# string buffer

George2
Guest
Posts: n/a

 12-10-2007
Hello everyone,

Suppose we defined a string buffer (array), like this,

char array[] = "hello world";
char buf[256]

Sometimes, I noticed that we either use,

1. array (buf)
or use,
2. &array (&buf)
or use
3. &array[0] (&buf[0])

as the beginning address of the array,

example like,

strcpy (buf, array);
strcpy (&buf, array);
....

I am wondering the differences between the 3 approaches, and which
approach is the most correct?

George

pete
Guest
Posts: n/a

 12-10-2007
George2 wrote:
>
> Hello everyone,
>
> Suppose we defined a string buffer (array), like this,
>
> char array[] = "hello world";
> char buf[256]
>
> Sometimes, I noticed that we either use,
>
> 1. array (buf)
> or use,
> 2. &array (&buf)
> or use
> 3. &array[0] (&buf[0])
>
> as the beginning address of the array,
>
> example like,
>
> strcpy (buf, array);
> strcpy (&buf, array);
> ...
>
> I am wondering the differences between the 3 approaches, and which
> approach is the most correct?

The type of the parameters of strcpy is: pointer to char.

char *strcpy(char * restrict s1, const char * restrict s2);

When buff and array are used as arguments,
their types are converted to pointers to char.

The type of (&buf) is pointer to array of 256 char,
so that's the wrong type of argument for the parameter.

N869
6.3.2 Other operands
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. If the array object has
register storage class, the behavior is undefined.

--
pete

Johannes Bauer
Guest
Posts: n/a

 12-10-2007
George2 schrieb:

> char array[] = "hello world";
> char buf[256]
>
> Sometimes, I noticed that we either use,
>
> 1. array (buf)
> or use,
> 2. &array (&buf)
> or use
> 3. &array[0] (&buf[0])
>
> as the beginning address of the array,

1 and 3 are semantically identical. I prefer 1.

2 is wrong for strcpy, as was already pointed out to you. It should at
least yield a warning in most compilers.

Greetings,
Johannes

--
"Viele der Theorien der Mathematiker sind falsch und klar
Gotteslästerlich. Ich vermute, dass diese falschen Theorien genau
deshalb so geliebt werden." -- Prophet und Visionär Hans Joss aka

vicks
Guest
Posts: n/a

 12-10-2007
On Dec 10, 9:16 am, Johannes Bauer <(E-Mail Removed)> wrote:
> George2 schrieb:
>
> > char array[] = "hello world";
> > char buf[256]

>
> > Sometimes, I noticed that we either use,

>
> > 1. array (buf)
> > or use,
> > 2. &array (&buf)
> > or use
> > 3. &array[0] (&buf[0])

>

I have tried (buf,array) working i tried ((char *)buf,(const char
*)array ) that also is working..but when i tried (&buf,&array) it
given warning..

But i think the mpost app. syntax would be strcpy((char *)buf,(const
char *)array)?

Regards
Vikas

Mark Bluemel
Guest
Posts: n/a

 12-10-2007
vicks wrote:
> I have tried (buf,array) working i tried ((char *)buf,(const char
> *)array ) that also is working..but when i tried (&buf,&array) it
> given warning..

> But i think the mpost app. syntax would be strcpy((char *)buf,(const
> char *)array)?

Why would you think that?

Given "char buf[<some number];", "buf" "degrades" to "char *", so the
first cast is totally unnecessary. (See 6.3.2.1 "Lvalues, arrays and
function designators").

If necessary, the "array" argument will be converted to "const char *"
as that's what the strcpy() prototype specifies it will be.

strcpy(buf, array) is simple, clear and readable.

Johannes Bauer
Guest
Posts: n/a

 12-10-2007
vicks schrieb:

> I have tried (buf,array) working i tried ((char *)buf,(const char
> *)array ) that also is working..but when i tried (&buf,&array) it
> given warning..

The compiler is giving a warning because it is clearly wrong, as pointed
out before.

Greetings,
Johannes

--
"Viele der Theorien der Mathematiker sind falsch und klar
Gotteslästerlich. Ich vermute, dass diese falschen Theorien genau
deshalb so geliebt werden." -- Prophet und Visionär Hans Joss aka

CBFalconer
Guest
Posts: n/a

 12-10-2007
George2 wrote:
>
> Suppose we defined a string buffer (array), like this,
>
> char array[] = "hello world";
> char buf[256]
>
> Sometimes, I noticed that we either use,
>
> 1. array (buf)
> or use,
> 2. &array (&buf)
> or use
> 3. &array[0] (&buf[0])
>
> as the beginning address of the array,

When passed as function parameters, all arrays are automatically
passed as pointers to the first item in the array. Thus by simply
using 'array' and 'buf' you are getting case 3.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Keith Thompson
Guest
Posts: n/a

 12-11-2007
CBFalconer <(E-Mail Removed)> writes:
[...]
> When passed as function parameters, all arrays are automatically
> passed as pointers to the first item in the array.

[...]

True, but incomplete.

I've seen a lot of posters here say that arrays are converted to
pointers when passed as function arguments. That's correct, but it's
only a special case of a more general rule. An array expression is
converted to a pointer in *most* contexts, not just in function calls
(the only exceptions are when the array expression is the operand of a
unary "sizeof" or "&" operator, or when it's a string literal used to
initialize an array).

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

CBFalconer
Guest
Posts: n/a

 12-12-2007
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
> [...]
> > When passed as function parameters, all arrays are automatically
> > passed as pointers to the first item in the array.

> [...]
>
> True, but incomplete.
>
> I've seen a lot of posters here say that arrays are converted to
> pointers when passed as function arguments. That's correct, but
> it's only a special case of a more general rule. An array
> expression is converted to a pointer in *most* contexts, not just
> in function calls (the only exceptions are when the array
> expression is the operand of a unary "sizeof" or "&" operator, or
> when it's a string literal used to initialize an array).

Why do you complicate the thread with this? It has nothing to do
with the OPs posting, to which I replied. That makes two similar
foolish postings in as many minutes.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Keith Thompson
Guest
Posts: n/a

 12-12-2007
CBFalconer <(E-Mail Removed)> writes:
[SNIP]
> Why do you complicate the thread with this? It has nothing to do
> with the OPs posting, to which I replied. That makes two similar
> foolish postings in as many minutes.

It's called a discussion.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"