On Thu, 26 Jul 2012 18:05:45 +0200
Markus Armbruster <arm...@redhat.com> wrote:

> Luiz Capitulino <lcapitul...@redhat.com> writes:
> 
> > On Thu, 26 Jul 2012 13:56:00 +0200
> > Markus Armbruster <arm...@redhat.com> wrote:
> >
> >> Luiz Capitulino <lcapitul...@redhat.com> writes:
> >> 
> >> > Previous commits added qapi infrastructure to automatically generate
> >> > qerror macros and the qerror table from qapi-schema-errors.json.
> >> >
> >> > This commit drops the current error macros from qerror.h and the error
> >> > table from qerror.c and use the generated ones instead.
> >> >
> >> > Please, note that qapi-error.c is actually _included_ by qerror.c.
> >> > This is hacky, but the alternative is to make the table private to
> >> > qapi-error.c and generate functions to return table entries. I think that
> >> > doesn't pay much off.
> >> 
> >> Functions?  Why can't you simply put
> >> 
> >>     const QErrorStringTable qerror_table[NUMBER_OF_ERRORS];
> >> 
> >> into qapi-errors.h?
> >
> > Because it's included by qerror.h, which is included by several files.
> 
> And what harm does the declaration of qerror_table[] to those files?

We want to restrict qerror stuff as much as we can. Having it on a header
that's used by several files goes against that.

However, we just had a discussion on irc about not having the schema, so
this patch is probably going to change.

PS: Anthony will send a summary of the discussion to the list later.

> 
> > I don't like much the idea of including a .c file, but on the other hand
> > it's only included by qerror.c and qerror.c will probably die in the
> > near future.
> >
> >> 
> >> With a literal number instead of NUMBER_OF_ERRORS.  If you suffer from
> >> literal-phobia, you can also #define it instead.
> 


Reply via email to