AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090407182821.32a02c41@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<jonathan.goldick@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB52AC8FDE38A@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 7 Apr 2009 18:29:07 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Jonathan Goldick <jonathan.goldick@onstor.com>
Subject: Re: anonymous union thingie
Message-ID: <20090407182907.5cc1165f@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB52AC8FDE38A@exch1.onstor.net>
References: <20090403130758.0e468981@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB52AC8EA6BDC@exch1.onstor.net>
	<20090407175903.722d64cc@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB52AC8FDE38A@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


No, u.whatever doesn't help anything by comparison, but a proper name
would, which is what I proposed.  But you ignored?  Maybe it's a life
long prejudice, or a traumatic childhood incident, but I don't think
kernel code is the right place for C++ constructs.

You don't think it lacks readability?  C'mon, really?  Or just
taking Max' side?  Whether or not my code tagger finds it readable
is definitely not the test.

Yes, I know the compiler switch; I'm merely feeling the need to discuss
the matter thoroughly.

Anyway....


On Tue, 7 Apr 2009 18:05:09 -0700 Jonathan Goldick
<jonathan.goldick@onstor.com> wrote:

> See JG>
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, April 07, 2009 5:59 PM
> To: Jonathan Goldick
> Subject: Re: anonymous union thingie
> 
> On Fri, 3 Apr 2009 13:23:30 -0700 Jonathan Goldick
> <jonathan.goldick@onstor.com> wrote:
> 
> > We use that everywhere in the TXRX, I've never liked adding a bogus field name like 'u' just so you can access a field in a union.  This is part of the C++ standard and prevalent in C compilers.
> > 
> 
> I'm confused.  Why use some obscuring feature that doesn't do anything
> for you but make the code harder to read?  In short, what would be
> wrong with adding a non-bogus identifier so that union element can be
> accessed?  Is this just to save on typing or something?  I'm afraid
> this description hasn't brought me up to speed.
> 
> JG> Having a 'u.' inserted doesn't add all that much that I can see, which is why they added the construct to C++.  The union can be accessed in the way the code is written, if the compiler has the proper support, which it does.
> 
> > Please do not attempt to change this everywhere.  It would be a huge task and doesn't result in anything working better than now.  While I learned about this construct by seeing it used here, it's actually pretty nice once you get used to it.
> > 
> 
> I'm not doing anything.  I'm just looking at the output of the
> compiler, and realizing that it will have to be dealt with at some
> point.  But now I'm getting this kind of error:
> 
> /homes/andys/src/tuxrx/nfx-tree/code/sm-nfs/nfs-open-api.h:239: error: 'struct nfs_open_ctx' has no member named 'in'
> 
> for a line of code like this:
> 
> ctx->in.ln_dirFcb = dir_fcb;
> 
> where ctx is type struct nfs_open_ctx (nfs-open-struct.h:135)
> 
> and I'm guessing that the "in.whatever" somehow refers to this nonsense
> in the structure definition:
> 
>   /* Passed to fcb_lookup() or fcb_lookupByName().
>      */
>     union {
>         lookup_name_t;
> 
>         /* Note that the volId in the handle is not filled in.
>          */
>         void *nr_lookup_handle;
>     };
> 
> 
> I'm sorry, but that's bloody hard to read.  Really, very, bloody hard to
> read.
> 
> I have no idea what, if anything, I'm going to do about it.
> 
> BTW, as I'm sure you would agree, improved readability always results in
> things working better.
> 
> JG> I would agree if I thought it added to readability...which I don't.  My code tagger has no problems handling this construct.  There is a compiler switch to make this work so there should be no need to "deal" with it by changing our structure definitions and miles of code.  Max knows the switch, I don't remember off the top of my head.
> 
> 
> > 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Friday, April 03, 2009 1:08 PM
> > To: Jonathan Goldick
> > Subject: anonymous union thingie
> > 
> > Here's a sample snippet from sm-nfs/nfs-open-struct.h
> > 
> > /* Context for nfs_open_by_handle() and  nfs_open_by_name().
> >  */
> > typedef struct nfs_open_ctx
> > {
> >     /* Passed to fcb_lookup() or fcb_lookupByName().
> >      */
> >     union {
> >         lookup_name_t;      <-------------
> > 
> >         /* Note that the volId in the handle is not filled in.
> >          */
> >         void *nr_lookup_handle;
> >     };
> > 
> >     /* Is passed to author_permissionOk.
> >      */
> >     author_permOkContext_t nr_perm_context;
> > 
> >     /* Is passed to author_permissionOk.
> >      */
> >     author_permissionOkResp_t nr_perm_resp;
> > 
> >     /* The open handle to fill
> >      */
> >     nfs_open_handle_t *nr_open_handle;
> > 
> >     /* Context to traverse the FNS tree
> >      */
> >     struct ofh_doFnsCtx_s *nr_traverse_ctx;
> > 
> >     /* Context to break the oplocks if necessary
> >      */
> >     struct op_breakConflicts_s *nr_oplock_ctx;
> > 
> >     /* How to open this file.
> >      */
> >     enum nfs_open_type nr_open_type;
> > 
> >     /* If true, the handle is valid
> >      */
> >     uint32 nr_handle_valid : 1;
> > 
> >     /* If true, we had dropped the parent directory lock
> >      * during last call.
> >      */
> >     uint32 nr_dropped_lock : 1;
> > 
> >     /* If true, we did drop the parent directory lock
> >      * at least once during the operation.
> >      */
> >     uint32 nr_has_dropped_lock : 1;
> > 
> >     /* If TRUE, permissions check has failed
> >      */
> >     uint32 nr_access_denied : 1;
> > } nfs_open_ctx_t;
