Hello,
I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far;
At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further
Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions.
As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway
____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
Joris Huizer wrote:
Hello,
I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far;
At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further
Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions.
As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway
On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions.
Robert Shearman rob@codeweavers.com wrote: Joris Huizer wrote:
Hello,
I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far;
At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further
Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions.
As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway
On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions.
Joris Huizer wrote:
Though the keyword "inline" implies the code should get inlined, and if it shouldn't, the implementation copy should be removed from the unicode.h file
No, it's a hint to the compiler. "static inline" says to the compiler try to inline this function if it is worth it, or otherwise include a copy of this function in the object file. "extern inline" says to the compiler try to inline this function if it is worth it, or otherwise link to shared copy of this function (in our case, implemented in the libwine shared object).
On 2/18/07, Robert Shearman rob@codeweavers.com wrote:
Joris Huizer wrote:
Though the keyword "inline" implies the code should get inlined, and if it shouldn't, the implementation copy should be removed from the unicode.h file
No, it's a hint to the compiler. "static inline" says to the compiler try to inline this function if it is worth it, or otherwise include a copy of this function in the object file. "extern inline" says to the compiler try to inline this function if it is worth it, or otherwise link to shared copy of this function (in our case, implemented in the libwine shared object).
I believe just "inline" by itself has that effect. One doesn't ordinarily put "extern" on the function definition (unless it's 'extern "C"').
-- Rob Shearman
-
Joris Huizer -
richardvoigt＠gmail.com -
Robert Shearman