AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090407175757.373d0e6c@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	2779531E7C760D4491C96305019FEEB52AC8EA6BDC@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 7 Apr 2009 17:59:03 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Jonathan Goldick <jonathan.goldick@onstor.com>
Subject: Re: anonymous union thingie
Message-ID: <20090407175903.722d64cc@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB52AC8EA6BDC@exch1.onstor.net>
References: <20090403130758.0e468981@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB52AC8EA6BDC@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

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.

> 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.


> 
> -----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;
