On Thu, Apr 12, 2007 at 04:56:15PM +0200, [EMAIL PROTECTED] wrote:
> On Thu, Apr 12, 2007 at 09:13:14AM -0500, Steve Peters wrote:
> > On Thu, Apr 12, 2007 at 01:37:24PM +0200, Ron Blaschke wrote:
> > > While poking the GCC documentation I found that there's a feature 
> > > available to limit the exported symbols (with GCC >= 3.3).  Maybe worth 
> > > considering?
> > > It's probably a design decision.  If there's an option to limit the 
> > > exported symbols or make all available, which one should be taken?
> > > 
> > > http://gcc.gnu.org/wiki/Visibility
> > > http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#Function-Attributes
> > > 
> > > This can be done by adding C<-fvisibility=hidden> to CFLAGS and setting 
> > > PARROT_API to C<__attribute__ ((visibility("default")))>.
> > > 
> > > 
> > 
> > I think that we need to tread very carefully with adding additional 
> > gcc-isms to Parrot, lest we break compatibility with additional compilers
> > even further.  If Parrot will run everywhere, we need to think about 
> > working more towards ANSI and POSIX compliance.
> 
> I think that the same effect can be achieved using a linker script (although
> I don't know much about them), in wich case you are not depending on a 
> compiler feature.

ld scripts have non-portability issues as well.

At my day job, we make heavy use of gcc attributes protected in #ifdef
blocks. E.g. 

    ...
    #ifdef __GNUC__
    ) __attribute__((format(printf, 6, 7)));
    #else // __GNUC__
    );
    #endif // __GNUC__

While this certainly does clutter up the headers we've decided that the
additional features, optimization, & error checking allowed by the use of
attributes are worth it.  Machine generating the headers would be better
but we don't have to support non-POSIX like platforms so it hasn't been
worth the effort.

My guess is that the majority of Parrot users are building it with gcc
and just the extra error checking possible from using a rich set of
attributes would benefit all platforms (compile time NULL checking,
etc.).  In fact, I'd vote for using the literal gcc attribute syntax
without protective #ifdefs and then mangling and/or removing
unsupported constructs for the target platform.

-J

--

Attachment: pgpoVwlFWisva.pgp
Description: PGP signature

Reply via email to