Re: including sparse headers in C++ code

[Josh Triplett <josh@joshtriplett.org>]

On Tue, Oct 12, 2010 at 12:33:32AM +0200, Tomas Klacko wrote:
> On Sat, Oct 9, 2010 at 11:46 PM, Christopher Li <sparse@chrisli.org> wrote:
> > On Sat, Oct 9, 2010 at 1:59 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> >> It seems reasonable to avoid the use of C++ keywords in Sparse *headers*
> >> (though unnecessary in *source*).  Looks like this will primarily cause
> >> pain due to "enum namespace" and the various places using it.  Seems
> >> easy enough to change those all to "ns".  "new" mostly seems to get used
> >> as a parameter name or local variable name; for the former we could omit
> >> it, and for the latter we could trivially call it something more
> >> specific like "newlist" or "newptr".
> >>
> >> So, I'd tend to guess "patches welcome" (again, for headers only, plus
> >> minimal corresponding source changes when required).  I wouldn't
> >> anticipate other Sparse developers objecting strongly, but if they do
> >> your mail seems like the right way to find out.  The various reasons
> >> given for *not* making the Linux kernel headers compatible don't seem to
> >> apply here, though.
> >
> > Well said. I don't expect sparse to compile in the C++ mode. Making
> > sparse header usable in C++ seems reasonable to me.
> 
> Great. I am posting my current status (as a patch) so that you can comment on it
> and that I can refine it further.

> --- a/c2xml.c
> +++ b/c2xml.c
> @@ -128,7 +128,7 @@ static void examine_modifiers(struct symbol *sym,
> xmlNodePtr node)
> 
>  	int i;
> 
> -	if (sym->namespace != NS_SYMBOL)
> +	if (sym->Namespace != NS_SYMBOL)

How about "ns"?

> --- a/compile-i386.c
> +++ b/compile-i386.c
> @@ -332,9 +332,9 @@ busy:
>  	return 1;
>  }
> 
> -static struct storage *get_reg(struct regclass *class)
> +static struct storage *get_reg(struct regclass *Class)

Just call it "regclass".

> --- a/evaluate.c
> +++ b/evaluate.c
> @@ -357,7 +357,7 @@ static inline int classify_type(struct symbol
> *type, struct symbol **base)
>  	return type_class[type->type];
>  }
> 
> -#define is_int(class) ((class & (TYPE_NUM | TYPE_FLOAT)) == TYPE_NUM)
> +#define is_int(Class) ((Class & (TYPE_NUM | TYPE_FLOAT)) == TYPE_NUM)

"c" or "cls"?

> --- a/expression.c
> +++ b/expression.c
> @@ -118,7 +118,7 @@ static struct token *parse_type(struct token
> *token, struct expression **tree)
>  	struct symbol *sym;
>  	*tree = alloc_expression(token->pos, EXPR_TYPE);
>  	(*tree)->flags = Int_const_expr; /* sic */
> -	token = typename(token, &sym, NULL);
> +	token = Typename(token, &sym, NULL);

"type_name"?

> --- a/lib.h
> +++ b/lib.h
> @@ -120,6 +120,10 @@ extern int Wdeclarationafterstatement;
>  extern int dbg_entry;
>  extern int dbg_dead;
> 
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +

> @@ -162,33 +170,41 @@ static inline void free_instruction_list(struct
> instruction_list **head)
>  	free_ptr_list((struct ptr_list **)head);
>  }
> 
> -static inline struct instruction * delete_last_instruction(struct
> instruction_list **head)
> +static inline struct instruction * delete_last_instruction(
> +        struct instruction_list **head)

Huh?  I don't see a change here, just formatting (and what looks like
whitespace damage).

>  {
> -	return undo_ptr_list_last((struct ptr_list **)head);
> +	return (struct instruction *)undo_ptr_list_last(
> +                (struct ptr_list **)head);
>  }

Wow.  I had to double-check this because I couldn't quite believe C++
had that degree of dain bramage, but sure enough:

/tmp$ cat test.c
extern void *pv(void);

int *pi(void)
{
    return pv();
}
/tmp$ gcc -c test.c -o /dev/null
/tmp$ g++ -c test.c -o /dev/null
test.c: In function ‘int* pi()’:
test.c:5: error: invalid conversion from ‘void*’ to ‘int*’
(1) /tmp$


I can understand C++ having stronger typechecking, but void pointers
*exist* for this purpose.  *Really* debatable whether Sparse should work
around this.  Avoiding keywords, sure, but casting void pointers
everywhere?  People *remove* these kinds of casts from C programs as a
cleanup.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html