All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.