Do not export internal unsafe_encode_char()

[petercolberg]

This commit removes a spurious external symbol for the internal function unsafe_encode_char(), which I noticed while preparing a package of the utf8proc library for Debian.

[petercolberg]

Strange, the tests with make check are passing, but the make data target is failing.

[petercolberg]

I added the compiler flag -Wmissing-prototypes that warns in case of exported internal functions:

cc -O2 -Wall -Wmissing-prototypes -fPIC -std=c99 -pedantic -DUTF8PROC_EXPORTS -c -o utf8proc.o utf8proc.c
utf8proc.c:191:18: warning: no previous prototype for ‘unsafe_encode_char’ [-Wmissing-prototypes]
 utf8proc_ssize_t unsafe_encode_char(utf8proc_int32_t uc, utf8proc_uint8_t *dst) {
                  ^

[stevengj]

Yes, we've had some persistent problems with the make data check because the ruby script seems to be producing non-deterministic tables, probably due to differences in hashing algorithms in different ruby versions or on different systems; we haven't tracked it down yet.

[stevengj]

The appveyor test seems to have bitrotted as well, grrr....

[petercolberg]

Just to make sure that my change does not introduce a silent regression to the tests: Was there any particular reason why the tests were using unsafe_encode_char() instead of utf8proc_encode_char()?

[tkelman]

Is -Wmissing-prototypes not included in -Wall? If it isn't, why not? MSVC understands -Wall but not -Wmissing-prototypes, and currently my hacky method of building Julia with MSVC goes through makefiles rather than cmake for some deps.

[stevengj]

It's not included in -Wall for gcc.

[stevengj]

If it causes problems with MSVC, I would just omit this warning.

[petercolberg]

Better suggestion: move -Wmissing-prototypes to CFLAGS in .travis.yml.

The flag serves a purpose, to warn when internal functions are accidentally exported.

[tkelman]

I like that plan, as long as people will skim the travis logs once in a while

[petercolberg]

See .travis.yml, the flag -Werror ensures that Travis will fail on warnings.

The 2.0 release and subsequent #77 proved that warnings will be ignored with certainty unless fatal. 😉