Paul Eggert <eggert@xxxxxxxxxxx> 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
