Hi Wookey,
> > in Gentoo Linux we want to change our CHOST triplets for 32-bit glibc
> > systems that use
> > 64-bit time_t, since this is technically an ABI change which breaks binary
> > compatibility [1].
>
> > * In an ideal world this change would be synchronized across distributions.
> >
>
> FWIW, yocto/openembedded have also done the same and offered a distro
> setting to the users
> to select 32bit time_t if they wished to but defaulted to 64bit time_t.
In case of Openembedded, which (as far as I understand) mostly offers
complete system images for download or build, I might ha
One possible improvement would be to append "t32" if you want 32-bit
time_t, instead of appending "t64" for 64-bit time_t. That way, people
wouldn't be stuck with appending that confusing "t64" for the
foreseeable future, and only specialists concerned with 32-bit time_t
would need to know abou
> One possible improvement would be to append "t32" if you want 32-bit
> time_t, instead of appending "t64" for 64-bit time_t.
Versioned symbols in glibc should mean that old binaries will still run (even
if they misbehave when they look at the system time), just like with most
previous ABI chan
On Thu, Sep 5, 2024 at 6:51 AM Andreas K. Huettel wrote:
>
> >
> > FWIW, yocto/openembedded have also done the same and offered a distro
> > setting to the users
> > to select 32bit time_t if they wished to but defaulted to 64bit time_t.
>
> In case of Openembedded, which (as far as I understand)
Hi Todd,
> Versioned symbols in glibc should mean that old binaries will still run (even
> if they
> misbehave when they look at the system time), just like with most previous
> ABI changes
> to libc over the years.
That is irrelevant here. glibc takes care of its own interface and is not a
> One possible improvement would be to append "t32" if you want 32-bit
> time_t, instead of appending "t64" for 64-bit time_t.
I hope you aren't earnestly proposing this worst of both worlds idea
(let's change CHOST for any system with no ABI change).
> I felt the same way about the 64-bit off
On 2024-09-05 10:03, Andreas K. Huettel wrote:
at least time64 implies largefile, so that will get sorted as side
effect.
Right, but this means the "t" in "t64" is somewhat misleading, as it's
not just about time: it also affects off_t, ino_t, etc., effects that
are in some cases more importa
Am Donnerstag, 5. September 2024, 20:20:32 CEST schrieb Paul Eggert:
> On 2024-09-05 10:03, Andreas K. Huettel wrote:
> > at least time64 implies largefile, so that will get sorted as side
> > effect.
>
> Right, but this means the "t" in "t64" is somewhat misleading, as it's
> not just about time
Snapshot gcc-12-20240905 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240905/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hello,
I'm looking at #pragma once behavior among the major C/C++ compilers as
part of a proposal paper for standardizing #pragma once. (This is
apparently a very controversial topic)
To put my question up-front: Would GCC ever be open to altering its
#pragma once behavior to bring it more in-lin
On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote:
>
> Hello,
>
> I'm looking at #pragma once behavior among the major C/C++ compilers as
> part of a proposal paper for standardizing #pragma once. (This is
> apparently a very controversial topic)
>
> To put my question up-front: Would GCC ever b
There was a recent related proposal for C23.
https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2896.htm
See also the email by Linus Torvalds referenced in
this paper.
Note that this proposal was not adopted for ISO C23.
I can't find when it was discussed, but IIRC the general
criticism was t
13 matches
Mail list logo
