[Mono-devel-list] possible bug in static constructor evaluation order

[2a5gjx302 at sneakemail.com]

At 11:29 PM 04/05/2003 +0200, you wrote:
[snip]
>Also Paragraph 6 states:
>
>(1) The static constructor for a class executes at most once in a given
>application domain. (2) The execution of a static constructor is triggered
>by the first of the following events to occur within an application
>domain:
>
>    * (3) An instance of the class is created.
>    * (4) Any of the static members of the class are referenced. 
>
>I would interpret 'A is triggered by B' as: A occurs just before B.
I should point out that this does not mean that there aren't any other
possible implementation-dependent triggers. Also, if people rely on the
ECMA spec, then their code may not run as expected when/if compiled with
Microsoft's compiler. While of course this just means that the Microsoft
compiler does not follow the final spec (not surprising, as it was created
before the final spec), the Microsoft compiler did come first and should be
authoritative reference (aside from bugs), rather than the specification,
which does not match it. The current specification as worded, the way you
interpret it, requires that compilers emit complex locking code and check
on every method call to see if the class has been statically initialized
yet (the locking isn't complex from the point of view of the code to
implement it, but it is definitely a performance concern). The current
specification does not prevent compilers or interpreters from statically
initializing classes when they are loaded, it simply does not specify or
recommend in either way.

On a personal/opiniated note, I can't imagine why they would add this, as
well as the textual order thing you mentioned earlier, to the
specification. For instance, file specification order would be preferable
for static field initializers as it would allow people to depend on the
values for earlier initializers in subsequent initializers in an
easy-to-follow order in the file. Oh well, just my two cents.

>Ah, and what do I need it for. I want to formally define some aspects of
>class loading using operational semantics, so I need precise rules.
>
>-- 
>: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
>: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h

Jonathan