Re: [PATCH v2 18/19] OFFSETOF_VAR macro to simplify hashmap iterators

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Eric Wong <e@xxxxxxxxx> writes:
> 
> > That seems too tedious.  I'm learning towards just initializing
> > var = NULL in the start of the for-loop:
> >
> > @@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
> >   * containing a @member which is a "struct hashmap_entry"
> >   */
> >  #define hashmap_for_each_entry(map, iter, var, member) \
> > -	for (var = hashmap_iter_first_entry_offset(map, iter, \
> > +	for (var = NULL /* squelch uninitialized warnings for OFFSETOF_VAR */, \
> > +		var = hashmap_iter_first_entry_offset(map, iter, \
> >  						OFFSETOF_VAR(var, member)); \
> 
> That looks a bit too ugly for my taste.  I've added an updated
> version (see below) and then rebased the whole thing on top of it.

I prefer to minimize the amount of stuff we do to work around
buggy compilers (in case they get fixed and old versions are
obsoleted).

If it's just clang with this problem, we know clang sets
__GNUC__, so we can use __typeof__ directly (bypassing extra
parentheses in our TYPEOF macro) to get around the warning:

#if defined(__GNUC__) /* clang sets this, too */
#define OFFSETOF_VAR(ptr, member) offsetof(__typeof__(*ptr), member)
#else /* !__GNUC__ */
...


That said, there could be other compilers which don't set
__GNUC__ and have the same problem as clang.  But maybe those
compilers are too buggy and we already ignore invalid warnings
on those compilers.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux