unnamed variable as place holder inside struct

call it Ralph and all will work. If Ralph is already used, call it Phred. My usual name for such is "expansion_space"

Erik

The problem is that I have way too many non-contiguous "reserved" field. Is there a way to leave it unnamed?

Thanks,

Anh

I think giving it a name is probably a better idea:

At least then you can set a breakpoint on "reserved_027" to ensure that nothing is (unwittingly) accessing it.

And you can easily do a text search for "reserved_" to find them all.

And, in the future version that starts using one of them, your can say "reserved_459 is now used for hyperdrive_warp_factor" or whatever.

Implicit in my previous post was the suggestion that you use a standard format; eg, call them all reserved_xxx, where xxx is just a 3-digit (or whatever) number.

Using a fixed 3 (or whatever) digits means that a simple text sort (eg, as in the uVision browser) will put them in the right order - otherwise you get reserved_9 coming before reserved_199 in a sorted list!

Also, a fixed size makes it easier to construct a regular expression to find them all

As far as I know, the C standard does not define anonymous non-bitfield struct members. Since Keil's C compilers claim to be ANSI C compliant, you can't expect them to have this feature. It seems that you'll have to do with named struct members.

- mike

"The problem is that I have way too many non-contiguous 'reserved' field."

Why??

Does this not suggest something that needs to be fixed in your design?

As you say yourself that there's "way too many," why don't you get rid of 'em?!

Would this work?

struct S
{
   int a;
   int b;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   char :8;
   int c;
   int d;
   int  bit0 : 1;
   int       : 6;
   int  bit7 : 1;
}

Would this work?

Not really --- keeping in mind that this method relies on the magic number 8 having its usual meaning of "number of bits in a byte", and that I don't think anonymous bitfields are supposed to have a width assigned to them --- they're supposed to be used to "flush" one machine word, so the next bitfield will start in a word of its own. Neither am I convinced they're guaranteed to start a new one if the next bit would have been in a fresh word already.

To summarize: the problem is in what the OP is trying to do, not in Keil preventing him from doing it.

Thanks Jon, I like your method. Any suggestions for arrays?

Anh

Take a look at http://www.keil.com/forum/docs/thread2150.asp and modify it for this situation.

Jon

If your objective is simply to avoid the drudgery of typing 'reserved' structure member names, this short AWK script will do it for you:

BEGIN { FS = "[" }

/[ \t]+(char|short|int|long)\[/ {
	count_str = sprintf("%03d", count++)
	$0 = $1 " reserved_" count_str "[" $2
}

{print}

struct S
{
   int a;
   int b;
   int[5]; //reserved 5 ints but dont' need to name it.
   char[5]; //reserved 5 ints but dont' need to name it.
   long[5]; //reserved 5 ints but dont' need to name it.
   int[5]; //reserved 5 ints but dont' need to name it.
   int c;
   int d;

   int  bit0 : 1;
   int       : 6;
   int  bit7 : 1;
}

struct S
{
   int a;
   int b;
   int reserved_000[5]; //reserved 5 ints but dont' need to name it.
   char reserved_001[5]; //reserved 5 ints but dont' need to name it.
   long reserved_002[5]; //reserved 5 ints but dont' need to name it.
   int reserved_003[5]; //reserved 5 ints but dont' need to name it.
   int c;
   int d;

   int  bit0 : 1;
   int       : 6;
   int  bit7 : 1;
}

Thanks everyone for their help. I had a lots of reserved fields for backward compatiblity with existing software.

Anh

"I had a lots of reserved fields for backward compatiblity with existing software."

In that case, I'd say it's particularly important that you do give them specific names that clearly indicate what's going on!