CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

#EXPORT giving problems on version 5.045 and later

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
AdamWebber



Joined: 18 Jun 2014
Posts: 13

View user's profile Send private message

#EXPORT giving problems on version 5.045 and later
PostPosted: Tue Dec 01, 2015 4:30 pm     Reply with quote

Is anybody else having problems with #export after version 5.044? I created #defines so that when I export the hex file, it automatically uses the defined values. After 5.044, it no longer uses the defined values. It now uses the label.

Code:

#define SW_VER   A
#define HW_VER   REVB
#define DATE     _2015-12-1

#define EXPNAME(a,b,c,d) a ##b ##c ##d
#export (HEX, FILE = EXPNAME(SW_VER,HW_VER,DATE,.hex) )


In the 5.044 and earlier, the filename would be "AREVB_2015-12-1.hex".
Anything later will be "SW_VERHW_VERDATE.hex".

Is there a fix for this before I go to the developer?
Ttelmah



Joined: 11 Mar 2010
Posts: 19520

View user's profile Send private message

PostPosted: Wed Dec 02, 2015 4:54 am     Reply with quote

It's actually working correctly now!....

This is a 'classic' C problem. When you use ## it precludes macro expansion of the arguments each side. So you have to 'double indirect', to get the expansion to occur.
Code:

#define SW_VER   A
#define HW_VER   REVB
#define DATE     _2015-12-1
#define CAT(a,b,c,d) a ## b ## c ## d
#define EXPNAME(a,b,c,d) CAT(a,b,c,d)
#export (HEX, FILE = EXPNAME(SW_VER,HW_VER,DATE,.hex))


Most C textbooks will have this explained, but what happens is that '##' will catenate the tokens without expanding them. So you have to force the macro expansion to take place before the catenation, by 'indirecting' this, calling it from another macro!...

It's interesting that CCS was expanding the macros (it shouldn't have).

Have a look at this:
<http://stackoverflow.com/questions/1489932/how-to-concatenate-twice-with-the-c-preprocessor-and-expand-a-macro-as-in-arg>

Note the 'PASTOR', and 'EVALUATOR' indirection, and the careful explanation of this.

It was done to allow 'unexpanded' values to be included in the macros, otherwise you have the problem of things being expanded 'accidentally', when they happen to contain a text value that is used elsewhere in a macro....
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Wed Dec 02, 2015 5:03 am     Reply with quote

I've had to do a similar thing for similar reasons with stringification. In my case also related to filenames:

Code:

// Utility stringification macro. We have to use this as stringising can only happen
// in a function-like macro, and it needs this unexpected double stage thing.
#define STRINGER1(a) #a
#define STRINGER(a) STRINGER1(a)

// If we've been given a part number we should name the hex file based on that number. The string version allows code to printf it more easily.
#define PART_NUMBER_STRING STRINGER(PART_NUMBER)
#define HEX_FILENAME PART_NUMBER.hex
#export (HEX, FILE=HEX_FILENAME)
Ttelmah



Joined: 11 Mar 2010
Posts: 19520

View user's profile Send private message

PostPosted: Wed Dec 02, 2015 5:07 am     Reply with quote

Yes. It applies to both the #, and the ## operators.
From the C spec:

Quote:

6.10.3.1 Argument substitution

After the arguments for the invocation of a function-like macro have been identified, argument substitution takes place. A parameter in the replacement list, unless preceded by a # or ## preprocessing token or followed by a ## preprocessing token (see below), is replaced by the corresponding argument after all macros contained therein have been expanded. Before being substituted, each argument’s preprocessing tokens are completely macro replaced as if they formed the rest of the preprocessing file; no other preprocessing tokens are available.


Critical bit is the phrase:
"unless preceded by a # or ## preprocessing token". On # though it doesn't apply to the token in front, but with ## this is affected as well:
"or followed by a ## preprocessing token".
AdamWebber



Joined: 18 Jun 2014
Posts: 13

View user's profile Send private message

PostPosted: Wed Dec 02, 2015 12:13 pm     Reply with quote

This code now compiles the hex file name properly. I just added a secondary #define EXPNAME that defines the first #define EXPNAME1. I changed nothing else.

Thank you for your help, Captain Awesome-O!

Code:
#define SW_VER   A
#define HW_VER   REVB
#define DATE     _2015-12-1

#define EXPNAME1(a,b,c,d) a ##b ##c ##d
#define EXPNAME(a,b,c,d) EXPNAME1(a,b,c,d)
#export (HEX, FILE = EXPNAME(SW_VER,HW_VER,DATE,.hex) )
Ttelmah



Joined: 11 Mar 2010
Posts: 19520

View user's profile Send private message

PostPosted: Thu Dec 03, 2015 1:35 am     Reply with quote

Good.

It is one of those things that once you understand it 'makes sense'. Problem is that if # or ## defaulted to doing a macro expansion before they joined things, you could not include stuff that contained keywords that were already #defined (so in your case for example the text 'DATE' could not be used, since it would expand). So they default to not expanding, and if you want an expansion, you have to use the indirect (which then does the expansion before the values are passed to the joining function). It is interesting that some of the older CCS versions were expanding. Would give problems with quite a few bits of code....

Smile
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group