On Fri, Jun 08, 2018 at 06:13:46PM +0100, Ramsay Jones wrote:
>
>
> On 08/06/18 17:44, Luc Van Oostenryck wrote:
> > Builtin macros are defined via the add_pre_buffer() mechanism
> > which is quite powerful/flexible but for small, simple builtin
> > macros, it's a bit sad to have to compose a buffer and then
> > tokenize it when it would be easy to directly define these macros.
> >
> > Add a new function, predefine(), which allows to directly add
> > a definition for a simple macro, taking no args and having
> > a single number or identifier as definition.
> >
> > Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
> > ---
> > lib.h | 1 +
> > pre-process.c | 38 ++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/lib.h b/lib.h
> > index 0e5f3e4a8..4ea6c6423 100644
> > --- a/lib.h
> > +++ b/lib.h
> > @@ -130,6 +130,7 @@ enum phase {
> >
> >
> > extern void add_pre_buffer(const char *fmt, ...) FORMAT_ATTR(1);
> > +extern void predefine(const char *name, int weak, const char *, ...) FORMAT_ATTR(3);
>
> missing 'fmt' parameter name in the proto - or were you trying
> to stay below 80 columns? ;-)
The later (and still 84 columns IIRC).
I'll do something for it later.
> > +///
> > +// predefine a macro with a printf-formatted value
> > +// @name: the name of the macro
> > +// @weak: 0/1 for a normal or a weak define
> > +// @fmt: the printf format followed by it's arguments.
> > +//
> > +// The type of the value is automatically infered:
> > +// TOKEN_NUMBER if it starts by a digit, TOKEN_IDENT otherwise.
> > +// If @fmt is null or empty, the macro is defined with an empty definition.
> > +void predefine(const char *name, int weak, const char *fmt, ...)
> > +{
> > + struct ident *ident = built_in_ident(name);
> > + struct token *value = &eof_token_entry;
> > + int attr = weak ? SYM_ATTR_WEAK : SYM_ATTR_NORMAL;
> > +
> > + if (fmt && fmt[0]) {
> > + static char buf[256];
> > + va_list ap;
> > +
> > + va_start(ap, fmt);
> > + vsnprintf(buf, sizeof(buf), fmt, ap);
> > + va_end(ap);
>
> I debated with myself, whether the documentation should mention
> this 256 byte limit to the result of the 'sprintf'. I suspect
> that, in the end, I would decide against! :-D
Oh yes, this sort of things doesn't belong to the doc in this case.
The use of a limit is debatable, though, but shorter limits are used
in quite a few place for more generic uses.
> [BTW, I have a mild dislike of using C++ style comments for
> the documentation. However, you are doing the work (which is
> to be applauded), so just ignore me!]
I understand and I must say that I'm not 100% in love with it.
But I've never liked the ' * ' starting the lines in the classic C
block-comment style and the closing ' */' even more. Also, for some
reasons, my combination of fingers + keyboard has hard to type them.
So, yes, I use the C++ style more and more.
Best regards,
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
