[cpp-threads] RE: Comments on Hans's latest strawman proposal

[Nick Maclaren]

> > [ I/O generally ]
> >
> I'm not quite sure what you mean here.  Remember that consistent
> executions exist primarily to define when something is data-race-free.
> We're not really insisting on totally ordering ordinary variable
> accesses, since we require that no conforming program can tell the
> difference.

What I mean is that constraining I/O (and streams generally) to be
as consistent as ordinary data accesses gets rather badly in the
way of buffering, asynchronous transfer etc.  So I favour a more
relaxed set of requirements - which needs more study, but is at
least localised.

> Let's postpone some of the later discussion, since those sections of the
> proposal really still need to be rewritten.

Yes.

> > Gug.  How clear is C++ that padding bytes may not be written
> > to?  There was a long and inconclusive debate about whether C
> > allows them to be. This may need clarification.
> >
> Why does it matter?

Some time back, I was talking to some implementors who had had to change
their compiler to leave padding bytes intact because not doing so was
breaking too many codes (GUIs are bad, for example).  I don't know if
things have improved.

> > static double d;
> > char *p = &((char *)d)[1];
> > *(char *)d = 0;
> >
> Agreed, though I suspect this isn't really controversial.  Anybody wnt
> to propose a way to handle this?

At least C++ provides the clear message "don't do that sort of thing",
so I suspect that it is not a huge problem.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679