Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else.  Anyone have reasons I _shouldn't_ do that?
>
> I don't have anything other than some doc updates, which I just now
> installed (see attached).

couple of notes below

>>> Note that in autoconf git, we've also got
>>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
>>> which is going to affect time_t efforts too
>> I have not been following the y2038 work closely.  Is it going to
>> affect things in a good way or a bad way??
>
> Both. […]

(let’s leave this discussion to the other thread)

> -  and ‘false’ work anyway.  This is for compatibility with C 2023 and
> +  and ‘false’ work anyway.  This is for compatibility with C23 and

Why are you changing four-digit years to two-digit years?  I know you’re
old enough to remember Y2K :-)

>  All other headers, including all headers
>  from later revisions of the C standard, need to be tested for
> +if your program is intended to be portable to C89
>  (@pxref{Header Files}).

I don’t understand what this addition is supposed to mean.  Not all
“modern” systems supply all of the C99 headers, even now.

> -The C standard says a call @code{malloc (0)} is implementation
> +The C standard says a successful call @code{malloc (0)} is implementation
>  dependent.  It can return either @code{NULL} or a new non-null pointer.

Style nit: how can a _call_ be implementation dependent?  Suggest
something like “The C standard says that _the result of_ a successful
call _to_ @code{malloc (0)} is implementation dependent.” (underscores
just to mark additions, not part of suggested text)

zw