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@xxxxxxxxxxx> wrote:
> > On Sat, Oct 9, 2010 at 1:59 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
