In message <1240835018.23553.20.ca...@localhost>
Ben Avison <[email protected]> wrote:
> On Sun, 2009-04-26 at 20:48 +0100, John Tytgat wrote:
> > _main is what we have in UnixLib wrapping the user supplied main() and
> > not as is replaceble. As far as I remember, all identifiers starting with
> > an underscore are reserved for user code so a bit questionable that Vala
> > uses this.
>
> Identifiers starting with two underscores, or one underscore followed by
> a capital letter, are the ones that are reserved to the C runtime
> library. So Vala is within its rights to use "_main" according to the C
> standard, and I'd argue UnixLib should be changed.
I'm not a C language laywer but I don't think this is the full and
correct story.
Not sure how well
<URL:http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf>
represents the final C99 spec, but section 7.1.3 there reads:
--8<--
7.1.3 Reserved identifiers
Each header declares or defines all identifiers listed in its associated
subclause, and optionally declares or defines identifiers listed in its
associated future library directions subclause and identifiers which are
always reserved either for any use or for use as file scope identifiers.
- All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for
use as identifiers with file scope in both the ordinary and tag name
spaces.
--8<--
You obviously refer to the first point and that's the set of identifiers
which are currently being used by some of the latest C identifiers (like
_Bool, _Complex) or can be used in future C specs. So I don't think they
can be safely used by the runtime system.
I was refering to the second point there. When you define a "_main"
function, you clearly have the _main identifier at file scope in an
'ordinary' name space. So this is a no go for user programs. A
counter example would be a "int _main;" variable declaration in a
function, that would be fine but that's not the case we're discussing
here.
But again, I don't pretend to fully master this specification so feel
free to point out what I'm missing here.
John.
--
John Tytgat, in his comfy chair at home BASS
[email protected] ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
