Re: [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 21/09/15 18:13, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library"):
>> On 21/09/15 17:17, Ian Jackson wrote:
>>> Do you mean that statement expressions (originally a GNU extension)
>>> should be avoided in tools code ?  A quick git-grep discovered that
>>> xenctrl already contains numerous statement expressions.
>> It is fine (in principle) to be used internally.  Not in a public header
>> for what is supposed to be a clean API.
> I don't understand why this distinction is relevant.  Either the
> compiler supports it, or it doesn't.

There shouldn't be items in a public header which can't be used by all
compilers which might want to compile it.

GCC is not the only compiler liable to encounter this new header file.

>
>>>> violates several principles of least supprise,
>>> This is just invective.
>> /me googles and discovered a new word.  I stand by my statement.
> Well, if you feel so strongly, I won't object to a patch to remove it.

This is exactly why I raise the point now when the ABI is deliberately
changing.  Having said that, it was previously in libxc so anything
went.  I would be happy to submit a patch either to libxc now, or to
libxentoollog later.

>
>>>> As part of the tidyup, we should choose a particular C standard (89,
>>>> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
>>>> -pedantic`.  This will help to provide a consistent API on other
>>>> platforms (I seem to recall an effort to port libvchan to windows.)
>>> -pedantic is certainly a bad idea.
>> Pedantic is absolutely the correct answer.  It will cause gcc to reject
>> any non C compliant statements.
> No, that is not what -pedantic does.  Please RTFM.

Please explain why you believe it to be unsuitable?  It is not perfect,
but is far better than nothing.

~Andrew