|
|
View previous topic :: View next topic |
Author |
Message |
tester
Joined: 29 Jun 2009 Posts: 40 Location: Russia, SPb
|
pointer, struct and typedef |
Posted: Wed Jan 06, 2010 6:50 am |
|
|
Hello!
There is something wrong in version 4.104 with accessing fields in struct through a pointer. (versions 4.084, 4.093, 4.102 works correctly)
Code: |
#include<16F877a.h>
#fuses HS, NOLVP, NOWDT, NOPROTECT
typedef struct {
char a;
char b;
} T_STRUCT;
typedef T_STRUCT* T_POINTER;
T_STRUCT s;
T_POINTER p;
void main (void)
{
p = &s;
p->a = 0; // Here we get an error: "Previous identifier must be a pointer"
} |
There is no error when :
1. Variable p declared as:
2. "->" replaced with "."
|
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Jan 06, 2010 9:00 am |
|
|
But the second variant can't generate correct code, because it involves a wrong level of indirection. |
|
|
tester
Joined: 29 Jun 2009 Posts: 40 Location: Russia, SPb
|
|
Posted: Wed Jan 06, 2010 9:11 am |
|
|
FvM wrote: | But the second variant can't generate correct code, because it involves a wrong level of indirection. |
Yes, of course. Second variant is just for example. The code generated for second variant is incorrect (s.a will not became 0). I just think that compiler must generate an error for second variant, but it doesn't. |
|
|
Ttelmah Guest
|
|
Posted: Wed Jan 06, 2010 9:27 am |
|
|
So, what happens if you do it the 'normal' way round?
Code: |
typedef *T_STRUCT T_POINTER;
|
Best Wishes |
|
|
tester
Joined: 29 Jun 2009 Posts: 40 Location: Russia, SPb
|
|
Posted: Wed Jan 06, 2010 9:38 am |
|
|
Ttelmah wrote: | So, what happens if you do it the 'normal' way round?
Code: |
typedef *T_STRUCT T_POINTER;
|
Best Wishes |
??? 'normal' way?
Compiler will generate an error "unknown type" or "syntax error" or something like this. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Jan 06, 2010 9:57 am |
|
|
Thank you for reporting the bug.
With PCD, I get 46 errors in a previously correct working application, that uses standard C constructs like:
Code: | typedef struct
{
unsigned int32 snr;
unsigned int16 timestamp;
signed int16 temp;
unsigned int16 res[2];
} txxx_reg, *pxxx_reg; |
Try it again, Sam. I wonder if the CCS guys have any serious test cases?
P.S.: I'm sad. It happened, that one PCD bug, that I reported 4 month ago has been finally fixed in V4.104.
But there are more open cases anyway.
Last edited by FvM on Wed Jan 06, 2010 10:05 am; edited 1 time in total |
|
|
Ttelmah Guest
|
|
Posted: Wed Jan 06, 2010 10:02 am |
|
|
K&R, only use the format you have that works. Declaring the typedef as a 'type', and then the variable as a pointer to this type (so the * in in front of the variable name). Using a trailing *, is not listed.
They in two locations, show using a leading *, but only with an intrinsic type, not with an already typdefed form.
The use of a trailing asterisk for this, is a C++ extension, not part of C. That it worked at all on some versions, is I'd imagine, basically a fluke.
So, why not just use the C format that is in K&R, and does work correctly?...
Best Wishes |
|
|
tester
Joined: 29 Jun 2009 Posts: 40 Location: Russia, SPb
|
|
Posted: Wed Jan 06, 2010 10:18 am |
|
|
Ttelmah wrote: | So, why not just use the C format that is in K&R, and does work correctly?... |
Line:
Code: |
typedef *T_STRUCT T_POINTER;
|
generates an error:
*** Error 34 "ccs16_test.c" Line 9(9,16): Unknown type
(I've checked this construction with msvc++, mcc30, mcc18, ht-picc. All they generated an error). Or did you mean something else? |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Jan 06, 2010 10:23 am |
|
|
Hm. My above typedef example is generic K&R C, as you may check in chapter 6.9 typedef.
Mostly I don't care for these sensitive differentiations between C specifications. It's not the point, when we face
arbitrary changes of an existing compiler "on the way". We are hoping, at least one of the various remaining bugs
could be fixed but we experience new unexpected ones instead.
If a modification would be necessary to resolve conflicting specifications (as we faced with pointer arithmetic
some time ago), it must be never done without a clear anouncement. |
|
|
Ttelmah Guest
|
|
Posted: Wed Jan 06, 2010 11:24 am |
|
|
K&R, 6.9,does not show the format with a trailing *, in any copy I have (1978 first edition, only uses the format with *, immediately in front of the name), while latter editions, have other things as chapter 6.9 (bit fields in a second edition). Typedef here is chapter 6.7, and again only has the format with the *, in front of the name.
Fvm, the format he already has, which works, is:
T_STRUCT *p;
Or,
typedef T_STRUCT *T_POINTER;
Both of which work for me with CCS.
Using an * in front of the type, is shown in a really early edition of K&R, as a direct printout from the PDP-11 files, but was changed in the printed editions. It does work on the original PDP compiler, but only with intrinsic types (not another typedef).
However _no_ version of K&R, that I have seen, referring just to C, uses a trailing *.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Jan 06, 2010 2:17 pm |
|
|
I refered to K&R regarding the below construct, now quoting the original text. It's in chapter 6.9 typedef of
the 1983 german copy of the 1977 Prentice-Hall 1st edition.
Code: | typedef struct tnode {
char * word;
int count;
struct tnode *left;
struct tnode *right;
} TREENODE, *TREEPTR; |
TREEPTR has been recognized as a pointer type with any C compiler I ever worked with, execpt CCS C V4.104.
This simple fact, besides all standardizations make me think of a bug.
The other construct in question can be also found in 1977 K&R:
Code: | typedef int MILES, *KLICKSP; |
The example clarifies also that * belongs to the newly defined pointer type KLICKSP rather than the referenced
type. There is no trailing * in any of the discussed cases in my opinion.
I didn't explicitely check for, but I would be really suprized if these clear and simple specification of basic C syntax
had been narrowed somehow in later standards.
But anyway, even if it would, this still doesn't justify a change in todays CCS C. |
|
|
|
|
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
|