In such cases return ENOMEM. This is a limitation of our
implementation, alternatively you may consider getline(3).
Differential Revision: https://reviews.freebsd.org/D442 (Partial)
Obtained from: Apple Inc. (Libc 997.90.3)
Relnotes: yes
POSIX.1-2008 requires that successful completion simply return a
non-negative integer. We have regularly returned a constant value.
Another, equally valid, implementation convention implies returning
the number of bytes written.
Adopt this last convention to be in line with what Apple's libc
does. POSIX also explicitly notes:
Note that this implementation convention cannot be adhered to for strings
longer than {INT_MAX} bytes as the value would not be representable in the
return type of the function. For backwards-compatibility, implementations
can return the number of bytes for strings of up to {INT_MAX} bytes, and
return {INT_MAX} for all longer strings.
Developers shouldn't depend specifically on either convention but
the change may help port software from Apple.
Differential Revision: https://reviews.freebsd.org/D442 (Partial)
Obtained from: Apple Inc. (Libc 997.90.3 with changes)
Relnotes: yes
aligned on a int64_t boundary. However, when we allocate the array of
these structures, we use ALIGNBYTES which defaults to sizeof(int) on
arm, i386 and others. The i386 stuff can handle unaligned accesses
seemlessly. However, arm cannot. Take this into account when creating
the array of FILEs, and add some comments about why.
Differential Revision: https://reviews.freebsd.org/D4708
immediatelly as old code does, now for append modes too.
Real use case for such fallback is impossible (unless specially crafted).
2) Remove now unneded include I forgot to remove in prev. commits.
MFC after: 1 week
are aliases for the syscall stubs and are plt-interposed, to the
libc-private aliases of internally interposed sigprocmask() etc.
Since e.g. _sigaction is not interposed by libthr, calling signal()
removes thr_sighandler() from the handler slot etc. The result was
breaking signal semantic and rtld locking.
The added __libc_sigprocmask and other symbols are hidden, they are
not exported and cannot be called through PLT. The setjmp/longjmp
functions for x86 were changed to use direct calls, and since
PIC_PROLOGUE only needed for functional PLT indirection on i386, it is
removed as well.
The PowerPC bug of calling the syscall directly in the setjmp/longjmp
implementation is kept as is.
Reported by: Pete French <petefrench@ingresso.co.uk>
Tested by: Michiel Boland <boland37@xs4all.nl>
Reviewed by: jilles (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
This function is equivalent to fclose(3) function except that it
does not close the underlying file descriptor.
fdclose(3) is step forward to make FILE structure private.
Reviewed by: wblock, jilles, jhb, pjd
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D2697
* Add VCREAT flag to indicate when a new file is being created
* Add VVERIFY to indicate verification is required
* Both VCREAT and VVERIFY are only passed on the MAC method vnode_check_open
and are removed from the accmode after
* Add O_VERIFY flag to rtld open of objects
* Add 'v' flag to __sflags to set O_VERIFY flag.
Submitted by: Steve Kiernan <stevek@juniper.net>
Obtained from: Juniper Networks, Inc.
GitHub Pull Request: https://github.com/freebsd/freebsd/pull/27
Relnotes: yes
These were found by gcc 5.0 on Dragonfly BSD, however I
made no attempt to silence the false positives.
Obtained from: DragonFly (cf515c3a6f3a8964ad592e524442bc628f8ed63b)
_p and _w are adjusted to account for the partial write (if any).
However, _p and _w should not be unconditionally adjusted and should only
be changed when we actually wrote some bytes, or the accumulated accounting
error will eventually result in a heap buffer overflow.
Reported by: adrian and alfred (Norse Corporation)
Security: FreeBSD-SA-14:27.stdio
Security: CVE-2014-8611
For consistency with r268985 for fputs.c, assign iov_len
first, avoiding the cast to uio_resid (int in stdio)
from degrading the value.
We currently don't support lengths higher than INT_MAX so
this change is little more than cosmetic.
MFC after: 3 days
Check for __SAPP flag before calling sflush. This avoids
performance degradation compared to the previous approach.
Submitted by: ache
MFC after: 2 weeks
Use EBADF instead of EINVAL when working around incorrect O_ACCMODE.
Phabric: D442
Obtained from: Apple Inc. (Libc 997.90.3)
Reviewed by: jilles
MFC after: 1 week
This has small changes to what Apple uses for compliance
with SUSv3. The changes cause no secondary effects in the
gnulib tests (we pass them).
Obtained from: Apple Inc. (Libc 997.90.3 with changes)
Reviewed by: bde
Phabric: D440
Update the manpage to reflect this change.
- Always set the current position to the first null-byte when opening in append
mode. This makes the implementation compatible with glibc's. Update the test
suite.
Reported by: pho
Approved by: cognet
An execute-only fd (opened with O_EXEC) allows neither read() nor write()
and is therefore incompatible with all stdio modes. Therefore, the [EINVAL]
error applies.
Also adjust the similar check in freopen() with a NULL path, even though
this checks an fd which is already from a FILE.