using string as a character buffer in unix system calls

[christopherlmarshall]

I have gotten in the habit of using strings to manage character buffers
that I pass in to unix system calls.

For example, suppose I want to create a character buffer to use with
the "write" system call.

string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());

It recently occured to me that the standard C++ library doesn't
necessarily guarantee that a vector<char> or string will be implemented
in terms of a single c array of char, so that by taking creating a
pointer to the first element of the string or vector and passing it
into a function expecting a c array of char I could be making my
programs non-portable.

Does anyone know if the standard makes any guarantees one way or the
other?

Does anyone find my practice a bad idea?

Chris

[Victor Bazarov]

ch******************@yahoo.com wrote:

I have gotten in the habit of using strings to manage character buffers
that I pass in to unix system calls.

For example, suppose I want to create a character buffer to use with
the "write" system call.

string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());
Ugh! Should most likely be

write(fd, buf.c_str(), buf.size());


It recently occured to me that the standard C++ library doesn't
necessarily guarantee that a vector<char> or string will be implemented
in terms of a single c array of char, so that by taking creating a
pointer to the first element of the string or vector and passing it
into a function expecting a c array of char I could be making my
programs non-portable.
Not really. If you use &somevector[0], you're most likely fine because
in the next standard the contiguousness of the vector storage will be
required (and all current implementations already do that). For a string
you should use 'c_str()' anyway.
Does anyone know if the standard makes any guarantees one way or the
other?
c_str() returns a pointer to the first character of an array, and that
pointer remains valid until a call to a non-const member function. What
you shouldn't attempt doing is _reading_ into that area.
Does anyone find my practice a bad idea?

No. Just do it right. And don't _read_ into a string. For that you
should use a vector or a plain array.

V

[christopherlmarshall]

Victor:

Thanks for the quick reply!

I goofed in my example. I should have declared my buf like this:

vector<char> buf(1024);

It is interesting that the next standard will require contiguousness of
storage in vectors. I wonder what reasons pushed that into being an
explicit issue?

Your c_str() point was well taken. Also the one about not reading into
a string through the address of its first element.

Chris Marshall

[Victor Bazarov]

ch******************@yahoo.com wrote:

[..]
It is interesting that the next standard will require contiguousness of
storage in vectors. I wonder what reasons pushed that into being an
explicit issue?

I think it's the same reason that drove you to use &v[0] to read into or
write from the vector's storage. People have too much legacy stuff that
needs an array. A vector is a good replacement for the C++ arrays _if_
you allow using its storage for direct access through a pointer to the
first element. Turned out to satisfy other requirements vector could not
have non-contiguous storage, so it was decided to legalize that drug.
At least that's how I remember it. You can find out better if you ask
in comp.std.c++ were they talk Standard document.

V

[Me]

Victor Bazarov wrote:

string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());

Ugh! Should most likely be

write(fd, buf.c_str(), buf.size());

I think it's better to use buf.data() here instead.