static functions declared but not used in header files causing warnings

[poly...@gmail.com]

Compiling for Android, which I believe uses GCC under the hood, I get this output:

include/webp/decode.h:164:24: warning: 'int _WebPIsAlphaMode(WEBP_CSP_MODE)' defined but not used [-Wunused-function]

include/webp/decode.h:170:24: warning: 'int WebPIsRGBMode(WEBP_CSP_MODE)' defined but not used [-Wunused-function]

include/webp/decode.h:214:24: warning: 'int WebPInitDecBuffer(WebPDecBuffer*)' defined but not used [-Wunused-function]

include/webp/decode.h:352:29: warning: 'uint8_t* WebPIDecGetYUV(const WebPIDecoder*, int*, uint8_t**, uint8_t**, int*, int*, int*, int*)' defined but not used [-Wunused-function]

include/webp/decode.h:466:24: warning: 'int WebPInitDecoderConfig(WebPDecoderConfig*)' defined but not used [-Wunused-function]

Also, similar warnings for encode.h. 

My question is, why are these in the header to begin with?

These warnings show up for every file that includes these headers. I assume they would be optimized out of the translation unit if the are not used, though not positive. Either way, when I am looking for warnings/errors in my code, it's kind of annoying to have a bunch of webp warning obscuring them. I could always use the -Wunused-function flag as stated in the output, but then I will miss any unused functions in my own code. Just seems to make sense to either take them out of the header or make them a true macro or dummy template if the code really needs to be in the header (again, why?)

I love webp btw, thank you!

-Shaun

[poly...@gmail.com]

This article makes me thing what is really intended here is inline rather than static inline:

http://stackoverflow.com/questions/10876930/should-one-never-use-static-inline-function

The fact that it is in the header tells me that users of the library should have access to these functions, but static generally means, "I want this function to exist and be available only in this file." But since it is in a header, it exists in any file that includes it, thus defeating the purpose of static... unless I'm missing something.

[Pascal Massimino]

Hi,

On Sat, Feb 15, 2014 at 11:24 PM, <poly...@gmail.com> wrote:

This article makes me thing what is really intended here is inline rather than static inline:

http://stackoverflow.com/questions/10876930/should-one-never-use-static-inline-function

The fact that it is in the header tells me that users of the library should have access to these functions, but static generally means, "I want this function to exist and be available only in this file." But since it is in a header, it exists in any file that includes it, thus defeating the purpose of static... unless I'm missing something.

that's strange, usually one gets this 'function XXX defined but not used...' warning only if you *don't* use the 'inline' keyword.

That's why we introduced this systematic 'static inline ...' declaration style for all small or critical functions that are implemented only

in the headers.

Which leads me to wonder: are you sure WEBP_INLINE is not defined empty on your system? This would be the

case if, e.g., you have __STRICT_ANSI__ declared somewhere (according to webp/types.h).

skal

On Saturday, February 15, 2014 10:44:00 PM UTC-8, poly...@gmail.com wrote:

Compiling for Android, which I believe uses GCC under the hood, I get this output:

include/webp/decode.h:164:24: warning: 'int _WebPIsAlphaMode(WEBP_CSP_MODE)' defined but not used [-Wunused-function]

include/webp/decode.h:170:24: warning: 'int WebPIsRGBMode(WEBP_CSP_MODE)' defined but not used [-Wunused-function]

include/webp/decode.h:214:24: warning: 'int WebPInitDecBuffer(WebPDecBuffer*)' defined but not used [-Wunused-function]

include/webp/decode.h:352:29: warning: 'uint8_t* WebPIDecGetYUV(const WebPIDecoder*, int*, uint8_t**, uint8_t**, int*, int*, int*, int*)' defined but not used [-Wunused-function]

include/webp/decode.h:466:24: warning: 'int WebPInitDecoderConfig(WebPDecoderConfig*)' defined but not used [-Wunused-function]

Also, similar warnings for encode.h. 

My question is, why are these in the header to begin with?

These warnings show up for every file that includes these headers. I assume they would be optimized out of the translation unit if the are not used, though not positive. Either way, when I am looking for warnings/errors in my code, it's kind of annoying to have a bunch of webp warning obscuring them. I could always use the -Wunused-function flag as stated in the output, but then I will miss any unused functions in my own code. Just seems to make sense to either take them out of the header or make them a true macro or dummy template if the code really needs to be in the header (again, why?)

I love webp btw, thank you!

-Shaun

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.

[poly...@gmail.com]

__STRICT_ANSI__ is not defined and WEBP_INLINE is defined as "inline"

I just tested removing only the word "static" before WEBP_INLINE, and sure enough the warning goes away.

[poly...@gmail.com]

Removing static is not the answer after all. I finally got my code to compile all the way. When it got to the linking stage I got many errors like this one:

multiple definition of 'WebPIsPremultipliedMode'

one for each of those inlines. So again, simply removing the static keyword is not the answer.

I thought the compiler or linker is supposed to figure things out if functions are defined "inline" and not put an instance into each translation unit. In other words, I thought that even if the compiler chose not to inline the code, it would deal with that choice during linking by removing the other instances of the function rather than complaining that there are several definitions. Apparently I am wrong.

So it still seems like the best solution would be moving these implementations to a c file and leaving prototypes in their place. Are there any arguments against doing that? I can't imagine having a slightly bigger lib file would hurt too much, but I don't know what the goals were and why choices were made in the first place (which is why I'm asking.)

Thanks!

-Shaun