Re: cvs: php-src /ext/standard config.m4 crypt_freesec.c crypt_freesec.h

hi, On Sat, Aug 23, 2008 at 7:57 PM, Arnaud Le Blanc <lbarnaud@php.net> wrote: > The commit adds AC_C_INLINE in config.m4, which defines "inline" appropriatly to > __inline or __inline__ if the compiler does not know the "inline" keyword. > > Basically it does what you added in your commit, but without forcing inlining, The latter is an optimization, I should have added it in my commit msg. By the way, config.m4 is unix only and is completely useless on windows. > and unlike a test against some known compiler macros, this will work on all > compilers by checking what they actually support. Except windows (and certainly other). > For instance your code will check only GCC and the MS compiler, and the last > #else may miss the fact that the compiler actually supported __inline or > __inline__. > > For "static" before "inline", it avoids a problem with the Sun compiler > (without static the compiler references the function but does not actually > outputs it). So please apply the correct fix, but keep the windows linux and windows build safe. That certainly means to add what you need in the src or add a portable way to use inline (like in zend, which is where I took the #ifdef). That would be actually the best solution (in php_config.h and config.w32.h). >> > +# ifndef HAVE_U_INT32_T >> > + typedef uint32_t u_int32_t; >> > +# endif >> > +#endif >> >> I don't understand this part. If HAVE_U_INT32_T is not defined, you >> still use u_int32_t? > > If HAVE_U_INT32_T is not defined that means that u_int32_t is not defined. > So I define u_int32_t it to uint32_t. This makes sense for me. It defines unint32_t not u_int32_t. The define should be HAVE_UINT32_T if what you test is uint32_t. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org