c++: invalid conversion from 'int' to 'const char*'

Fabian Keil freebsd-listen at fabiankeil.de
Sat Sep 12 10:56:21 UTC 2009

Boris Samorodov <bsam at ipt.ru> wrote:

> I'm porting a c++ application to FreeBSD. I've got an error:
> -----
> ~/work/src/FileChannel.cpp: In member function 'QString FileChannel::errorString()':
> ~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to 'const char*'
> ~/work/src/FileChannel.cpp:251: error:   initializing argument 2 of 'char* strcpy(char*, const char*)'
> *** Error code 1
> -----
> A simle patch makes the application to be compiled without errors:
> -----
> --- src/FileChannel.cpp.orig	2009-09-12 13:08:28.000000000 +0400
> +++ src/FileChannel.cpp	2009-09-12 13:08:41.000000000 +0400
> @@ -248,7 +248,7 @@
>  QString FileChannel::errorString()
>  {
> -    strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
> +    strcpy(lastErrorString, "XXX: Fix me: errno should be here");
>      return QString(trUtf8(lastErrorString));
>  }

At least to me, this looks like a bug in the program you are porting.
I don't see how this would work on other platforms either, unless
the libc strerror_r() is shadowed which seems unlikely.

I assume someone replaced strerror() with strerror_r() and
missed the differences. The third argument of strerror_r()
being zero looks strange, too.

> If I understand correctly, an integer value which is returned by
> strerror_r() should be converted to const char*.
> I have _very_ basic knowledge about c++. Hence my question.
> Can someone provide a patch (a proof of concept)? Thanks!

You could try replacing the strerror_r() call with strerror(errno).
It wouldn't be thread-safe, but should at least work most of the

If the application is threaded, a better fix would be not to use
strcpy() at all. strerror_r() already puts the error description
into the buffer, so there's no need to copy anything. To do this,
you'd still need to fix the third argument, though.

If lastErrorString is an array you could use sizeof(lastErrorString),
if it's a pointer you could look for a malloc() call that allocates
the buffer to figure out the size.

Either way, you should probably report the problem upstream.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090912/83a58599/signature.pgp

More information about the freebsd-questions mailing list