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 support@ccsinfo.com

enum syntax error

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



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

enum syntax error
PostPosted: Mon Dec 22, 2008 2:50 pm     Reply with quote

I just started workong on my first project using the PICC compiler (v4.065) integrated with MPLAB (v8.10). I'm trying to compile some code written for previous projects, and I'm running into a problem with a line that is valid C syntax. Here's a code sample to demonstrate the problem:

Code:
#device PIC18F4520

enum ABC
{
   A, B, C
};

void Func1(enum ABC Param);


The compiler gives me the following error:

*** Error 33 "Compiler Test.c" Line 8(21,26): Expecting a {

If I remove the word "enum" in the parameter list of the function prototype, it compiles with no errors. This implies that the enum is automatically typedef'd by the compiler.

The automatic typedef'ing doesn't bother me too much (although it is non-standard C). But even with the typedef, using "enum" in the function declaration is still valid C.

I'm compiling these files with multiple compilers for different projects, so I can't change all of them to remove the "enum" (then the other compilers will complain about the lack of a typdef).

Why is this happening and how do I fix it?
TonyG



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

Intersting addendum
PostPosted: Mon Dec 22, 2008 3:51 pm     Reply with quote

I've noticed that this problem doesn't occur when the enumeration is a return parameter. For example, the following code compiles with no errors:

Code:
#device PIC18F4520

enum ABC
{
   A, B, C
};

enum ABC Func1(void);

enum ABC Func1(void)
{
   return A;
}


I'm starting to think this is a compiler bug.
TonyG



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

Another C syntax problem
PostPosted: Mon Dec 22, 2008 3:58 pm     Reply with quote

I've run into another error with valid C syntax. When I compile this following code:

Code:
#device PIC18F4520

int8 Func1(void);

void Func2(void);

int8 Func1(void)
{
   return 0;
}

void Func2(void)
{
   int8 x = Func1();
}


I get:

*** Error 27 "Compiler Test.c" Line 14(17,18): Expression must evaluate to a constant

The error applies to the line, "int8 X = Func1();".

It is perfectly valid to have a non-const initializer for a non-static variable. Why is the compiler complaining?
TonyG



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

But wait, there's more!
PostPosted: Mon Dec 22, 2008 5:22 pm     Reply with quote

Here's another compiler error about valid C syntax:

Code:
#device PIC18F4520

enum TEST
{
   A
} static x = A;

struct TEST_STRUCT
{
   int8 x;
} static x = { 0 };


The compiler generates the following errors for the definitions:

*** Error 28 "Compiler Test.c" Line 6(10,16): Expecting an identifier

Again, this is valid C syntax. Is this compiler ANSI89 compliant or not?
TonyG



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

Still more!
PostPosted: Mon Dec 22, 2008 5:38 pm     Reply with quote

One of the compilers I'm using supports a pragma statement for specifying structure packing. The statement is: "#pragma pack (1)". This pragma is of course not recognized by the PICC compiler. The ANSI 89 standard states that an unrecognized pragma should be ignored, but the PICC compiler generates the following error:

*** Error 7 "File.h" Line 39(9,13): Invalid Pre-Processor directive

Is there a list somewhere of all the ANSI 89 rules that the compiler doesn't follow?
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Mon Dec 22, 2008 6:13 pm     Reply with quote

Tony,
The subject has been brought up a number of times previously on this board. The answer to your question is no, this compiler is not intended to be fully ANSI compliant. Typically PIC related embedded compilers are not fully ANSI compliant due to the special requirements working with the PIC processors.
TonyG



Joined: 22 Dec 2008
Posts: 6

View user's profile Send private message

PostPosted: Mon Dec 22, 2008 6:22 pm     Reply with quote

Dyeatman,

Thanks for the reply. I realize that embedded compilers require adaptations. I've used Keil, IAR, Greenhills, and GNU before, so I'm familiar with these issues. Unfortunately the problems I'm having aren't related to embedded issues. For example, there should be no difference between:

int8 x = Func();

and:

int8 x;
x = Func();

but the compiler will only accept the latter.

Is there a FAQ or general thread that gives a detailed list of areas where the PICC compiler is not compliant with ANSI 89?
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Mon Dec 22, 2008 6:34 pm     Reply with quote

I have been around this board for quite a few years and have never seen any
kind of list like you are seeking. I have seen a few things recently where CCS
is working to make significant improvements to compatibility in version
4.100 I also heard that they plan to make it possible with version 4.100 (??)
to compile C18 code....don't know if this is really true. I would recommend
sending them the examples to see if they can include them in the upgrade.
Ttelmah
Guest







PostPosted: Tue Dec 23, 2008 5:23 am     Reply with quote

Some comments.

The inability to initialise from a function, is in the manual. It specifically says that the initialising value, is 'cexpr', with the comment below that 'cexpr, is a constant expression'. Though it may well 'appear' the same to initialise, then set a value to a returned value from a function, in code terms it isn't. The way that the CCS compiler works, it distinguishes stuff it puts into the 'initialisation header', from stuff in the main program. I must admit it'd not seem hard now to allow such initialisations, but it doesn't.

The enum is quite interesting. It actually implies that the compiler is not making enum definitions made outside the main functions 'global'. Historically, an enum definition, needs to be in the same 'scope' as the operation using them, and normally (in common with other defintions), anything declared outside of all functions, is 'global'. It appears that in the case of an enum, CCS is not doing this. It appears as if things inside function defintions, are being treated as having the 'scope' of the function, rather than beng global. This is why it works for the return parameter (in the external scope), but not for the calling parameters.
So you can do this, if you either typedef the enum, or declare it inside the scope of the function. So:

Code:

void Func1(enum ABC { A, B, C } val);

typedef enum {Alpha=0, Beta, Charlie } ABC2;

void Func2(ABC2 val);


I suspect it hasn't been noticed before, because most people would typedef this.

However, it is important to realise that if the enum definition is made fully 'global', this could lead to a lot of problems. enum values, must be unique in the scope to which they apply. Having enums as fully global, could then lead to problems. I have a strange 'memory', that the CCS approach, is actually the same as was done by the original PDP-11 'C', when enums first appeared. Remember that the original K&R 'C', did not have these at all.

Best Wishes
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