Re: GCC optimizes integer overflow: bug or feature?

* Joseph S. Myers: On Tue, 19 Dec 2006, Florian Weimer wrote: * Paolo Bonzini: Interesting read. I agree with the proposed fix; however, note that GCC does not make the result of overflowing signed left-shifts undefined, exactly because in this case the overflow is relied upon

Re: GCC optimizes integer overflow: bug or feature?

* Robert Dewar: What is (a*2)/2 optimized to? certainly it has the value a if you wrap, Huh? Isn't (INT_MAX*2)/2 negative (and thus not equal to INT_MAX) in 2-complement arithmetic?

Re: changing configure to default to gcc -g -O2 -fwrapv ...

* Andrew Pinski: If what you propose is the only way out, and there is no way to make GCC optimizers reasonable, then I believe Paul's proposal is the next option. But that still does not address the issue is that this is not just about GCC any more since autoconf can be used many

Re: changing configure to default to gcc -g -O2 -fwrapv ...

* Daniel Berlin: OTOH, people who rely on signed overflow being wraparound generally *know* they are relying on it. Given this seems to be some small number of people and some small amount of code (since nobody has produced any examples showing this problem is rampant, in which case i'm

Re: [PATCH] open: introduce O_NOSTD

. (O_CLOEXEC should have been a thread attribute, like the base path in the *_at functions. *sigh*) -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

Re: __typeof__ does not work as expected with XLC compiler on AIX 5.2

On 10/28/2016 05:13 PM, TestRealTime . wrote: Hello, I would like to report about two (probably, self-connected) bugs in the __typeof__ C function. These bugs are reproduced when I am trying to compile a simple code with XLC compiler on AIX 5.2. Please, look at the code snippets below. 1.

Re: [PATCH 2/3] scratch_buffer: new module

On 09/02/2017 01:33 AM, Paul Eggert wrote: > +AC_CHECK_FUNCS_ONCE([__libc_scratch_buffer_grow]) This configure test is invalid because __libc_scratch_buffer_grow is a GLIBC_PRIVATE symbol not part of the ABI. You really need to rename those __libc_* functions because they are in the internal

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/02/2018 07:38 PM, Paul Eggert wrote: Florian Weimer wrote: Without kernel support, a non-zero argument returns EINVAL, not ENOSYS. This mirrors what the kernel does for invalid renameat2 flags. The Gnulib renameat2 function <https://www.gnu.org/software/gnulib/MODULES.html#mod

malloca, freea are not thread-safe

The mmalloca function used to implement malloca accesses a static global array without synchronization: #define HASH_TABLE_SIZE 257 static void * mmalloca_results[HASH_TABLE_SIZE]; … mmalloca (size_t n) { … /* Enter p into the hash table. */ slot = (uintptr_t) p %

Re: malloca, freea are not thread-safe

On 01/11/2018 05:26 AM, Bruno Haible wrote: Another idea is to add some header (like the current implementation does), but instead of storing a marker only in the malloc case, store a different marker also in the alloca case. This should be done through a GCC statement expression. => Should work

Re: malloca, freea are not thread-safe

On 02/02/2018 11:10 PM, Paul Eggert wrote: This can cause problems when -fcheck-pointer-bounds is in effect, since converting a pointer to uintptr_t and back means that GCC won't connect the resulting pointer to the original and this messes up bounds checking on the result.

Re: [PROPOSED] renameatu: rename from renameat2

On 07/04/2018 04:45 AM, Paul Eggert wrote: It's looking like Glibc will add a renameat2 function that is incompatible with Gnulib renameat2; see: https://sourceware.org/ml/libc-alpha/2018-07/msg00064.html To help avoid future confusion, rename renameat2 to something else. Use the name

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 11:04 AM, Andreas Schwab wrote: On Jul 03 2018, Paul Eggert wrote: Florian Weimer wrote: Surely that's a gnulib bug because the main reason for the RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or the other race where the file exists under both the old

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 10:13 PM, Carlos O'Donell wrote: This is a good suggestion, and I think Florian should work on something going into the manual to document the behaviour. We do not have any documentation for the *at functions at present. I find it difficult to document renameat2 without

Re: new module suggestion: fprintftime-check

* Bruno Haible: > [CCing Florian Weimer. > Florian, the thread started at > https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ] > > Assaf Gordon wrote: >> The comment even says: >>/* Unknown format; output the format, including the '%', >

Re: new module suggestion: fprintftime-check

* Bruno Haible: > Florian Weimer wrote: >> The standards do not provide a way to report errors for malformed format >> strings. I think the current behavior is acceptable, all things >> considered. > > OK, then I'm fine with Assaf's approach to create a new, separat

Re: closed file descriptors on HP-UX

* Bruno Haible: > Oh well. Then it's even POSIX compliant. But HP-UX (and possibly > Windows) is the only platform where things are really like this - > otherwise we would have seen more platforms where the diffutils > 'new-file' test fails. glibc does this as well if the process underwent an

Re: [RFC] Adding a real HashTable implementation to gnulib

* Tim Rühsen: > But I still wonder why > > - nested functions need an executable stack (why does the code have to > be run on the stack ?) The static chain pointer needs to be passed to the nest function, but most ABIs only have a code pointer. So a trampoline is written to the stack which

Re: Why does close_stdout close stdout and stderr?

* Paul Eggert: >> As long as you link libraries dynamically, any of the directly or indirectly >> linked libraries can introduce an ELF destructor or atexit() handler anytime, > > I don't see any way around this problem in general with the closeout > module's current API, because when it

Re: Why does close_stdout close stdout and stderr?

* Paul Eggert: > On 5/13/19 12:00 AM, Florian Weimer wrote: >>> I don't see any way around this problem in general with the closeout >>> module's current API, because when it discovers an I/O error it calls >>> _exit, and _exit also clashes with that kind of c

Re: Why does close_stdout close stdout and stderr?

* Bruno Haible: > Florian Weimer wrote in > <https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00087.html>: >> The relevant case is where there is no error, and we do not call _exit. >> I'm worried that the current implementation introduces a use-after-free >

Re: [PATCH 1/2] copy-file-range: new module

* Paul Eggert: > +/* Emulation of copy_file_range. > + Copyright 2017-2019 Free Software Foundation, Inc. > + > + This program is free software: you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation;

Re: Why does close_stdout close stdout and stderr?

* Kamil Dudka: > On Friday, May 10, 2019 12:17:11 AM CEST Paul Eggert wrote: >> On 5/8/19 11:39 PM, Florian Weimer wrote: >> > atexit handlers run before ELF destructors (and some C++ destructors). >> > There can also be multiple such handlers. So it's not true that an

Re: Coverity false positives triggered by gnulib's implementation of base64

* Kamil Dudka: >> For example, how do you know that the reports are false positives and not >> true positives? > > I think it was obvious from my previous explanation: > > (1) You need to check (by manual review) that the source of data is really > untrusted. > > (2) You need to check (by manual

Re: Why does close_stdout close stdout and stderr?

* Paul Eggert: > Florian Weimer wrote: >>> You can achieve that "actual close call" using >>> >>>error = close(dup(fileno(stdout))); >>> >>> so you don't actually need to "fclose" if you don't want to. >>>

Re: Why does close_stdout close stdout and stderr?

* Bernhard Voelker: > On 5/6/19 9:19 PM, Florian Weimer wrote: >> How would a programmer check that close_stdout has run, to determine >> that stdout and stderr are now invalid, to avoid the memory corruption? > > lib/closeout.c:98: > "Since close_stdout is co

Why does close_stdout close stdout and stderr?

I get that error checking is important. But why not just use ferror and fflush? Closing the streams is excessive and tends to introduce use-after-free issues, as evidenced by the sanitizer workarounds. Thanks, Florian

Re: Why does close_stdout close stdout and stderr?

* Bernhard Voelker: > On 5/6/19 5:47 PM, Florian Weimer wrote: >> * Bernhard Voelker: >>> What is the problem? I mean if it is use-after-free as mentioned in >>> the first mail, then write() after fflush() without error checking via >>> another ffl

Re: Why does close_stdout close stdout and stderr?

* Florian Weimer: > * Eric Blake: > >> On 4/29/19 2:45 PM, Florian Weimer wrote: >>> I get that error checking is important. But why not just use ferror and >>> fflush? Closing the streams is excessive and tends to introduce >>> use-after-free issues, as

Re: Why does close_stdout close stdout and stderr?

* Bernhard Voelker: > On 5/6/19 2:05 PM, Florian Weimer wrote: >>>> On 4/29/19 2:45 PM, Florian Weimer wrote: >>>>> I get that error checking is important. But why not just use ferror and >>>>> fflush? Closing the streams is excessive and t

Re: Why does close_stdout close stdout and stderr?

* NeilBrown: > On Tue, May 07 2019, Bruno Haible wrote: > >> Assaf Gordon wrote: >>> 4. >>> "fflush" instead of "fclose" seems to work OK, but I do not know >>> if there are other side effects: >>> >>>$ ./aa stdout fflush > /dev/full && echo ok || echo error >>>aa: fflush failed: No

Re: [PATCH 1/2] copy-file-range: new module

* Bruno Haible: > Pádraig Brady wrote: >> https://sourceware.org/ml/libc-alpha/2019-06/msg00873.html > > In the NEWS entry, Florian writes: > >Applications which use the >copy_file_range function will have to be run on kernels which implement >the copy_file_range system call. > > I

Re: accept4 and SOCK_NONBLOCK

* Richard W. M. Jones: > As for why accept4 is being replaced at all, the only reference to it > in config.log is: > > configure:25630: checking whether accept4 is declared > configure:25630: gcc -c -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2

Re: accept4 and SOCK_NONBLOCK

* Richard W. M. Jones: > On Tue, Aug 20, 2019 at 05:37:58PM +0200, Florian Weimer wrote: >> * Richard W. M. Jones: >> >> > As for why accept4 is being replaced at all, the only reference to it >> > in config.log is: >> > >> > co

[PATCH] wctob: mbtowc is declared in

* m4/wctob.m4 (gl_FUNC_WCTOB): Include . --- m4/wctob.m4 | 1 + 1 file changed, 1 insertion(+) diff --git a/m4/wctob.m4 b/m4/wctob.m4 index 05c1237ee..90de3e8ad 100644 --- a/m4/wctob.m4 +++ b/m4/wctob.m4 @@ -81,6 +81,7 @@ int main () included before . */ #include #include +#include

Re: GNUlib unicode encoding causes smart quotes to be displayed in program's output

* Tim Rühsen: > On 12/5/19 4:12 PM, Wes Hurd wrote: >> Hi, >> >> It seems GNUlib quote encoding goes to Unicode smart quotes, which causes >> command-line program output to be in smart quotes. >> Smart quotes are dangerous for programmers and technical users, and should >> be avoided in program

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

* Paul Eggert: > On 1/22/20 2:05 PM, Rich Felker wrote: >> I think we're approaching a consensus that glibc should fix this too, >> so then it would just be gnulib matching the fix. > > I installed the attached patch to Gnulib in preparation for the upcoming > glibc fix. The patch causes

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

* Rich Felker: > Note that in any case, musl's lchmod/fchmodat is not affected since it > always refuses to change symlink modes; I did this because I was > worried that chmod on the magic symlink in /proc might pass through > not just to the symlink it refers to, but to the symlink target if one

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

* Paul Eggert: > On 3/10/20 12:30 PM, Florian Weimer wrote: > >> Is the concern here that >> you would get a different mode from the requested one if you use >> umask+mknod and not mknod+some form of chmod? > > Yes. See: > > https://bugs.gnu.org/14371 Wro

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

* Paul Eggert: > On 3/10/20 12:30 PM, Florian Weimer wrote: >> The glibc implementation needs /proc to avoid the race. There is no >> way around that, otherwise we introduce a security vulnerability. > > It is unfortunate that we have dueling paranoia here. coreutils mk

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

* Pádraig Brady: > On 09/03/2020 18:51, Paul Eggert wrote: >> On 3/9/20 10:30 AM, Pádraig Brady wrote: >> >>> A very similar "ENOTSUP" problem is being reported with coreutils-8.32 >>> with `mknod -m 666 /dev/random c 1 8` when trying to build Fedora >>> rawhide in a chroot. >>>

Re: Relicence explicit_bzero to GPL2+/LGPL3 dual

* Bastien ROUCARIES: > Could be possible to relicence this module under dual GPL2+ LGPL3 licence? > > Code is from glibc thus LGPL2+ and it will be useful for some program > like fwknop Isn't this implied by LGPL2+? Thanks, Florian

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

* Pádraig Brady: > On 10/03/2020 11:52, Florian Weimer wrote: >> * Pádraig Brady: >> >>> On 09/03/2020 18:51, Paul Eggert wrote: >>>> On 3/9/20 10:30 AM, Pádraig Brady wrote: >>>> >>>>> A very similar "ENOTSUP" problem is

Undefined behavior in lib/canonicalize-lgpl.c

We have received a report that the glibc realpath implementation exhibits undefined behavior: In gnulib, the code is in lib/canonicalize-lgpl.c: 234 if (!ISSLASH (dest[-1])) 235 *dest++ = '/'; 236

Use-after-free in test-perror2, test-strerror_r

The problem is visible with glibc 2.32 under valgrind: ==20== Invalid read of size 1 ==20==at 0x483DAB4: strcmp (vg_replace_strmem.c:847) ==20==by 0x109414: main (test-perror2.c:84) ==20== Address 0x4a1a3d0 is 0 bytes inside a block of size 17 free'd ==20==at 0x483A9F5: free

Re: new module 'aligned-malloc'

* Paul Eggert: > On 7/21/20 8:51 AM, Florian Weimer wrote: >> The official aligned_alloc produces pointers compatible with free. >> This module cannot do that. > > I don't see why not, at least on platforms of interest to Gnulib. On > systems that provide no native way to

Re: [musl] Building Bison 3.7 with musl (was Re: portability issues with unicodeio)

* Bruno Haible: > Yes and no. The code is not making assumptions about a particular iconv() > implementation. But it needs to distinguish two categories of replacements > done by iconv(): > - those that are harmless (for example when replacing a Unicode TAG > character U+E00xx with an empty

Re: /*unsigned*/ int level3 in gen-uni-tables.c

* Bruno Haible: >> This kind of narrowing initialization is no longer valid C++. > > Indeed, GCC 10.2.0 and clang give errors about this code when uses as C++ > code: > > $ gcc -Wall -O -S -x c++ foo.c > foo.c:156:1: error: narrowing conversion of '4294967295' from 'unsigned int' > to 'int'

/*unsigned*/ int level3 in gen-uni-tables.c

gen-uni-tables.c produces types like this: struct { int header[1]; int level1[2]; short level2[2 << 7]; /*unsigned*/ int level3[16 << 4]; } Why is the unsigned commented out? Some of the constants are so large that they are treated as unsigned ints. This kind of narrowing

Re: Module with preprocessor utilities

* Marc Nieper-Wißkirchen: > Am Fr., 24. Juli 2020 um 10:05 Uhr schrieb Florian Weimer > : > >> It's still a candidate for an RFE. Martin Sebor has been working on >> such warnings. I'm going to talk to him. > > It may also be useful for optimizations because the comp

Re: new module 'aligned-malloc'

* Paul Eggert: > On 7/22/20 12:13 AM, Florian Weimer wrote: >> I don't think it will work. Try to get an allocation of 4096 bytes with >> 4096 bytes alignment using glibc malloc this way. > > That's just a mental exercise since glibc malloc already has > aligned_alloc,

Re: Missing '_Noreturn'

* Paul Eggert: > On 7/26/20 3:10 PM, Gisle Vanem wrote: >> Here's an error though: >> >>   test-dfa-match-aux.c >>   test-dfa-match-aux.c(39): error C2381: 'dfawarn': redefinition; >>   '__declspec(noreturn)' or '[[noreturn]]' differs >>   lib\dfa.h(125): note: see declaration of 'dfawarn' >

Re: Module with preprocessor utilities

* Marc Nieper-Wißkirchen: > Am Fr., 24. Juli 2020 um 08:53 Uhr schrieb Florian Weimer > : > >> * Bruno Haible: > >> > (This is with gcc 10.1.0.) >> > >> > clang, OTOH, produces warnings for both foo1 and foo2. >> > >> > But I won'

Re: new module 'aligned-malloc'

* Paul Eggert: > Also, how about naming the new module 'aligned-alloc' and having it > implement aligned_alloc? That would make for more-seamless > integration. The official aligned_alloc produces pointers compatible with free. This module cannot do that. Thanks, Florian

Re: new module 'aligned-malloc'

* Paul Eggert: > On 7/23/20 5:24 AM, Florian Weimer wrote: >> Ah, 4096 is too small. >> >> For large allocations (above the mmap threshold), what happens in the >> example is that the process VMA limit is eventually exhausted, at which >> malloc falls back to sbrk

Re: Optimize three-valued comparison between integers

* Bruno Haible: > A comment in Luca Saiu 'jitter' project [1] brought my attention to 3-valued > comparison and the book "Hacker's Delight". > > === > int sign1 (long n1, long n2) > { > return (n1 > n2 ? 1 : n1 < n2 ? -1 : 0); > } > > int sign2 (long

Re: Module with preprocessor utilities

* Bruno Haible: > Also, if that's the intent of the syntax, it has been overlooked by the > GCC developers. See: > > decl.c > #include > > extern void foo1 (double x [static 1]); > extern void foo2 (double x []) __attribute__

Re: improve clang support (35)

* Bruno Haible: > clang (at least in version >= 4), in C++ mode, supports the 'throw > ()' declaration on functions, and uses it to optimize try/catch > statements at the caller site. I think throw() has been removed from C++20:

Re: rcs configure hang

* Kelly Wang: > Hi Florian, > > Thanks for checking. Here is my system info: > % uname -a > Linux sjc-ads-7913 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Wed Nov 27 01:11:44 UTC > 2019 x86_64 unknown unknown GNU/Linux > % rpm -q kernel > kernel-4.18.0-80.el8.x86_64 > kernel-4.18.0-147.3.1.el8_1.x86_64 >

Re: [PATCH 2/5] Import idx.h from gnulib

* Adhemerval Zanella via Libc-alpha: > diff --git a/include/idx.h b/include/idx.h > new file mode 100644 > index 00..ad7d31a2bc > --- /dev/null > +++ b/include/idx.h > @@ -0,0 +1,113 @@ > +/* A type for indices and sizes. > + > + Copyright (C) 2020 Free Software Foundation, Inc. > + > +

Re: [PATCH v3 5/6] support: Add support_small_thread_stack_size

* Adhemerval Zanella via Libc-alpha: > It returns the minimum stack size large enough to cover most internal > glibc stack usage. Looks okay to me.

Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch

caledef and the locale sources, so it's easy to build custom locales), but other GNU components had to be patched. > Florian Weimer wrote: >> There is a Shift-JIS variant which is ASCII-transparent (Windows-31J, >> it's also specified by WhatWG/HTML5), so from a glibc point of view, it

Re: [PATCH 1/5] posix: Sync regex code with gnulib

* Adhemerval Zanella via Libc-alpha: > Paul, this seemed to a common pattern scatter on multiple file in gnulib. > Wouldn't be better to consolidate it on cdefs.h? gnulib shouldn't be using cdefs.h on glibc systems, so I think a separate header would be needed. Thanks, Florian -- Red Hat GmbH,

Re: [PATCH 1/5] posix: Sync regex code with gnulib

* Adhemerval Zanella: > On 19/01/2021 13:52, Florian Weimer wrote: >> * Adhemerval Zanella via Libc-alpha: >> >>> Paul, this seemed to a common pattern scatter on multiple file in gnulib. >>> Wouldn't be better to consolidate it on cdefs.h? >> >&g

Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch

* Paul Eggert: > By the way, how important is it to support awful encodings like > shift-JIS that contain bytes that look like '\'? If we don't have to > support these encodings any more, things get a bit easier. (Asking for > a friend. :-) There is a Shift-JIS variant which is

Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch

* Adhemerval Zanella via Libc-alpha: > It removes the alloca usage on the string convertion to wide characters > before calling the internal function. We have a downstream-only patch to fall back the single byte handling in case of multibyte decoding failure. Basically it's a quick hack to fix

Re: clang++ 11 compilation issues

* Alexandre Duret-Lutz: > (1) lib/argmatch.h includes lib/gettext.h which fails as follows > >> clang++ -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../buddy/src -I../lib -I../lib >> -W -Wall -Werror -Wint-to-void-pointer-cast -Wzero-as-null-pointer-constant >> -Wcast-align -Wpointer-arith

glibc support for allocating alternate signal stacks

I've posted a proposal to provide an interface for allocating stacks in glibc: Misc: Add and the cstack_* family of functions This is based on our observation that many applications use static buffers for alternate stacks,

Re: an old fstatat bug

* Paul Eggert: >> +This function does not fail when the second argument is an empty string >> +on some platforms: >> +glibc 2.7. > > If AT_EMPTY_PATH is specified, fstatat is documented to behave that > way with an empty string. So possibly this behavior is also > kernel-dependent (AT_EMPTY_PATH

Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

* Paul Eggert: > On 7/7/21 1:45 AM, Florian Weimer wrote: > >> Y2038 support requires recompilation. If you are able to do that, why >> not recompile for a 64-bit architecture? > > Doesn't this argue against _TIME_BITS=64 in general? It seems to be > saying that one s

Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

* Paul Eggert: > In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit, > defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit. > Apps must define both macros. Gnulib applications that use either > the largefile or the year2038 modules will want this behavior; >

Re: Undefined use of weak symbols in gnulib

* Michael Hudson-Doyle: > Did this thread ever reach a conclusion? I'm testing a snapshot of > glibc 2.34 in ubuntu and running into this issue -- bison segfaults on > startup on ppc64el. For us it got resolved with a binutils fix: commit b293661219c36e72acb80502a86b51160bb88cfd Author: Alan

Re: Undefined use of weak symbols in gnulib

* Matthias Klose: > On 7/12/21 5:03 PM, Florian Weimer via Binutils wrote: >> * Michael Hudson-Doyle: >> >>> Did this thread ever reach a conclusion? I'm testing a snapshot of >>> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on >>>

Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

* Bruno Haible: > Hi Florian, > >> > In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit, >> > defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit. >> > Apps must define both macros. Gnulib applications that use either >> > the largefile or the year2038 modules

Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

* Bruno Haible: > Florian Weimer wrote: > >> 64-bit file offsets enabled real use cases. > > Year 2038 is also a real use-case. It is not so rare that machines are > being used for 15 years. (I still occasionally use a 14-years old > computer, and had a washing mach

Undefined use of weak symbols in gnulib

lib/glthread/lock.h has this: | /* The way to test at runtime whether libpthread is present is to test |whether a function pointer's value, such as _mutex_init, is |non-NULL. However, some versions of GCC have a bug through which, in |PIC mode, != NULL always evaluates to true if

Re: Undefined use of weak symbols in gnulib

* Paul Eggert: > On 4/26/21 10:53 PM, Florian Weimer via Libc-alpha wrote: >> This will become an urgent issue with glibc 2.34, which defines >> pthread_mutexattr_gettype unconditionally. Certain gnulib modules will >> stop working until the binaries are relinked. >

Re: Undefined use of weak symbols in gnulib

* Andreas Schwab: > On Apr 27 2021, Florian Weimer via Binutils wrote: > >> I think we can provide an libBrokenGnulib.so preload module which >> defines pthread_mutexattr_gettype to zero (as an absolute address), so >> there is a kludge to keep old binaries wor

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: >> I spent today on coming up with a workaround in glibc. > > These are the workarounds I can see: > - Delay the planned changes in glibc by 5 years or so, to minimize > the number of binaries out there that would crash. (Probably not what > you want.) Nah, those

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: > You write: >> Dynamic linking with weak symbols is not very well-defined. ... >> the code will crash if pthread_mutexattr_gettype is ever defined. > > In which situations will it crash? > > (a) when the code is in an executable, that gets linked with '-lpthread' > and

Re: Undefined use of weak symbols in gnulib

* H. J. Lu via Libc-alpha: > Alan extended the fix to PPC: > > commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de > Author: Alan Modra > Date: Wed Apr 19 01:26:57 2017 +0930 > > Implement -z dynamic-undefined-weak > > -z nodynamic-undefined-weak is only implemented for x86. (The sparc >

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: > Hi Florian, > >> Here's a fairly representative test case, I think. >> >> #include >> #include >> >> extern __typeof (pthread_key_create) __pthread_key_create __attribute__ >> ((weak)); >> extern __typeof (pthread_once) pthread_once __attribute__ ((weak)); >> >> void >> f1

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: > So, in the normal cases (link with '-lpthread', link without '-lpthread', > and even with dlopen()), everything will work fine. The only problematic > case thus is the the use of LD_PRELOAD. Right? LD_PRELOAD and glibc 2.34 as originally planned. > I think few packages in a

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: > I'm confused again. Are you saying that the crash will occur when old > binaries are being used with glibc 2.34 also *without* LD_PRELOAD? Yes, that's how we discovered it. And really is a problem. Thanks, Florian

Re: [PATCH 2/2] posix: Remove alloca usage for internal fnmatch implementation

* Adhemerval Zanella via Libc-alpha: > -else if (*p == L_('|')) > +else if (*p == L_(')') || *p == L_('|')) >{ > if (level == 0) >{ > -NEW_PATTERN; > -startp = p + 1; > +size_t slen = opt == L_('?') || opt == L_('@') > +

Re: [PATCH 1/2] posix: Falling back to non wide mode in case of encoding error [BZ #14185]

* Adhemerval Zanella via Libc-alpha: > +static int > +fnmatch_convert_to_wide (const char *str, struct scratch_buffer *buf, > + size_t *n) > +{ > + mbstate_t ps; > + memset (, '\0', sizeof (ps)); > + > + size_t nw = buf->length / sizeof (wchar_t); > + *n = strnlen

Re: [PATCH 1/2] posix: Falling back to non wide mode in case of encoding error [BZ #14185]

* Florian Weimer via Libc-alpha: > * Adhemerval Zanella via Libc-alpha: > >> +static int >> +fnmatch_convert_to_wide (const char *str, struct scratch_buffer *buf, >> + size_t *n) >> +{ >> + mbstate_t ps; >> + memset (, '\0'

Re: [PATCH 2/2] posix: Remove alloca usage for internal fnmatch implementation

* Adhemerval Zanella: > On 08/03/2021 09:59, Florian Weimer wrote: >> * Adhemerval Zanella via Libc-alpha: >> >>> -else if (*p == L_('|')) >>> +else if (*p == L_(')') || *p == L_('|')) >>>{ >>> if (level

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

* DJ Delorie: > diff --git a/lib/glob.c b/lib/glob.c > index 22c459574..d0521bb4a 100644 > --- a/lib/glob.c > +++ b/lib/glob.c > @@ -1381,7 +1381,26 @@ glob_in_dir (const char *pattern, const char > *directory, int flags, >if (flags & GLOB_ONLYDIR) > switch

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

* DJ Delorie: > Florian Weimer writes: >>> + if (fullpath == NULL) >>> + /* This matches old behavior wrt DT_UNKNOWN. */ >>> + break; >> >> Shouldn't this report memory allocation failure to the call

Re: Undefined use of weak symbols in gnulib

* Bruno Haible: > Florian Weimer wrote on 2021-04-28: >> However, you should really remove those weak symbol >> hacks. They won't have any effect for glibc 2.34 > > I'm trying to do this now. But what is the right condition? > > 1) I understand that it's only for g

Re: Undefined use of weak symbols in gnulib

* Joseph Myers: > On Sat, 17 Jul 2021, Bruno Haible wrote: > >> 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO. >>How about not defining LIBPTHREAD_SO, since linking with it is supposed >>to be a no-op in these newer glibc versions? > > I think LIBPTHREAD_SO is really for use

Re: xmalloc calling undeclared xalloc_die function

* Bruno Haible: > Florian Weimer wrote: >> lib/xmalloc.c contains this function definition, unconditionally: >> >> static void * _GL_ATTRIBUTE_PURE >> nonnull (void *p) >> { >> if (!p) >> xalloc_die (); >> return p; >

Hidden visibility for obstack symbols

Someone reported that ls in coreutils exported _obstack* symbols. This is because ls uses the obstack module from gnulib (I assume). Due to the way ELF linking works by default, this promotes the symbols to global visibility, so that there is a single definition in the entire process. This is

Re: -Wlto-type-mismatch warning in error()

* Bruno Haible: > Gavin Smith wrote: >> I expect it is not a gnulib problem. install-info/install-info.c declares >> a function called "error" which appears to clash with a function from glibc. >> ... The "error" module is brought in by "xalloc" (which we >> ask for explicitly). > > Yes, I think

xmalloc calling undeclared xalloc_die function

lib/xmalloc.c contains this function definition, unconditionally: static void * _GL_ATTRIBUTE_PURE nonnull (void *p) { if (!p) xalloc_die (); return p; } But the declaration of xalloc_die in lib/xalloc.h is conditional: #if GNULIB_XALLOC_DIE /* This function is

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

* Bruno Haible: > But when it comes to scratch_buffer or dynarray code, this week's experience > has shown that we cannot count on as much care for Gnulib users. Rather, > the mindset on the glibc side seems to be: "This is glibc internal code; > we can refactor / reshuffle / trim it as we like."

Re: On time64 and Large File Support

* Sam James: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> >> * Sam James: >> >>> In Gentoo, we've been planning out what we should do for time64 on >>> glibc [0] and concluded that we need some support in glibc for a newer >>> optio

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

* Paul Eggert: > What problems do you see with the interfaces, and are there efforts to > come up with a better API? The need is there in GNU apps, each of > which tends to roll its own code here. dynarray has an aliasing violation in its implementation. The embedded pointer should be void *

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

* Paul Eggert: > On 2022-11-14 04:41, Aaron Ballman wrote: >> it's generally a problem when autoconf relies on invalid >> language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful

  1   2   >