2009/3/11 Tim Jenness <[log in to unmask]>:
> Can anyone explain this code to me please?
>
> In datmap.c:
>
> 193 /* NB workaround for problems with EMS... */
> 194 temp_status = hds_gl_status;
> 195 if ( (hds_gl_status = DAT__CONER) )
I've no (known) involvement in any of this, but surely that "=" should
be "==" ? The original author must have made a typo, and then a later
author covered up the problem by adding the extra parentheses...
David
> 196 hds_gl_status = DAT__OK;
> 197 rec_release_data(&data->han, objlen, objoff, 'R', &dom);
> 198 if ( _ok( hds_gl_status ) )
> 199 hds_gl_status = temp_status;
> 200 }
>
> The intel compiler thinks that should be ( hds_gl_status == DAT__CONER ).
>
> Peter gets the blame for that line but only because he merged in a change
> from Brian that was originally:
>
> 197) /* NB workaround for problems with EMS...
> */
> 198) temp_status = hds_gl_status;
> 199) if ( hds_gl_status = DAT__CONER ) hds_gl_status = DAT__OK;
> 200) rec_release_data(&data->han, objlen, objoff, 'R', &dom);
> 201) if ( _ok( hds_gl_status ) ) hds_gl_status = temp_status;
>
> adding the extra paren and breaking the if-statement over two lines. The
> above code is assigned to Norman because he added it to CVS initially. This
> is the down side of not having full access to the code history. The HDS C
> code doesn't even have an author in the prologue (usually there is not a
> prologue in the files that have more than one functions)
>
> As far as I can tell the above code sets hds_gl_status to DAT__CONER and
> immediately resets it to DAT__OK. So why not just set it to DAT__OK in the
> first place?
>
> * Can anyone work out what the code is attempting to work around?
> * Could the EMS bug referenced above have been fixed by now?
> * rec_release_data does start a whole new EMS context so maybe
> that was part of the problem?
> * Is the code correct, but confusing?
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|