This patch consolidates all the non cancellable write calls to use
the __write_nocancel identifier. For non cancellable targets it will
be just a macro to call the default respective symbol while on Linux
will be a internal one.
Checked on x86_64-linux-gnu, x86_64-linux-gnu-x32, and i686-linux-gnu.
* sysdeps/generic/not-cancel.h (write_not_cancel): Remove macro.
(__write_nocancel): New macro.
* sysdeps/unix/sysv/linux/not-cancel.h (__write_nocancel):
Rewrite as a function prototype.
(write_not_cancel): Remove macro.
* sysdeps/unix/sysv/linux/write.c (__write_nocancel): New function.
* gmon/gmon.c (ERR): Replace write_not_cancel with __write_nocancel.
(write_gmon): Likewise.
* libio/fileops.c (_IO_new_file_write): Likewise.
* login/utmp_file.c (pututline_file): Likewise.
(updwtmp_file): Likewise.
* stdio-common/psiginfo.c (psiginfo): Likewise.
* sysdeps/posix/spawni.c (__spawni_child): Likewise.
* sysdeps/unix/sysv/linux/gethostid.c (sethostid): Likewise.
* sysdeps/unix/sysv/linux/libc_fatal.c (backtrace_and_maps):
Likewise.
* sysdeps/unix/sysv/linux/pthread_setname.c (pthread_setname_np):
Likewise.
This patch consolidates all the non cancellable read calls to use
the __read_nocancel identifier. For non cancellable targets it will
be just a macro to call the default respective symbol while on Linux
will be a internal one.
Also, since it is used on libcrypto it is also exported in GLIBC_PRIVATE
namespace.
Checked on x86_64-linux-gnu, x86_64-linux-gnu-x32, and i686-linux-gnu.
* sysdeps/generic/not-cancel.h (read_not_cancel): Remove macro.
(__read_nocancel): New macro.
* sysdeps/unix/sysv/linux/Versions (libc) [GLIBC_PRIVATE]: Add
__read_nocancel.
* sysdeps/unix/sysv/linux/not-cancel.h (__read_nocancel): Remove
macro.
(__read_nocancel): New prototype.
* sysdeps/unix/sysv/linux/read.c (__read_nocancel): New function.
* catgets/open_catalog.c (__open_catalog): Replace read_not_cancel
with __read_nocancel.
* intl/loadmsgcat.c (read): Likewise.
* libio/fileops.c (_IO_file_read): Likewise.
* locale/loadlocale.c (_nl_load_locale): Likewise.
* login/utmp_file.c (getutent_r_file): Likewise.
(internal_getut_r): Likewise.
(getutline_r_file): Likewise.
* sysdeps/unix/sysv/linux/fips-private.h (fips_enable_p): Likewise.
* sysdeps/unix/sysv/linux/gethostid.c (gethostid): Likewise.
* sysdeps/unix/sysv/linux/getloadavg.c (getloadavg): Likewise.
* sysdeps/unix/sysv/linux/getlogin_r.c (__getlogin_r_loginuid):
Likewise.
* sysdeps/unix/sysv/linux/getsysstats.c (next_line): Likewise.
* sysdeps/unix/sysv/linux/i386/smp.h (is_smp_system): Likewise.
* sysdeps/unix/sysv/linux/ia64/has_cpuclock.c (has_cpuclock):
Likewise.
* sysdeps/unix/sysv/linux/libc_fatal.c (backtrace_and_maps):
Likewise.
* sysdeps/unix/sysv/linux/malloc-sysdep.h (check_may_shrink_heap):
Likewise.
* sysdeps/unix/sysv/linux/pthread_getname.c (pthread_getname_np):
Likewise.
* sysdeps/unix/sysv/linux/sysconf.c (__sysconf): Likewise.
This commit puts all libio vtables in a dedicated, read-only ELF
section, so that they are consecutive in memory. Before any indirect
jump, the vtable pointer is checked against the section boundaries,
and the process is terminated if the vtable pointer does not fall into
the special ELF section.
To enable backwards compatibility, a special flag variable
(_IO_accept_foreign_vtables), protected by the pointer guard, avoids
process termination if libio stream object constructor functions have
been called earlier. Such constructor functions are called by the GCC
2.95 libstdc++ library, and this mechanism ensures compatibility with
old binaries. Existing callers inside glibc of these functions are
adjusted to call the original functions, not the wrappers which enable
vtable compatiblity.
The compatibility mechanism is used to enable passing FILE * objects
across a static dlopen boundary, too.
Both of "_IO_UNBUFFERED" and "_IO_LINE_BUF" are the bit flags, but I
find there are some codes looks like "_IO_LINE_BUF+_IO_UNBUFFERED",
while some codes are "_IO_LINE_BUF|_IO_UNBUFFERED".
I think the former is not good, even though the final result is same.
POSIX allows applications to switch file handles when a read results
in an end of file. Unset the cached offset at this point so that it
is queried again.
Currently we seek to end of file if there are unflushed writes or the
stream is in write mode, to get the current offset for writing in
append mode, which is the end of file. The latter case (i.e. stream
is in write mode, but no unflushed writes) is unnecessary since it
will only happen when the stream has just been flushed, in which case
the recorded offset ought to be reliable.
Removing that case lets ftell give the correct offset when it follows
an ftruncate. The latter truncates the file, but does not change the
file position, due to which it is permissible to call ftell without an
intervening fseek call.
Tested on x86_64 to verify that the added test case fails without the
patch and succeeds with it, and that there are no additional
regressions due to it.
[BZ #17647]
* libio/fileops.c (do_ftell): Seek only when there are
unflushed writes.
* libio/wfileops.c (do_ftell_wide): Likewise.
* libio/tst-ftell-active-handler.c (do_ftruncate_test): New
test case.
(do_one_test): Call it.
Prior to the 2.20 release, the function was just changed to fail
unconditionally, in commit a1a6a401ab.
This commit removes the function completely, including gconv bits
which depend on it.
This changes the gconv ABI, which is not a public interface.
The offset computation in write mode uses the fact that _IO_read_end
is kept in sync with the external file offset. This however is not
true when O_APPEND is in effect since switching to write mode ought to
send the external file offset to the end of file without making the
necessary adjustment to _IO_read_end.
Hence in append mode, offset computation when writing should only
consider the effect of unflushed writes, i.e. from _IO_write_base to
_IO_write_ptr.
The wiki has a detailed document that describes the rationale for
offsets returned by ftell in various conditions:
https://sourceware.org/glibc/wiki/File%20offsets%20in%20a%20stdio%20stream%20and%20ftell
The ftell implementation was made conservative to ensure that
incorrectly cached offsets never affect it. However, this causes
problems for append mode when a file stream is rewound. Additionally,
the 'clever' trick of using stat to get position for append mode files
caused more problems than it solved and broke old behavior. I have
described the various problems that it caused and then finally the
solution.
For a and a+ mode files, rewinding the stream should result in ftell
returning 0 as the offset, but the stat() trick caused it to
(incorrectly) always return the end of file. Now I couldn't find
anything in POSIX that specifies the stream position after rewind()
for a file opened in 'a' mode, but for 'a+' mode it should be set to
0. For 'a' mode too, it probably makes sense to keep it set to 0 in
the interest of retaining old behavior.
The initial file position for append mode files is implementation
defined, so the implementation could either retain the current file
position or move the position to the end of file. The earlier ftell
implementation would move the offset to end of file for append-only
mode, but retain the old offset for a+ mode. It would also cache the
offset (this detail is important). My patch broke this and would set
the initial position to end of file for both append modes, thus
breaking old behavior. I was ignorant enough to write an incorrect
test case for it too.
The Change:
I have now brought back the behavior of seeking to end of file for
append-only streams, but with a slight difference. I don't cache the
offset though, since we would want ftell to query the current file
position through lseek while the stream is not active. Since the
offset is moved to the end of file, we can rely on the file position
reported by lseek and we don't need to resort to the stat() nonsense.
Finally, the cache is always reliable, except when there are unflished
writes in an append mode stream (i.e. both a and a+). In the latter
case, it is safe to just do an lseek to SEEK_END. The value can be
safely cached too, since the file handle is already active at this
point. Incidentally, this is the only state change we affect in the
file handle (apart from taking locks of course).
I have also updated the test case to correct my impression of the
initial file position for a+ streams to the initial behavior. I have
verified that this does not break any existing tests in the testsuite
and also passes with the new tests.
The cached offset is reliable to use in ftell when the stream handle
is active. We can consider a stream as being active when there is
unflushed data. However, even in this case, we can use the cached
offset only when the stream is not being written to in a+ mode,
because this case may have unflushed data and a stale offset; the
previous read could have sent it off somewhere other than the end of
the file.
There were a couple of adjustments necessary to get this to work.
Firstly, fdopen now ceases to use _IO_attach_fd because it sets the
offset cache to the current file position. This is not correct
because there could be changes to the file descriptor before the
stream handle is activated, which would not get reflected.
A similar offset caching action is done in _IO_fwide, claiming that
wide streams have 'problems' with the file offsets. There don't seem
to be any obvious problems with not having the offset cache available,
other than that it will have to be queried in a subsequent
read/write/seek. I have removed this as well.
The testsuite passes successfully with these changes on x86_64.
ftell semantics are distinct from fseek(SEEK_CUR) especially when it
is called on a file handler that is not yet active. Due to this
caveat, much care needs to be taken while modifying the handler data
and hence, this first iteration on separating out ftell focusses on
maintaining handler data integrity at all times while it figures out
the current stream offset. The result is that it makes a syscall for
every offset request.
There is scope for optimizing this by caching offsets when we know
that the handler is active. A simple way to find out is when the
buffers have data. It is not so simple to find this out when the
buffer is empty without adding some kind of flag.
Partially revert commits 2b766585f9 and
de2fd463b1, which were intended to fix BZ#11741
but caused another, likely worse bug, namely that fwrite() and fputs() could,
in an error path, read data beyond the end of the specified buffer, and
potentially even write this data to the file.
Fix BZ#11741 properly by checking the return value from _IO_padn() in
stdio-common/vfprintf.c.
In BZ #12724, partial support for POSIX 2008 fclose behavior was added.
Since it isn't entirely conforming to the spec, some applications are
known to be breaking in this intermediate state. So revert the partial
support until we can get things fully implemented.
This reverts commit fcabc0f8b1.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
fopen should set the FD_CLOEXEC flag if requested evenif the kernel does
not support an aotmic operation.
freopen should reuse the file descriptor for the stream. This is
especially important for calls to change the standard streams (stin,
stdout, stderr).
