<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/libio/libioP.h, branch vdso</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/libio/libioP.h?h=vdso</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/libio/libioP.h?h=vdso'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-08-15T17:56:13Z</updated>
<entry>
<title>ungetc: Fix backup buffer leak on program exit [BZ #27821]</title>
<updated>2024-08-15T17:56:13Z</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2024-08-14T01:08:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=3e1d8d1d1dca24ae90df2ea826a8916896fc7e77'/>
<id>urn:sha1:3e1d8d1d1dca24ae90df2ea826a8916896fc7e77</id>
<content type='text'>
If a file descriptor is left unclosed and is cleaned up by _IO_cleanup
on exit, its backup buffer remains unfreed, registering as a leak in
valgrind.  This is not strictly an issue since (1) the program should
ideally be closing the stream once it's not in use and (2) the program
is about to exit anyway, so keeping the backup buffer around a wee bit
longer isn't a real problem.  Free it anyway to keep valgrind happy
when the streams in question are the standard ones, i.e. stdout, stdin
or stderr.

Also, the _IO_have_backup macro checks for _IO_save_base,
which is a roundabout way to check for a backup buffer instead of
directly looking for _IO_backup_base.  The roundabout check breaks when
the main get area has not been used and user pushes a char into the
backup buffer with ungetc.  Fix this to use the _IO_backup_base
directly.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>Revert "Allow glibc to be compiled without EXEC_PAGESIZE"</title>
<updated>2024-04-22T21:00:18Z</updated>
<author>
<name>Samuel Thibault</name>
<email>samuel.thibault@ens-lyon.org</email>
</author>
<published>2024-04-22T21:00:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=16c8dfba14ff7596ad3aea941a240f8abcdc50e6'/>
<id>urn:sha1:16c8dfba14ff7596ad3aea941a240f8abcdc50e6</id>
<content type='text'>
This reverts commit 49aa652db810ebdca3a662ebd5b0468bd08ec688.

This is still being discussed.
</content>
</entry>
<entry>
<title>Allow glibc to be compiled without EXEC_PAGESIZE</title>
<updated>2024-03-23T21:47:26Z</updated>
<author>
<name>Sergey Bugaev</name>
<email>bugaevc@gmail.com</email>
</author>
<published>2024-03-23T17:32:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=49aa652db810ebdca3a662ebd5b0468bd08ec688'/>
<id>urn:sha1:49aa652db810ebdca3a662ebd5b0468bd08ec688</id>
<content type='text'>
We would like to avoid statically defining any specific page size on
aarch64-gnu, and instead make sure that everything uses the dynamic
page size, available via vm_page_size and GLRO(dl_pagesize).

There are currently a few places in glibc that require EXEC_PAGESIZE
to be defined. Per Roland's suggestion [0], drop the static
GLRO(dl_pagesize) initializers (for now, only if EXEC_PAGESIZE is not
defined), and don't require EXEC_PAGESIZE definition for libio to
enable mmap usage.

[0]: https://mail.gnu.org/archive/html/bug-hurd/2011-10/msg00035.html

Signed-off-by: Sergey Bugaev &lt;bugaevc@gmail.com&gt;
Message-ID: &lt;20240323173301.151066-4-bugaevc@gmail.com&gt;
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2024-01-01T18:53:40Z</updated>
<author>
<name>Paul Eggert</name>
<email>eggert@cs.ucla.edu</email>
</author>
<published>2024-01-01T18:12:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=dff8da6b3e89b986bb7f6b1ec18cf65d5972e307'/>
<id>urn:sha1:dff8da6b3e89b986bb7f6b1ec18cf65d5972e307</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Always do locking when accessing streams (bug 15142, bug 14697)</title>
<updated>2023-07-03T07:55:43Z</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@suse.de</email>
</author>
<published>2018-01-30T09:16:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=af130d27099651e0d27b2cf2cfb44dafd6fe8a26'/>
<id>urn:sha1:af130d27099651e0d27b2cf2cfb44dafd6fe8a26</id>
<content type='text'>
Now that abort no longer calls fflush there is no reason to avoid locking
the stdio streams anywhere.  This fixes a conformance issue and potential
heap corruption during exit.
</content>
</entry>
<entry>
<title>libio: Remove the usage of __libc_IO_vtables</title>
<updated>2023-03-27T16:57:55Z</updated>
<author>
<name>Adhemerval Zanella Netto</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2022-12-27T21:11:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=3020f72618e4f1d7338cd42b8bc7b2813e961b5a'/>
<id>urn:sha1:3020f72618e4f1d7338cd42b8bc7b2813e961b5a</id>
<content type='text'>
Instead of using a special ELF section along with a linker script
directive to put the IO vtables within the RELRO section, the libio
vtables are all moved to an array marked as data.relro (so linker
will place in the RELRO segment without the need of extra directives).

To avoid static linking namespace issues and including all vtable
referenced objects, all required function pointers are set to weak alias.

Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>Move libc_freeres_ptrs and libc_subfreeres to hidden/weak functions</title>
<updated>2023-03-27T16:57:55Z</updated>
<author>
<name>Adhemerval Zanella Netto</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2022-12-27T21:11:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=88677348b4de73874ca7d5a47451f42880f65f07'/>
<id>urn:sha1:88677348b4de73874ca7d5a47451f42880f65f07</id>
<content type='text'>
They are both used by __libc_freeres to free all library malloc
allocated resources to help tooling like mtrace or valgrind with
memory leak tracking.

The current scheme uses assembly markers and linker script entries
to consolidate the free routine function pointers in the RELRO segment
and to be freed buffers in BSS.

This patch changes it to use specific free functions for
libc_freeres_ptrs buffers and call the function pointer array directly
with call_function_static_weak.

It allows the removal of both the internal macros and the linker
script sections.

Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>C2x scanf binary constant handling</title>
<updated>2023-03-02T19:10:37Z</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-03-02T19:10:37Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=dee2bea048b688b643a9a3b44b26ca9f7a706fe8'/>
<id>urn:sha1:dee2bea048b688b643a9a3b44b26ca9f7a706fe8</id>
<content type='text'>
C2x adds binary integer constants starting with 0b or 0B, and supports
those constants for the %i scanf format (in addition to the %b format,
which isn't yet implemented for scanf in glibc).  Implement that scanf
support for glibc.

As with the strtol support, this is incompatible with previous C
standard versions, in that such an input string starting with 0b or 0B
was previously required to be parsed as 0 (with the rest of the input
potentially matching subsequent parts of the scanf format string).
Thus this patch adds 12 new __isoc23_* functions per long double
format (12, 24 or 36 depending on how many long double formats the
glibc configuration supports), with appropriate header redirection
support (generally very closely following that for the __isoc99_*
scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes
precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU
extensions to C89 continues to get old-style GNU %a and does not get
this new feature).  The function names would remain as __isoc23_* even
if C2x ends up published in 2024 rather than 2023.

When scanf %b support is added, I think it will be appropriate for all
versions of scanf to follow C2x rules for inputs to the %b format
(given that there are no compatibility concerns for a new format).

Tested for x86_64 (full glibc testsuite).  The first version was also
tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/
tests), and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2023-01-06T21:14:39Z</updated>
<author>
<name>Joseph Myers</name>
<email>joseph@codesourcery.com</email>
</author>
<published>2023-01-06T21:08:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=6d7e8eda9b85b08f207a6dc6f187e94e4817270f'/>
<id>urn:sha1:6d7e8eda9b85b08f207a6dc6f187e94e4817270f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources</title>
<updated>2022-10-18T15:04:10Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2022-10-18T15:00:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=58548b9d689fb9bba67bdc5b59c8d2fa47f4f8ec'/>
<id>urn:sha1:58548b9d689fb9bba67bdc5b59c8d2fa47f4f8ec</id>
<content type='text'>
In the future, this will result in a compilation failure if the
macros are unexpectedly undefined (due to header inclusion ordering
or header inclusion missing altogether).

Assembler sources are more difficult to convert.  In many cases,
they are hand-optimized for the mangling and no-mangling variants,
which is why they are not converted.

sysdeps/s390/s390-32/__longjmp.c and sysdeps/s390/s390-64/__longjmp.c
are special: These are C sources, but most of the implementation is
in assembler, so the PTR_DEMANGLE macro has to be undefined in some
cases, to match the assembler style.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
</feed>
