This is the mail archive of the
mailing list for the Cygwin project.
Re: [Patch] Setup: Warn about dropped mirrors.
- From: Max Bowsher <maxb1 at ukf dot net>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 14 Mar 2006 15:37:24 +0000
- Subject: Re: [Patch] Setup: Warn about dropped mirrors.
- Openpgp: id=C0F2C580
- References: <096201c64708$355aee60$a501a8c0@CAM.ARTIMI.COM>
- Reply-to: cygwin-apps at cygwin dot com
-----BEGIN PGP SIGNED MESSAGE-----
Dave Korn wrote:
> On 10 March 2006 17:20, Christopher Faylor wrote:
>> On Mon, Mar 06, 2006 at 05:00:45AM +0100, Bas van Gompel wrote:
>>> Op Wed, 16 Nov 2005 23:29:50 +0100 (MET) schreef Bas van Gompel
>>> in <n2m-g.dlgdit.3vsvtmt.1<at>buzzy-box.bavag>:
>>> Now using std::string, not String.
> Is that ok vs the passing std::string params to dll functions in 3.4.4
setup doesn't make _any_ C++ calls across DLL boundaries.
>> (gdb) f 2
>> #2 0x0045293c in do_download_site_info_thread (p=0x4dbd40) at
>> /cygnus/src/cygwin-apps/setup/site.cc:330 330 theCachedString =
>> new_cstr_char_array (cached_mirrors);
>> This happened a couple of times and then I could no longer duplicate it.
>> Can anyone else?
> I can reproduce this by renaming aside mirrors-lst. It occurs on the line
> theCachedString = new_cstr_char_array (cached_mirrors);
> when cached_mirrors is an empty string.
Thanks for debugging!
> One possible fix is the first attached patch. Would check it in as trivial
> and obvious, but I don't know whether we should rightly consider this a bug in
> c_str rather than in new_cstr_char_array; it's not like we have a
> tightly-documented spec for the String class that would let us decide whether
> n_c_c_a is at fault for not handling a valid return or c_str is at fault for
> returning an invalid value. Maybe we want to think about whether we should
> make String store the nul terminator after all, or otherwise not let
> String::c_str() return NULL? It could just as easily return "" instead. I've
> attached three possible patches; the first one is the one that most directly
> attacks the problem at site with least danger of knock-on effects, whereas if
> we change c_str we'd have to be sure that any code that depended on getting a
> NULL return worked as well when given a real return with a strlen of zero.
> 2006-03-14 Dave Korn <email@example.com>
> * String++.cc (new_cstr_char_array): Handle null input correctly.
Looks good, please go ahead and commit.
It is my fond hope that one day we will have completely eliminated
String from setup's code in favour of std::string. The current madness
of using a mixture of two different string classes is silly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
-----END PGP SIGNATURE-----