Hi, Kevin Ryde <[EMAIL PROTECTED]> writes:
> Which is probably not really in line with gnu coding standards > (standards.info end of "Syntactic Conventions" node). But I guess any > application might do it. Certainly not the only thing that's not GCS-compatible in Guile... ;-) > That was ceval/deval() local variables on gcc 4 last time I hit that. > -O1 may be better, or just on eval.c at least. Right, I don't have the "stack overflow" with `-O1', fortunately. >> +static SCM_C_INLINE int > > I suspect extern inline is what you want, static inline might end up > with a copy of the code in every file, under -O0 at least. But extern > inline is even more of a gcc-ism, if you're worried about the > commercial compilers. With `-O0', no inlining takes place, unless the `always_inline' attribute was specified. `extern inline' is a indeed a GCCism. It might be better since, as you said, it would allow a single definition to be used in the case where inlining doesn't take place. Quoting the GCC manual: If you specify both `inline' and `extern' in the function definition, then the definition is used only for inlining. In no case is the function compiled on its own, not even if you refer to its address explicitly. Such an address becomes an external reference, as if you had only declared the function, and had not defined it. OTOH, the code of this function is sufficiently small so that code duplication shouldn't be a concern---if it was, we wouldn't be inlining in the first place. So I think it'd make sense to apply it as is. We'll have to ask people who work with proprietary compilers to voice out if there's something wrong anyway. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel