On Sat, Nov 12, 2022, at 4:33 PM, Zack Weinberg wrote:
> On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote:
>> Because of the concerns raised in this thread it's become clear that
>> what's in Autoconf now is too drastic, and I've proposed (though not yet
>> implemented) a change that will
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some
On 2022-11-11 07:11, Aaron Ballman wrote:
Clang doesn't require such a linker (we work with various system linkers).
As long as the system linkers continue to work as they have
traditionally worked, we're fine.
the frontend perspective, we can't tell the difference between
"trust me this
On 2022-11-11 19:45, Zack Weinberg wrote:
For anything specified by either ISO C or POSIX/XSI, I think Autoconf
probably*can* bake in an expected function prototype.
Unfortunately that won't work in general. strerror_r comes to mind
(GNU's signature disagrees with POSIX). And it's not
On 2022-11-12 06:09, Zack Weinberg wrote:
- 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?
Formerly the Autoconf documentation was inconsistent.
On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote:
> Because of the concerns raised in this thread it's become clear that
> what's in Autoconf now is too drastic, and I've proposed (though not yet
> implemented) a change that will cause AC_SYS_LARGEFILE to continue to
> not affect time_t
On 2022-11-12 12:23, Wookey wrote:
we can't just have everyone who enabled LFS sometime in the
last 20 years suddenly being forced into the time_t change (can we?)
We've done it in the past.
AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to
Autoconf. Originally it affected
Wookey writes:
> Now, I'm not yet sure if just having autoconf 2.72 will actually break
> things. AIUI, these changes only apply where LFS
> (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that
> is not the default on 32bit arches, maybe this is OK. But probably quite
> a lot
On 2022-11-12 11:15 -0800, Paul Eggert wrote:
> On 2022-11-12 10:50, Bruno Haible wrote:
> > I'm saying
> > "tiny" because we are still 15 years away, and new releases of the (not
> > many) affected packages are likely to come in the next 1-2 years.
>
> Not so "tiny", I'm afraid. My department is
On 2022-11-12 10:50, Bruno Haible wrote:
I'm saying
"tiny" because we are still 15 years away, and new releases of the (not
many) affected packages are likely to come in the next 1-2 years.
Not so "tiny", I'm afraid. My department is still running a server with
libraries and executables that
Paul Eggert wrote:
> On 2022-11-12 06:16, Zack Weinberg wrote:
> > I am going to go ahead and do this if nobody raises a concrete objection
> > within the next 24 hours.
>
> I object to a simple reversion, as this will cause problems downstream
> with Gnulib-using applications, several of which
On 2022-11-11 20:20, Wookey wrote:
It doesn't seem right to me that AC_SYS_LARGEFILE should imply
AC_SYS_YEAR2038. What is the reasoning behind that?
First, in Autoconf git AC_SYS_LARGEFILE does not imply AC_SYS_YEAR2038.
The former is willing to fall back on 32-bit time_t if 64-bit is not
On 2022-11-11 18:20, Zack Weinberg wrote:
I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
overriding the glibc maintainers. Rather, I think he was only thinking
about applications, not libraries, and only about source distribution.
No, I was thinking about libraries
On 2022-11-12 06:16, Zack Weinberg wrote:
I am going to go ahead and do this if nobody raises a concrete objection
within the next 24 hours.
I object to a simple reversion, as this will cause problems downstream
with Gnulib-using applications, several of which have already been
released
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that
On 2022-11-10 19:08 +0100, Florian Weimer wrote:
> * Zack Weinberg via Gcc:
>
> > It’s come to my attention (via https://lwn.net/Articles/913505/ and
> > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> > Clang both plan to disable several “legacy” C language features by
>
Demi Marie Obenour writes:
> On 11/10/22 15:19, Paul Eggert wrote:
>> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf
>> supported K C, C89, C99, etc. At some point (I'm not sure when),
>> Autoconf started requiring C89 or later. Is it now OK for Autoconf to
>>
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>>
Sam James writes:
>> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha
>> wrote:
>> I am honestly not sure what to do about this in the long term, but for
>> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
>> makes sense to back out change #2, only — that is,
Paul Eggert 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
20 matches
Mail list logo
