IO_VTABLES_LEN is the size of the struct array in bytes, not the number
of __IO_jump_t's in the array. Drops just under 384kb from .rodata on
LP64 machines.

Fixes: 3020f72618e ("libio: Remove the usage of __libc_IO_vtables")
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Tested-by: Florian Weimer <fweimer@redhat.com>

On GNU/Hurd, O_RDWR actually is O_WRONLY|O_RDONLY, so checking through
bitness really is wrong. O_ACCMODE is there for this.

Fixes: 5324d258427f ("fileops: Don't process ,ccs= as individual mode flags (BZ#18906)")

In processing the first 7 individual characters of the mode for fopen
if ,ccs= is used those characters will be processed as well.  Stop
processing individual mode flags once a comma is encountered.  This has
the effect of requiring ,ccs= to be the last mode flag in the mode
string.  Add a testcase to check that the ,ccs= mode flag is not
processed as individual mode flags.

Reviewed-by: DJ Delorie <dj@redhat.com>

The change is meant to avoid unwanted PLT entry for the fgets_unlocked
routine when _FORTIFY_SOURCE is set.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

Move declarations from libio/bits/stdio.h to existing
libio/bits/stdio2-decl.h. This will enable future use of
__REDIRECT_FORTIFY in place of some __REDIRECT.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to
be excluded from the fortification.

On top of that:
 - some tests explicitly verify that some level of fortification works
   appropriately, we therefore shouldn't modify the level set for them.
 - some objects need to be build with optimization disabled, which
   prevents _FORTIFY_SOURCE to be used for them.

Assembler files that implement architecture specific versions of the
fortified routines were not excluded from _FORTIFY_SOURCE as there is no
C header included that would impact their behavior.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

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.

With fortification enabled, system calls return result needs to be checked,
has it gets the __wur macro enabled.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

With fortification enabled, fread calls return result needs to be checked,
has it gets the __wur macro enabled.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>