Date: Sat, 12 Sep 2009 18:37:37 -0400 From: "John L. Templer" <green_tiger@comcast.net> To: Boris Samorodov <bsam@ipt.ru>, FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: c++: invalid conversion from 'int' to 'const char*' Message-ID: <4AAC22B1.20900@comcast.net> In-Reply-To: <33804141@bb.ipt.ru> References: <53480375@bb.ipt.ru> <20090912124143.2fb77924@r500.local> <33804141@bb.ipt.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Boris Samorodov wrote:
> On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote:
>> Boris Samorodov <bsam@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AAC22B1.20900>