«

I have some C code in a header which must be #included in both C and
C++ source files. The code in the header makes use of memcpy().

In bcb3 and bcb6, memcpy() needs <mem.h>. According to the g++ man page
for memcpy(), memcpy() needs <string.h>, and g++ complains that it
can't find <mem.h>

Is there anything in the standards which specify which header memcpy()
should require?

I'm aware of <cstring> but can't use it because this code must be both
valid C and C++

I don't want to end up with code which is stuffed full of #ifdef's for
all the different compilers I need to support. How do I deal with this
issue?

--
Simon Elliott http://www.ctsn.co.uk

Simon Elliott wrote:
>
> Is there anything in the standards which specify which header memcpy()
> should require?
>
> I'm aware of <cstring> but can't use it because this code must be both
> valid C and C++
>

It's declared in <string.h> and <cstring>.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Simon Elliott wrote:
> I have some C code in a header which must be #included in both C and
> C++ source files. The code in the header makes use of memcpy().
>
> In bcb3 and bcb6, memcpy() needs <mem.h>. According to the g++ man page
> for memcpy(), memcpy() needs <string.h>, and g++ complains that it
> can't find <mem.h>
>
> Is there anything in the standards which specify which header memcpy()
> should require?

Yes. 'memcpy' is available either in <cstring> or <string.h>. The former
is supposed to have it in 'std' namespace. The latter is supposed to have
it in both global and 'std' namespaces.

>
> I'm aware of <cstring> but can't use it because this code must be both
> valid C and C++

Use <string.h> then.

>
> I don't want to end up with code which is stuffed full of #ifdef's for
> all the different compilers I need to support. How do I deal with this
> issue?
>

Try to always use the common standard denominator. Be prepared though
to still have some #ifdef's in your code. It's inevitable. Not all
compilers support 100% of the language and quite a few simply have bugs.

V

On Tue, 28 Jun 2005 00:07:17 +0400, Simon Elliott <Simon at <ctsn.co.uk>>
wrote:

> I have some C code in a header which must be #included in both C and
> C++ source files. The code in the header makes use of memcpy().
>
> In bcb3 and bcb6, memcpy() needs <mem.h>. According to the g++ man page
> for memcpy(), memcpy() needs <string.h>, and g++ complains that it
> can't find <mem.h>

There is no standard header <mem.h>. C standard ISO/IEC 9899:1999 (E) in
7.21 states memcpy() is declared in <string.h>.

--
Maxim Yegorushkin

On 28/06/2005, Maxim Yegorushkin wrote:

> > In bcb3 and bcb6, memcpy() needs <mem.h>. According to the g++ man
> > page for memcpy(), memcpy() needs <string.h>, and g++ complains
> > that it can't find <mem.h>

> There is no standard header <mem.h>. C standard ISO/IEC 9899:1999 (E)
> in 7.21 states memcpy() is declared in <string.h>.

Thanks for this. It turns out that memcpy() is declared in <string.h>
as well as <mem.h> in the Borland compilers, so I can simply change all
occurances of <mem.h> to <string.h> and have standard and portable code
with no #ifdefs.

--
Simon Elliott http://www.ctsn.co.uk