From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5141 invoked by alias); 19 Sep 2005 15:03:08 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 3686 invoked by uid 22791); 19 Sep 2005 15:02:04 -0000 Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (199.232.76.164) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 19 Sep 2005 15:02:04 +0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EHN9e-00011Z-J9 for gcc-help@gnu.org; Mon, 19 Sep 2005 11:02:02 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1EHMmm-0008J1-0M for gcc-help@gnu.org; Mon, 19 Sep 2005 10:38:24 -0400 Received: from [64.233.162.206] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EHMml-0008Ix-OU for gcc-help@gnu.org; Mon, 19 Sep 2005 10:38:23 -0400 Received: by zproxy.gmail.com with SMTP id k1so149036nzf for ; Mon, 19 Sep 2005 07:38:23 -0700 (PDT) Received: by 10.37.14.48 with SMTP id r48mr2436025nzi; Mon, 19 Sep 2005 07:38:23 -0700 (PDT) Received: by 10.37.22.44 with HTTP; Mon, 19 Sep 2005 07:38:22 -0700 (PDT) Message-ID: <2e393d0805091907386cf6f442@mail.gmail.com> Date: Mon, 19 Sep 2005 15:03:00 -0000 From: corey taylor Reply-To: corey.taylor@gmail.com To: John Love-Jensen Subject: Re: Reasonable static initialization assurance Cc: gcc-help@gnu.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2e393d0805091907272c7c9460@mail.gmail.com> X-SW-Source: 2005-09/txt/msg00120.txt.bz2 > >Do you know of any difference in this area with the OSX gcc? >=20 > I'm not aware if XCode 2.1 / GCC 4.0 on OS X has any particular caveats > other than the usual suspects applicable to all platforms. So it's probably just a memory clear value discrepency? Some value that the memory is "initialized" with causes a false std::string setup and fails on an assignment. It was amazingly consistant once it started to fail though -- we have no idea yet why the code change caused the failure. The code shouldn't have been like that anyway, but not knowing what caused thee memory failure is a pain :) corey