Re: GNU make release candidate 4.1.90 available for download

On 05/02/2016 01:56 AM, Paul Smith wrote:
> On Tue, 2016-04-26 at 17:14 +0200, h.becker wrote:
>> cc: Warning: main.c, line 2628: In this statement, the referenced type
>> of the pointer value
>> "(switches[i].long_name==0?"":switches[i].long_name)" is const, but 
>> the referenced type of the target of this assignment is not.
>> (notconstqual)
>>       long_options[i].name = (switches[i].long_name == 0 ? "" :
>> ------^
> 
> Hm.  This must mean your compiler on this system doesn't define
> __STDC__.

Hm, sort of. When there is no option to select any standard, the default
is a relaxed ANSI language mode, accepting standard ANSI C89 and C99
features. This sets the macro __STDC__ to 0. So it is defined, however
in getopt.h it is checked whether __STDC__ is defined and it is non-zero
(then the type qualifier "const" is attached).

If I select strict ANSI C89 language mode, I get a lot of informational
messages like

cc: Info: makeint.h, line 548: In this declaration, type "unsigned long
long" is a new feature in C99. (longlongtype)
const char *vpath_search (const char *file, FILE_TIMESTAMP *mtime_ptr,
--------------------------------------------^

and the already mentioned errors for "for loops" like

cc: Error: variable.c, line 1466: Missing ";". (nosemi)
          for (unsigned int count = 1; *p != '\0'; ++p)
---------------^

> I'd prefer to not worry about this for now: if/when I update the version
> of getopt that comes with GNU make to use the latest one from gnulib
> this issue will go away.

That's OK with me. I just mentioned it in case it shows in other
environments and in case someone wants to fix it. If getopt will change
anyway, then fixing it seems to be a waste of time.