From owner-freebsd-questions@FreeBSD.ORG Sat Sep 12 22:50:50 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE75106566B for ; Sat, 12 Sep 2009 22:50:50 +0000 (UTC) (envelope-from green_tiger@comcast.net) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 35E2D8FC0C for ; Sat, 12 Sep 2009 22:50:50 +0000 (UTC) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id fyXe1c00517UAYkA4ydgcF; Sat, 12 Sep 2009 22:37:40 +0000 Received: from [192.168.1.2] ([69.250.45.68]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id fyde1c0081UFfxx8Zydfyo; Sat, 12 Sep 2009 22:37:40 +0000 Message-ID: <4AAC22B1.20900@comcast.net> Date: Sat, 12 Sep 2009 18:37:37 -0400 From: "John L. Templer" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Boris Samorodov , FreeBSD Mailing List References: <53480375@bb.ipt.ru> <20090912124143.2fb77924@r500.local> <33804141@bb.ipt.ru> In-Reply-To: <33804141@bb.ipt.ru> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: c++: invalid conversion from 'int' to 'const char*' X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 22:50:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Boris Samorodov wrote: > On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote: >> Boris Samorodov 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 > > 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 */ > 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-----