| Message ID | 1351675847-22740-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | Accepted |
| Commit | 475363176c80feedb8feb5e335ba64de68c7b055 |
| Headers | show |
Ping! now that 1.4 is open. patchwork url http://patchwork.ozlabs.org/patch/195783/ -- PMM On 31 October 2012 09:30, Peter Maydell <peter.maydell@linaro.org> 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 <peter.maydell@linaro.org> > --- > 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 > >
Thanks, applied. On Wed, Oct 31, 2012 at 9:30 AM, Peter Maydell <peter.maydell@linaro.org> 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 <peter.maydell@linaro.org> > --- > 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 >
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)
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 <peter.maydell@linaro.org> --- HACKING | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)