linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Tomas Klacko <tomas.klacko@gmail.com>
Cc: Christopher Li <sparse@chrisli.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-sparse@vger.kernel.org
Subject: Re: including sparse headers in C++ code
Date: Sun, 17 Oct 2010 22:39:56 -0700	[thread overview]
Message-ID: <20101018053955.GA1628@feather> (raw)
In-Reply-To: <AANLkTi=tpKLvWh6VKsizpZaxYMBntaGU1gC5uRu1_bND@mail.gmail.com>

On Sun, Oct 17, 2010 at 12:31:26PM +0200, Tomas Klacko wrote:
> On Sat, Oct 16, 2010 at 9:11 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Sat, Oct 16, 2010 at 06:03:53PM +0200, Tomas Klacko wrote:
> >> On Wed, Oct 13, 2010 at 2:37 AM, Christopher Li <sparse@chrisli.org> wrote:
> >> > On Tue, Oct 12, 2010 at 3:45 PM, Tomas Klacko <tomas.klacko@gmail.com> wrote:
> 
> >> >>  /* Silly type-safety check ;) */
> >> >>  #define DECLARE_PTR_LIST(listname,type)        struct listname { type *list[1]; }
> >> >> -#define CHECK_TYPE(head,ptr)           (void)(&(ptr) == &(head)->list[0])
> >> >>  #define TYPEOF(head)                   __typeof__(&(head)->list[0])
> >> >>  #define VRFY_PTR_LIST(head)            (void)(sizeof((head)->list[0]))
> >> >>
> >> >> +#ifndef __cplusplus
> >> >> +#define CHECK_TYPE(head,ptr)           (void)(&(ptr) == &(head)->list[0])
> >> >> +#else
> >> >> +/* I don't know yet how to do this better in C++. */
> >> >> +#define CHECK_TYPE(head,ptr) (void)((void*)&(ptr) == (void*)&(head)->list[0])
> >> >> +#endif
> >> >
> >> > If you can't get CHECK_TYPE work in C++, you might just make it an empty define
> >> > instead of doing useless point dancing. At least it is clear that it does not
> >> > do any thing here.
> >>
> >> True. How about
> >> #define CHECK_TYPE (head,ptr)   (void)(1)
> >> ?
> >
> > As far as I can tell, CHECK_TYPE works just fine in C++.  I could easily
> > compile an invocation of CHECK_TYPE, as well as some simple examples
> > that called the macros which invoked CHECK_TYPE.  When I tried
> > FOR_EACH_PTR, I encountered *other* warnings (related to assigning (void
> > *) to some other type without a cast), but those warnings didn't come
> > from CHECK_TYPE.
> 
> Maybe I did not investigate deeply enough to find out the origin of
> the warnings.
> But I get no warnings/errors, when I disable CHECK_TYPE in C++ code.
> 
> > What warning do you encounter about CHECK_TYPE?
> 
> In the following code1 (file main.cc):
> int main(int argc, char* argv[])
> {
>     struct string_list *files=NULL;
> 
>     void* file_void;
>     char* file_char;
> 
>     struct symbol_list *symbols=NULL;
>     struct symbol_list *all_symbols=NULL;
> 
>     symbols=sparse_initialize(argc, argv, &files);
>     concat_symbol_list(symbols, &all_symbols);
> 
>     FOR_EACH_PTR_NOTAG(files, file_void) {  // line 19
>         file_char=(char*)file_void;
>         symbols=sparse(file_char);
>         concat_symbol_list(symbols, &all_symbols);
>     } END_FOR_EACH_PTR_NOTAG(file_void);
> 
>     exit(EXIT_SUCCESS);
> }
> 
> I get:
> main.cc: In function ‘int main(int, char**)’:
> main.cc:19: error: comparison between distinct pointer types ‘void*’
> and ‘char*’ lacks a cast

This warning means that CHECK_TYPE has done its job correctly; you
should not use the void * file_void to iterate over a list of files. 
FOR_EACH_PTR (and the _NOTAG variant) expect a list type and the
corresponding element type, and they use CHECK_TYPE to make this
type-safe.

