Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS

From: Ian Jackson <ian.jackson@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "stefanos@xilinx.com" <stefanos@xilinx.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	"julien.grall@arm.com" <julien.grall@arm.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS
Date: Fri, 8 Mar 2019 15:31:49 +0000	[thread overview]
Message-ID: <23682.35557.153834.423011@mariner.uk.xensource.com> (raw)
In-Reply-To: <5C8224A70200007800150142@prv1-mh.provo.novell.com>

Jan Beulich writes ("Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS"):
> >No.  This is not fine.  Signed integer subtraction sometimes has UB.
...
> I've spent an hour trying to find the relevant parts of the spec, but I'm
> afraid I've once again failed at finding all necessary pieces.

The spec is obtuse indeed.

> This does not make any provisions for unsigned types being special.

6.2.5 9
   .... A computation involving unsigned operands can never overfow,
   because a result that cannot be represented by the resulting
   unsigned integer type is reduced modulo the number that is one
   greater than the largest value that can be represented by the
   resulting type.

> As to the unsigned -> signed conversion, according to, again in the
> Conversions section,
> 
> "Otherwise, the new type is signed and the value cannot be represented
>  in it; either the result is implementation-defined or an implementation-
>  defined signal is raised."
> 
> this is implementation defined according to my understanding (but I take
> it that we're fine with this).

Yes.  On the platforms currently supported by Xen, the
`implementation' `defines' that the result is simply the same bit
pattern.  I say `implementation' in quotes because really we mean
compiler, and `defines' because while no doubt there is a formal
conformance statement somewhere, what we are relying on is instead
something much more general:

The community of C programmers for `normal' architectures effectively
require that conversion to signed integer work this way.  A platform
where that didn't work would be strange and would produce a lot of
other porting difficulties too.  And because the result is *defined*,
the compiler authors can't use this as an optimisation opportunity so
aren't motivated to sophistic justifications for misbehaviour.

> >Conversely, I think the discussion of the sizes of these types is not
> >really relevant.  To port Xen it is necessary to have an environment
> >where
> >sizeof(ptrdiff_t) == sizeof(uintptr_t)
> >== sizeof(void*) == sizeof(struct maxalign*)
> >and I think there is little harm in further baking in those
> >assumptions.
> 
> Good (except that I don't understand the struct maxalign* part - neither
> why you use a pointer there, nor - assuming there was no pointer - how
> that would be in line with __{,u}int128_t or with vector types).

On some machines, pointers to different types have different
representations and even different sizes.  Xen cannot be ported to
such machines - at least, not without an awful lot of work.

Xen assumes that all pointers have the same representation.

`struct maxalign*' was a somewhat-informal way of referring to the
type of a pointer to an object type with the maximal alignment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel