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

Boris Samorodov bsam at ipt.ru
Sat Sep 12 11:22:11 UTC 2009


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.

-- 
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve


More information about the freebsd-questions mailing list