Patchwork HACKING: List areas where we may rely on impdef C behaviour

login
register
mail settings
Submitter Peter Maydell
Date Oct. 30, 2012, 3:09 p.m.
Message ID <1351609766-21335-1-git-send-email-peter.maydell@linaro.org>
Download mbox | patch
Permalink /patch/195513/
State New
Headers show

Comments

Peter Maydell - Oct. 30, 2012, 3:09 p.m.
Add a section to HACKING describing the bits of implementation
defined C compiler behaviour which C code in QEMU is allowed
to rely on.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
Since the issue just came up. Have I missed anything off the list?

 HACKING | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
malc - Oct. 30, 2012, 3:40 p.m.
On Tue, 30 Oct 2012, Peter Maydell wrote:

> Add a section to HACKING describing the bits of implementation
> defined C compiler behaviour which C code in QEMU is allowed
> to rely on.

People who will desperately do a text search for "behaviour" in
relevant standards will soon learn that the british spelling is
not favoured by WG14. Other than that this addition to the document
looks fine (a link to the freely available drafts and/or wikipedia
reference would be nice)

[..snip..]
Peter Maydell - Oct. 30, 2012, 4:15 p.m.
On 30 October 2012 16:40, malc <av1474@comtv.ru> wrote:
> On Tue, 30 Oct 2012, Peter Maydell wrote:
>
>> Add a section to HACKING describing the bits of implementation
>> defined C compiler behaviour which C code in QEMU is allowed
>> to rely on.
>
> People who will desperately do a text search for "behaviour" in
> relevant standards will soon learn that the british spelling is
> not favoured by WG14. Other than that this addition to the document
> looks fine (a link to the freely available drafts and/or wikipedia
> reference would be nice)

This one, right?
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
("Final version of the C99 standard with corrigenda TC1, TC2, and
TC3 included, formatted as a draft", to borrow wikipedia's description).

I guess I should also say we code to C99 in particular (ie not
C89 or C11).

-- PMM
malc - Oct. 30, 2012, 4:55 p.m.
On Tue, 30 Oct 2012, Peter Maydell wrote:

> On 30 October 2012 16:40, malc <av1474@comtv.ru> wrote:
> > On Tue, 30 Oct 2012, Peter Maydell wrote:
> >
> >> Add a section to HACKING describing the bits of implementation
> >> defined C compiler behaviour which C code in QEMU is allowed
> >> to rely on.
> >
> > People who will desperately do a text search for "behaviour" in
> > relevant standards will soon learn that the british spelling is
> > not favoured by WG14. Other than that this addition to the document
> > looks fine (a link to the freely available drafts and/or wikipedia
> > reference would be nice)
> 
> This one, right?

Yes.

> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> ("Final version of the C99 standard with corrigenda TC1, TC2, and
> TC3 included, formatted as a draft", to borrow wikipedia's description).
> 
> I guess I should also say we code to C99 in particular (ie not
> C89 or C11).

Patch

diff --git a/HACKING b/HACKING
index 89a6b3a..1e17ac7 100644
--- a/HACKING
+++ b/HACKING
@@ -123,3 +123,19 @@  gcc's printf attribute directive in the prototype.
 This makes it so gcc's -Wformat and -Wformat-security options can do
 their jobs and cross-check format strings with the number and types
 of arguments.
+
+6. Implementation defined and undefined behaviours
+
+The C language specification defines regions of undefined behaviour and
+implementation defined behaviour (to give compiler authors enough
+leeway to produce better code). In general, code in QEMU should
+follow the language specification and avoid both undefined and
+implementation defined constructs. ("It works fine on the gcc
+I tested it with" is not a valid argument...) However there are
+a few areas where we allow ourselves to assume certain behaviours
+because in practice all the platforms we care about behave in the
+same way and writing strictly conformant code would be painful.
+These are:
+ * you may assume that integers are 2s complement representation
+ * you may assume that right shift of a signed integer duplicates
+   the sign bit (ie it is an arithmetic shift, not a logical shift)