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

John L. Templer green_tiger at comcast.net
Sat Sep 12 22:50:50 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Boris Samorodov wrote:
> On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote:
>> 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.
> 
> It compiles at linux (with warning though). ;-)
> 
>> 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
>> time.
> 
> Aha, the following patch helps:
> -----
> --- src/FileChannel.cpp.orig	2009-09-12 15:09:00.000000000 +0400
> +++ src/FileChannel.cpp	2009-09-12 15:11:23.000000000 +0400
> @@ -248,7 +248,7 @@
>  
>  QString FileChannel::errorString()
>  {
> -    strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
> +    strcpy(lastErrorString, strerror(errno));
>      return QString(trUtf8(lastErrorString));
>  }
>  
> -----
> 
>> 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.
> 
> Thanks for your suggestions, much appreciated.
> 
>> Either way, you should probably report the problem upstream.
> 
> Yep, it has been already done. The author said he'll fix it at
> the next release but he have no time ATM. While I try to create
> a port with the current release.
> 

According to the man pages supplied with GNU gcc, this is a GNU extension.  (The following is from a
Linux system, but I suspect it's similar to the gcc port on FreeBSD.)

> NAME
>        strerror, strerror_r - return string describing error number
> 
> SYNOPSIS
>        #include <string.h>
> 
>        char *strerror(int errnum);
> 
>        int strerror_r(int errnum, char *buf, size_t buflen);
>                    /* XSI-compliant */
> 
>        char *strerror_r(int errnum, char *buf, size_t buflen);
>                    /* GNU-specific */
   <snip>
>        The XSI-compliant strerror_r() is preferred for portable  applications.
>        It  returns  the error string in the user-supplied buffer buf of length
>        buflen.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqsIq4ACgkQjkAlo11skePOdACfSFAVWlkGskL9lOhzNYdmNAgq
9TYAoJqCRlVdA2rSzv3qXYD0ck6d/hJg
=qsX9
-----END PGP SIGNATURE-----


More information about the freebsd-questions mailing list