Possible miscalculation of buffer length in png_icc_profile_error

[johnstiles-google]

Noticed a strange/misleading comment in png.c.

pos = png_safecat(message, (sizeof message), pos, "h: "); /* +2 = 116 */

The string being appended, h: , is three characters long—not two.
In practice this may be a non-issue, because the next line allows an arbitrary +79 slop factor which doesn't seem to correspond to any real limit.

/* The 'reason' is an arbitrary message, allow +79 maximum 195 */

[jbowler]

That's why I wrote safecat; people do this all the time. I.e. update a message and don't increase the length of the corresponding buffer or do the addition wrong. It's safe because this is precisely what safecat checks for (it will never overwrite the buffer).

In this case the comment error was in the original code (871b1d). The comment should be fixed some time; remarkable that so much copy editing was done including changes to the comment but one one until now noticed the words in the comment were wrong!

[johnstiles-google]

Yes, since this is safecat, the only real danger is truncation; there shouldn't be any security/UB risk.

[jbowler]

@ctruta: [libpng18] but low priority because it is safe and, anyway, maybe libpng18 could do something about the lack of i18n?

[ctruta]

I think the time to embrace a C99'ish stdlib, going forward, is long overdue.

Even if we still insist on supporting prehistoric compilers that cater to the yester-millenium (which I'm not so sure if it's a good idea or a bad one), we should at least have workarounds for pre-C99 compilers that offer basic C99 library features like snprintf. For example: we can introduce our own png_snprintf that uses snprintf where available, and _snprintf for those compilers that have it (like Visual C or Watcom C), and, seriously, pull the rug from those compilers that don't keep up with what was new a quarter-century ago.