> compiler and (important) flags:
> g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4), -Wall -Werror
> 
> 
> Now, the code2 (file main.cc):
> int main(int argc, char* argv[])
> {
>     struct string_list *files=NULL;
> 
>     char* file_char;
> 
>     struct symbol_list *symbols=NULL;
>     struct symbol_list *all_symbols=NULL;
> 
>     symbols=sparse_initialize(argc, argv, &files);
>     concat_symbol_list(symbols, &all_symbols);
> 
>     FOR_EACH_PTR_NOTAG(files, file_char) {  // line 18
>         symbols=sparse(file_char);
>         concat_symbol_list(symbols, &all_symbols);
>     } END_FOR_EACH_PTR_NOTAG(file_char);
> 
>     exit(EXIT_SUCCESS);
> }
> 
> I get error:
> main.cc: In function ‘int main(int, char**)’:
> main.cc:18: error: invalid conversion from ‘void*’ to ‘char*’

This warning doesn't come from CHECK_TYPE; it comes from the subsequent
implicit conversion from the list's void * to the desired type char *,
which will indeed need a cast to work correctly when included from C++.

Based on these two code examples, I think you don't need to change
CHECK_TYPE at all.  (And the user should always use code like your
second example, not your first example.)

(Of course, if someone really wants to use these lists from C++, they
might want to build appropriate type-safe C++ iterator types on top of
the ptrlist bits. :) )

- 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

  parent reply	other threads:[~2010-10-18  5:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-09 16:40 including sparse headers in C++ code Tomas Klacko
2010-10-09 20:59 ` Josh Triplett
2010-10-09 21:46   ` Christopher Li
2010-10-10 11:41     ` Bernd Petrovitsch
2010-10-10 11:52       ` Kamil Dudka
2010-10-11  9:44         ` Bernd Petrovitsch
2010-10-11 16:04           ` Christopher Li
2010-10-11 19:12             ` Josh Triplett
2010-10-13 14:45               ` Bernd Petrovitsch
2010-10-18 18:43                 ` Christopher Li
2010-10-20  7:29                 ` Al Viro
2010-10-20  9:39                   ` Bernd Petrovitsch
2010-10-20 15:34                     ` Christopher Li
2010-10-29 13:22                       ` Bernd Petrovitsch
2010-11-05  0:57                         ` Christopher Li
2010-11-09 13:28                           ` Bernd Petrovitsch
2010-11-09 22:52                             ` Christopher Li
2010-11-10 10:52                               ` Bernd Petrovitsch
2010-10-11 22:33     ` Tomas Klacko
2010-10-11 22:46       ` Al Viro
2010-10-11 23:01         ` Christopher Li
2010-10-12 22:45           ` Tomas Klacko
2010-10-13  0:37             ` Christopher Li
2010-10-13 11:39               ` Bernd Petrovitsch
2010-10-16 16:03               ` Tomas Klacko
2010-10-16 19:11                 ` Josh Triplett
2010-10-17 10:31                   ` Tomas Klacko
2010-10-18  4:13                     ` Christopher Li
2010-10-18  5:39                     ` Josh Triplett [this message]
2010-10-18 18:37                       ` Christopher Li
2010-10-19 20:03                         ` Tomas Klacko
2010-10-19 21:31                           ` Al Viro
2010-10-19 21:46                             ` David Malcolm
2010-10-19 22:12                               ` Al Viro
2010-10-19 22:49                             ` Tomas Klacko
2010-10-20 10:19                               ` Bernd Petrovitsch
2010-10-19 23:07                             ` Christopher Li
2010-10-20  7:40                               ` Al Viro
2010-10-18  3:16                   ` Christopher Li
2010-10-11 23:37       ` Josh Triplett
2010-10-12 10:42         ` Bernd Petrovitsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101018053955.GA1628@feather \
    --to=josh@joshtriplett.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    --cc=tomas.klacko@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).