This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Undefined behavior in glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>
- Cc: Dwight Guth <dwight dot guth at runtimeverification dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 10 Feb 2016 12:58:58 +0000
- Subject: Re: Undefined behavior in glibc
- Authentication-results: sourceware.org; auth=none
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <alpine dot DEB dot 2 dot 10 dot 1601282311351 dot 6102 at digraph dot polyomino dot org dot uk> <20160128234356 dot GH14840 at vapier dot lan> <56AAB6CE dot 8060101 at openwall dot com> <20160129005816 dot GK14840 at vapier dot lan> <56AC16C8 dot 4030202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1601311559210 dot 31071 at digraph dot polyomino dot org dot uk> <56B1F294 dot 5020105 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602031234280 dot 31480 at digraph dot polyomino dot org dot uk> <56B4E8E3 dot 5010308 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602051835320 dot 3446 at digraph dot polyomino dot org dot uk> <56B50010 dot 20202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602052233360 dot 21033 at digraph dot polyomino dot org dot uk> <56BAB213 dot 20102 at openwall dot com>
On Wed, 10 Feb 2016, Alexander Cherepanov wrote:
> > I think going from the pointer to char back to a pointer to long is valid
> > in GNU C and in common usage C, provided you never access the same memory
> > with different non-character types (other than signed/unsigned variations)
> > in ways that would require a union to do without conversions between
> > pointer types.
>
> Not sure this plays well with other principles. AIUI (from [1], [2], [2] etc.)
> you want to retain the freedom in gcc to optimize based on Q16 in DR 017. But
> going through char* seems to permit cheating. Suppose you have a 2d array and
> a pointer to char which points to the boundary between two rows. What you get
> after converting it to a pointer to the type of the elements -- a pointer
> pointing past the end of the previous row or a pointer to the first element of
> the next row? What are the limits for pointer arithmetic with this pointer --
> one row, two rows, whole array?
This is not relevant to the string functions since it's not visible to
them if a subobject was used to contstruct the pointer passed in.
> I've got a question regarding separate compilation etc. What's the problem
> with explicit_bzero then?
It needs *consensus* on the appropriateness of the patch as it exists now,
notwithstanding the various ways in which, absent new compiler features,
other copies of the zeroed memory may still be present and accessible to
the process if subsequently compromised.
> Just compile it separately and no barriers are
> required, right?
In my view, yes (the arguments about barriers are irrelevant).
--
Joseph S. Myers
joseph@codesourcery.com