Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/3] livepach: Add 
.livepatch.hooks functions and test-case"):
> On 10.08.16 at 11:46, <JBeulich@xxxxxxxx> wrote:
> > Odd. I've tried this simple example:
> > 
> > typedef int fn_t(void);
...
> >     const fn_t**cfn;

Ie,
        const int **cfn(void);

> >     for(i = 0; !rc && i < ps->n; ++i)
> >             rc = ps->cfn[i]();

From `(gcc-4)Function Attributes':

  `const'
       Many functions do not examine any values except their arguments,
       and have no effects except the return value.  Basically this is
       just slightly more strict class than the `pure' attribute below,
       since function is not allowed to read global memory.

       Note that a function that has pointer arguments and examines the
       data pointed to must _not_ be declared `const'.  Likewise, a
       function that calls a non-`const' function usually must not be
       `const'.  It does not make sense for a `const' function to return
       `void'.

       The attribute `const' is not implemented in GCC versions earlier
       than 2.5.  An alternative way to declare that a function has no
       side effects, which works in the current version and in some older
       versions, is as follows:

            typedef int intfn ();

            extern const intfn square;

       This approach does not work in GNU C++ from 2.6.0 on, since the
       language specifies that the `const' must be attached to the return
       value.

Ie, gcc has always treated a function marked const as having no
unexpected inputs and no side effects.

> > test1() and test2() get compiled identically. test3(), using the field
> > with the misplaced const, oddly enough gets compiled slightly
> > differently (and without a warning despite one would seem
> > warranted), yet the call doesn't get omitted. If, however, I change
> > the return type of fn_t to void, the function body of test3() ends
> > up empty, which is a compiler bug afaict, but which also suggests
> > that you've tried the variant with the misplaced const.

No, it is gcc realising that there is no point calling a function
which returns void and has no side effects

TBH I am inclined to agree that gcc should issue a warning for a
such a function.

> FTR: This is not a compiler bug, as specifically named undefined
> in the C spec.

In this case, the behaviour is defined by the GCC manual.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel