Hi Simon, Simon Josefsson <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: >> One possible problem is that you end up writing C99 code, using >> C99-specific things like, say, C++-style comments, declarations not at >> the beginning of a block, etc. These things will break with non-C99 >> compilers. > > Yes, but anything like that would be bugs. We still target C89 + POSIX > sockets. Gcc's default mode is gnu89 (I think?), which does permit some > things from C99, so we have had this problem forever. Compiling with `-std=c99' makes it harder to catch these "bugs". > Unfortunately, I think it is too early to require C99. A lot of > embedded and less capable systems need gnutls, and they barely have C89 > support even these days. Agreed. >> Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o' >> objects produced on MacOS X, I have now idea. > > As far as I can tell, it would only happen if some code in gnutls uses > some guile declaration that implicitly calls gmpz_abs. Reports I've seen about the `G_INLINE_FUNC' issue in Glib (which is a similar problem) seem to imply that something's wrong with Apple's linker that prevents "extern inline" from working properly. > 'extern inline' means, I think, that stand-alone object code is still > generated and can be used by external code. So any code that use calls > mpz_abs would declare an external symbol as well. However, it seems to > me that this should only be a weak symbol, so I don't understand how > there could be a symbol collision. Indeed. > Hm. There is actually some interesting discussion in gmp.h: > > /* The following are provided as inlines where possible, but always exist as > library functions too, for binary compatibility. > > Within gmp itself this inlining generally isn't relied on, since it > doesn't get done for all compilers, whereas if something is worth > inlining then it's worth arranging always. > > There are two styles of inlining here. When the same bit of code is > wanted for the inline as for the library version, then __GMP_FORCE_foo > arranges for that code to be emitted and the __GMP_EXTERN_INLINE > directive suppressed, eg. mpz_fits_uint_p. When a different bit of code > is wanted for the inline than for the library version, then > __GMP_FORCE_foo arranges the inline to be suppressed, eg. mpz_abs. */ Another possible investigation area... Thanks, Ludovic. _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
