Some refactoring

[wx257osn2]

• Remove trailing whitespaces
• Use png_size_t instead of int
• Specify formats for printf using inttypes.h for portability
• Cast unused parameters as void due to suppress warnings
• Use stbi_image_free instead of free
• Add static to local symbols
• Make the cast of narrowing conversion explicitly due to suppress a warning on MSVC
• Add -Wall -Wextra for qoibench
• Add -Wall -Wextra -pedantic-errors for qoiconv

This PR doesn't change the output of qoiconv and qoibench for the conventionally assumed environments.

[phoboslab]

Adding -Wall -Wextra is probably a good idea. So is static for local symbols and the unused params fix. I'm ambivalent to the whitespace cosmetics and against the inttypes.h (Windows doesn't have this, afaik; and it makes the printfs() unnecessarily hard to read).

I'll go through this in a few days. Thanks!

[Alcaro]

MSVC ignored stdint.h and inttypes.h (and the rest of C99) for many years, but they once the same features showed up in C++11, they were implemented. From what I can google, they exist in MSVC 2015, and not in 2005; I can't find any more precise bounds.

That said, PRIu64 is indeed ugly. And it's not correct either - png_size_t is size_t, which is not a 64bit type. The correct formatting opcode for a size_t is %zu. (I'm also unsure why we'd use png_size_t and not just size_t.)

[phoboslab]

size_t vs. int was discussed in https://github.com/phoboslab/qoi/issues/21. For the sake of c89 compatibility I have no intention to change it.

I will implement a check to ensure bytes_read == size to catch problems early!

[wx257osn2]

@Alcaro

The correct formatting opcode for a size_t is %zu.

I had rather thought that %zu had not been implemented in MSVC for a long time, but it seems to have been implemented in recent MSVC. I agree that %zu is more appropriate too.

I'm also unsure why we'd use png_size_t and not just size_t.

In libpng context, it's better to use png_size_t instead of size_t , isn't it?

---

@BenBE

I only remarked about the size_t issue once, but to do it properly this includes a full API update throughout the code.

I agree your opinion, it needs API updating to fix the issue properly . However, I think that this project has already passed the point where changes could be made to the API. In addition, for the sake of compatibility with the C89, it should be as-is either. Third-party implementations might keep this in mind.

[BenBE]

In addition, for the sake of compatibility with the C89, it should be as-is either. Third-party implementations might keep this in mind.

I'm not much of a fan for C89: If code should be as compatible as possible I usually prefer it to follow C99 standard, as several very convenint features like inline functions, an expliit bool data type as well as intermixed variable declarations&code have been introduced (among others). Furthermore the comment style used in lines 38ff of qoi.h is also C99. ;-) Also, strictly speaking qoibench.c also uses C99 for the access to floating point support. Another feature taken from C99 is inttypes.h, which was introduced with that release of the standard.

Or put differently: Not using the C99 standard introduces more hassles in maintenance than the compatibility argument warrants. I'm not aware of any decent compiler that does not support C99 enough to understand inline, all the inttypes/stddef/stdint and intermixed variable declarations. Even MSVC is C99 compliant, if you ask it to. ;-) I'm currently only aware of one platform where I consider C99 support "broken out of the box", which is the newlibc used on several ARM processors, which silently skips some features of C99 (floating point support, some format specifiers for printf) in its default configuration (can be fixed by building the toolchain yourself and activating 2 features while doing so).

C99 was released 22 years ago: At some point it's just not state of the art anymore …

[wx257osn2]

@BenBE I want to make two points clear. First, I have the opinion that new language standards should be used actively, and I don't consider C89 support to be particularly important. If I had to write C myself, I would definitely use C99 or later. (Actually, I'm not good at C, so I don't master C11 or later currently. Usually I use C++.) However, in light of the fact that this project has C89 support in mind ( especially in qoi.h ), I think it would be difficult to change at least the qoi_read interface. And second, this is due to my poor English, what third party implementations must keep in mind that I'd wanted to told you is that size shouldn't be handled with int, and not that we should use C89.

[vtorri]

on windows : %I instead of %z

something like

#ifdef _WIN32
#define FMT_ZU "%Iu"
#else
#define FMT_ZU "%zu"
#endif

and use this macro when needed. It will always work, even with old versions of Visual Studio

and if there is a warning with gcc about %I being not ISO, add -Wno-pedantic-ms-format to the gcc options