This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16919] recvmsg standard compliance
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 07 May 2014 17:08:02 +0000
- Subject: [Bug libc/16919] recvmsg standard compliance
- Auto-submitted: auto-generated
- References: <bug-16919-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16919
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Padding should use __glibc_reserved* names.
To make part of an existing field into padding like this, the following
need to be true:
* If the kernel reads the field, all existing kernel versions supported by
glibc already treat that part of the field as padding, so they will not
misinterpret uninitialized data there. If that's not the case, glibc
needs to initialize the padding appropriately before passing the structure
to the kernel.
* If the kernel writes the field, it gives an overflow error rather than
treating that part of the field as something to which a significant value
may be written. If it treats it as significant, glibc needs to check in
userspace for overflow and set an error in that case (just as the
asm-generic implementations of 32-bit stat functions do).
* If user programs write the field, so that for old programs the high bits
are significant but for new programs the high bits are padding, symbol
versioning needs to be used to avoid misinterpreting values written there
by existing binaries.
* If user programs read the field, so that old programs may interpret high
bits written by glibc or the kernel as significant, those bits need
initializing appropriately for the existing programs.
--
You are receiving this mail because:
You are on the CC list for the bug.