summaryrefslogtreecommitdiffstats
path: root/libass/Makefile.am
diff options
context:
space:
mode:
authorOleg Oshmyan <chortos@inbox.lv>2021-07-08 04:12:30 +0300
committerOleg Oshmyan <chortos@inbox.lv>2021-07-10 02:36:31 +0300
commitd7e0e17ce571a8eca8fdf978a7c00c096782d037 (patch)
treea52f964487ad6aab700b5b2a28fcf1954a70defe /libass/Makefile.am
parentac254eb826ec11e676223a9df560ce246927d063 (diff)
downloadlibass-d7e0e17ce571a8eca8fdf978a7c00c096782d037.tar.bz2
libass-d7e0e17ce571a8eca8fdf978a7c00c096782d037.tar.xz
Use gnu_printf format attribute to avoid warnings on MinGW
We use %zu format specifiers to log size_t values. However, __attribute__((format(printf, ...))) in modern GCC means "system's default" printf, which on MinGW means MSVCRT.DLL printf, which does not support the z length modifier (even on Windows 10), so GCC warns that our format strings are invalid. Older GCC is unable to check Microsoft's format strings at all and has only format(printf), which is equivalent to the newer gnu_printf. Clang also lacks gnu_printf, but it is covered by the same macro check because its __GNUC...__ macros always report version 4.2.1. On non-Microsoft platforms, printf and gnu_printf are currently aliases, so the __MINGW32__ check is redundant. However, with some luck, GCC may start to check other platforms' printf formats more carefully in the future; and we would like to receive warnings if our format strings don't work on some platform, although we intend to stick to standard C99 format strings. Indeed, if we use an extension by accident, this might help us catch it. And even if we make no mistake but there is another platform that fails to support C99 format strings, this might warn some poor soul building on that platform that their system printf doesn't understand our log format strings, so they will know they need to work around it in their log callback or to patch libass.
Diffstat (limited to 'libass/Makefile.am')
0 files changed, 0 insertions, 0 deletions