Re: [bug-gperf] Change to size_t makes gperf 3.1 incompatible with code written for 3.0.4

[Bruno Haible]

Alvarez G. M. wrote in 
https://lists.gnu.org/archive/html/bug-gperf/2017-01/msg00004.html:

> When upgrading gperf to recent release, we've come to notice that gperf
> users usually hardcode function prototypes, as (const char *str, unsigned 
> len);
> 
> However, latest change from unsigned to size_t, even though perfectly
> reasonable, produces a mismatch between function and its prototype, so code
> written for gperf 3.0.4 output isn't able to compile using gperf 3.1 output.
> 
> I've searched on buildroot's package database and these packages require
> modifications to work with gperf 3.1:
> 
> eudev, libsvgtiny, systemd, webkitgtk, libcap, qt5webkit, kodi

The simplest way to deal with this change is
  - to change the prototype in the package's source code to use 'size_t' instead
    of 'unsigned int',
  - to document in the HACKING file that gperf 3.1 or newer is required.

Alternatively, if you really need source code that compile with newer AND
older versions of gperf, you can do some Makefile processing to detect
the declaration that gperf has generated. Like done in gnulib here: [1]

> I was wondering if gperf could possibly include a compatibility option,
> enabled by default, so that code generated maintains the old prototype and
> only uses size_t when explicitly asked for.

This would add complexity to gperf and not reduce the issue on the applications'
side. Since the world has widely adopted 64-bit CPUs, 'unsigned int' (a
32-bit type) is just the wrong type for string lengths. Continuing to use
'unsigned int' for a string length introduces the risk of bugs that can
even become security bugs. So, it is mandatory at some point to switch
to using 'size_t' instead of 'unsigned int'.

> Otherwise, I think this version could have been maybe named 4.0, so as to
> make this incompatibility clearer?

Possibly. But I went with the usual conventions, which are:
  - A bump in the major number indicates major new functionality.
  - An incompatible change is listed in the NEWS file.

Bruno

[1] 
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4be488081b917f98a2fd3e2766324043649cca6e