Reasonable static initialization assurance

Reasonable static initialization assurance

[corey taylor]

Is there any reasonable manner to ensure a static object is
initialized before use without wrapping it in a getter/setter
function?

We are seeing some order issues show up on an OSX build (not linux though yet).

Take file.a and file.b:

file.a has a global variable of a table which accesses the static
System class methods for allocation and setup.

file.b has the System methods which all call an init method when first
called to make sure the system is setup right and find out what
version and computer is running.  This method accesses a static global
variable in file.b and seg faults.

Is there any way to ensure a static variable in file.b is initialized
before being used?

Corey

Re: Reasonable static initialization assurance

[corey taylor]

> 1. Your question is of general nature not specific to gcc.  As such it doesn't
> belong onto the gcc-help list.

You're telling me that the compiler plays no part in the variable
initializations?

2.  I'm trying to find the difference between the code specifically. 
It also currently only happens on OSX gcc and not linux.  Perhaps I
can reproduce in linux, but as I've finally tracked the error down to
a std::string object being assigned to during another part of the
static initialization period I'm sure that case has happened before.

> 3. Static values are contained in the program text at any execution time and
> are loaded into their own memory section never changing their place.

Yes of course, exactly.  I'm asking if there is any "reasonable" way
to use non-POD types for static global variables and use them before
the initalization period is over.

Of course, you can replace objects like std::string with character
arrays -- but the question still remains.

> I assume you access not initialized contents of the variables or you write
> into const sections of constant values.

Well, even without an assignment made.  Just a non-POD object sitting
in memory initialized properly.

Corey

Re: Reasonable static initialization assurance

[Ingo Krabbe]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

No I'm telling you that the compiler type plays no part in your problem with 
variable initializations.

Am Montag, 19. September 2005 08:37 schrieb corey taylor:
> > 1. Your question is of general nature not specific to gcc.  As such it
> > doesn't belong onto the gcc-help list.
>
> You're telling me that the compiler plays no part in the variable
> initializations?
>
> 2.  I'm trying to find the difference between the code specifically.
> It also currently only happens on OSX gcc and not linux.  Perhaps I
> can reproduce in linux, but as I've finally tracked the error down to
> a std::string object being assigned to during another part of the
> static initialization period I'm sure that case has happened before.
>
> > 3. Static values are contained in the program text at any execution time
> > and are loaded into their own memory section never changing their place.
>
> Yes of course, exactly.  I'm asking if there is any "reasonable" way
> to use non-POD types for static global variables and use them before
> the initalization period is over.
>
> Of course, you can replace objects like std::string with character
> arrays -- but the question still remains.
>
> > I assume you access not initialized contents of the variables or you
> > write into const sections of constant values.
>
> Well, even without an assignment made.  Just a non-POD object sitting
> in memory initialized properly.
>
> Corey

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reasonable static initialization assurance

[corey taylor]

On 9/19/05, Ingo Krabbe <ikrabbe.ask@web.de> wrote:
> No I'm telling you that the compiler type plays no part in your problem with
> variable initializations.

Then that's a difference answer.

corey

Re: Reasonable static initialization assurance

[John Love-Jensen]

Hi Corey,

> Is there any way to ensure a static variable in file.b is initialized before
being used?

Yes, but you'll have to refactor your code a bit.

Use a static function in FileB to return FileB's static data (which is
static data inside that static function).

Have FileA get to the FileB's static data through that accessor function.

HTH,
--Eljay

Re: Reasonable static initialization assurance

[corey taylor]

Yea, I figured as much.  

Current solution uses a character array for the global variable and a
static accssor that assigns that to a static const std::string.

I knew there was no way around that -- but I thought there might be
some way to do it, in some order.

Eljay,

  Do you know of any difference in this area with the OSX gcc?

corey

On 9/19/05, John Love-Jensen <eljay@adobe.com> wrote:
> Hi Corey,
> 
> > Is there any way to ensure a static variable in file.b is initialized before
> being used?
> 
> Yes, but you'll have to refactor your code a bit.
> 
> Use a static function in FileB to return FileB's static data (which is
> static data inside that static function).
> 
> Have FileA get to the FileB's static data through that accessor function.
> 
> HTH,
> --Eljay
> 
>

Re: Reasonable static initialization assurance

[John Love-Jensen]

Hi Corey,

> I knew there was no way around that -- but I thought there might be
> some way to do it, in some order.

As a general C/C++ solution, no.

There is a GCC mechanism that could help:
-finit-priority
__attribute__((init_priority(n)))

Depending on how dependent you like your code on compiler extensions.

>Do you know of any difference in this area with the OSX gcc?

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.

HTH,
--Eljay

Re: Reasonable static initialization assurance

[corey taylor]

> >Do you know of any difference in this area with the OSX gcc?
> 
> 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