On Mon, 03 Mar 2008, Sisyphus wrote: > Alias.xs defines PERL_CORE (but not PERL_EXT). I gather that PERL_CORE is > also switching on access to those functions. (The changes mentioned in the > above two links involve both PERL_CORE and PERL_EXT.)
PERL_CORE is a superset: everything is visible when you define PERL_CORE (but may still not be linkable if your code isn't statically linked into the core). PERL_EXT exposes fewer symbols, but all symbols those symbols are always available under PERL_CORE too. I think it is a mistake that Alias.xs uses PERL_CORE. > > You'll see that the APIs are marked 'EX' if embed.fnc and not 'A'. That > > means they are still not considered part of the public API, and they may > > change from release to release. > > Yes - I noticed that. (Bad terminology on my part .... "explicitly exported" > != "public"). > > I'll hazard a quick guess that anything marked with an 'E' is exported if > PERL_CORE is defined, and anything marked with an 'X' is exported if > PERL_EXT is defined. Not quiet: "E" means visible at compile-time when PERL_EXT is defined, "X" means the symbol is exported and therefore resolvable at runtime. This is just a historical accident; you'll always see "E" and "X" together because "E" alone doesn't make any sense. "E" should imply "X", just as "A" does. So basically you have 3 layers: 1) all symbols are visible when you define PERL_CORE 2) only the symbols marked with A or E are available when you define PERL_EXT 3) only the symbols marked with A are available in a normal extension Nothing is preventing you from breaking the rules, except that on Windows and AIX you won't be able to access non-exported symbols, thereby protecting the inner layer (1) above. Cheers, -Jan _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
