on Tue, 13 Apr 2021 21:08:36 +0100 you (Peter Sewell
<Peter.Sewell_at_[hidden]>) wrote:

> On Tue, 13 Apr 2021 at 20:22, Jon Chesterfield <
> jonathanchesterfield_at_[hidden]> wrote:
>
> > On Tue, Apr 13, 2021 at 7:39 PM Peter Sewell
> > <Peter.Sewell_at_[hidden]> wrote:
> >
> >> - all other cases (i.e., those that are neither representation-byte
> >> accesses, padding-byte accesses, or partially initialised struct
> >> member accesses) of reading uninitialised variables can be
> >> regarded as programmer errors
> >>
> >
> > A case I believe is missing from the enumeration involves reading
> > off the end of an array, from uninitialised memory, when processing
> > an array in chunks of multiple elements at a time. Popular with
> > code using vector intrinsics. Copying an uninitialised value, doing
> > arithmetic to it, then flushing it back to the source is quicker
> > than explicit loop epilogues.
>
> True. We have previously thought about that case, but it's
> intertwined also with the provenance and effective type semantics, so
> perhaps better to defer for now.

I think that these kind of algorithms are usually close to the
boundary between C library implementation and user code and very
specialized for a particular architecture. They could (should?) be
handled with implementation specific permissions (if considered UB in
general) or as part of the C library.

That is one of the reasons why `memcpy` is a C library function. Only
the C library provider can know if it is safe to access bytes up to
the next word boundary, for example, and how to avoid information
leaks that such techniques could produce. Probably the C standard is
not precise enough on these topics, architectures have much evolved
since the corresponding C library text has been written.

Sanitizing the C library could be a interesting topic, but more of a C
library SG, if we had such a thing.

In the mean time, specialized application libraries (e.g for optimized
vector computing) should perhaps position themselves on the C library
side and provide the necessary guarantees to their users.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::