[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc_bugs

Title:DEC C Problem Reporting Forum
Notice:Report DEC C++ problems in TURRIS::C_PLUS_PLUS
Moderator:CXXC::REPETETCHEON
Created:Fri Nov 13 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1299
Total number of notes:6249

1287.0. "AXP 5.5-003 VMS 7.1 prcdef.h bug or precompiler hiccup." by COMICS::EDWARDSN (Dulce et decorum est pro PDP program) Wed Apr 16 1997 07:45

Wondered if anyone had spotted this in the past. It's still here either way:

#include <prcdef.h>

union prcdef q_stsflg;

void main (void) {
  q_stsflg.prc$r_prcdef_bits.prc$v_detach = 1;
}

Yields:

  q_stsflg.prc$r_prcdef_bits.prc$v_detach = 1;
..^
%CC-E-NEEDMEMBER, In this statement, "prc$r_prcdef_bits" is not a member of "q_s
tsflg.prc$r_prcdef_bits".
at line number 8 in file DKA400:[USERS.EDWARDS.C]PRCFAULT.C;1

To check that I hadn't gone quite insane just yet, (my C syntax is not cast iron
so it could be stupidity on my part - pass me that Learning Services catalog)

union fish {
  struct {
    int cod;
    int ling;
  } old_fish;
  struct {
    int salmon;
    int trout;
  } new_fish;
};
union fish fresh;
void main (void){
  fresh.old_fish.cod = 1;
}

Compiles cleanly.
The customer is migrating from VAX C 3.2 to AXP VMS 6.2 DEC C 5.0, but this shows
the same behaviour at 5.5-003 and 7.1 of VMS.

Any answers please. I've told them to remove the .prc$r_prcdef_bits as a workaround.

Neil.
T.RTitleUserPersonal
Name		DateLines
1287.1variant_structsCXXC::REINIGThis too shall changeWed Apr 16 1997 10:1160
Compiling:

    #include <prcdef.h>

    union prcdef q_stsflg;

    void main (void) {
        q_stsflg.prc$r_prcdef_bits.prc$v_detach = 1;
    }
 
/preprocess_only I get the follow (some parts removed)

    #pragma nostandard

    union prcdef {
        variant_struct   {
            ...
            unsigned prc$v_detach : 1;       
            ...
        } prc$r_prcdef_bits;
        variant_struct   {
            unsigned prc$v_fill_0 : 6;
            unsigned prc$v_login : 1;        
            unsigned prc$v_fill_60 : 1;
        } prc$r_prcdef_obsolete;
    } ;

    union prcdef q_stsflg;

    void main (void) {
        q_stsflg.prc$r_prcdef_bits.prc$v_detach = 1;
    }

prc$r_prcdef_bits is a variant_struct, not a struct.  Because
prc$r_prcdef_bits is a variant_struct, you do not mention it when
referencing its fields.  That is, you use

        q_stsflg.prc$v_detach

and not

        q_stsflg.prc$r_prcdef_bits.prc$v_detach

------

If you modified your test program to use variant_struct instead of struct
for old_fish, you would get a 

    %CC-W-VARIANTEXT, variant struct or union is a language extension.

diagnostic if you compiled in a standard conforming mode of the compiler. 
You would not get the diagnostic if you used /standard=vaxc.  PRCFAULT.C
does not get this diagnostic because of the 

    #pragma nostandard

in <prcdef.h>.  This pragma tells the compiler that there is odd stuff
coming and to not complain about it.

                                            August G. Reinig
1287.2Further detailsDECCXL::WIBECANThat&#039;s the way it is, in Engineering!Wed Apr 16 1997 12:0525
Assuming non-VAXC mode, there are a bunch of lines in prcdef.h of the form:

#define prc$v_detach prc$r_prcdef_bits.prc$v_detach

These defines are an attempt to hide the intermediate structures created by
SDL.  You are expected to reference the fields as August indicated:

	q_stsflg.prc$v_detach = 1;
Not	q_stsflg.prc$r_prcdef_bits.prc$v_detach = 1;

Given the macro definition above, the latter expands to

	q_stsflg.prc$r_prcdef_bits.prc$r_prcdef_bits.prc$v_detach = 1;

which leads to the error you saw.

Be careful using these structure fields in macro invocations, by the way. 
Because the field name matches the macro, the field name might get expanded a
second time, leading to the same error.

(Some time back I tried to convince the SDL implementers to use uppercase for
the actual field and lowercase for the macro, avoiding the possibility of the
macro being expanded too many times, but nobody's taken me up on that one.)

						Brian