Thanks, applied. On Wed, Oct 31, 2012 at 9:30 AM, Peter Maydell <[email protected]> wrote: > Add a section to HACKING saying which version of the C spec > we use and describing the bits of implementation defined C > compiler behaviour which C code in QEMU is allowed to rely on. > > Signed-off-by: Peter Maydell <[email protected]> > --- > HACKING | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/HACKING b/HACKING > index 89a6b3a..6654d33 100644 > --- a/HACKING > +++ b/HACKING > @@ -123,3 +123,23 @@ 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. C standard, implementation defined and undefined behaviors > + > +C code in QEMU should be written to the C99 language specification. A copy > +of the final version of the C99 standard with corrigenda TC1, TC2, and TC3 > +included, formatted as a draft, can be downloaded from: > + http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf > + > +The C language specification defines regions of undefined behavior and > +implementation defined behavior (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 behaviors 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) > -- > 1.7.11.4 >
