This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined behavior in glibc

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]