Actions
Bug #1258
closedC back-end processes typedefs on arrays incorrectly
Start date:
05/20/2011
Due date:
% Done:
0%
Estimated time:
Detected in build:
svn
Platform:
Published in build:
Description
While implementing #1159 issue I noticed (also I have noticed it a long ago) that such typedefs:
#line 40 "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include/stdarg.h"
typedef __builtin_va_list __gnuc_va_list;
#line 102 "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include/stdarg.h"
typedef __gnuc_va_list va_list;
are printed as:
#line 40 "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include/stdarg.h"
typedef __builtin_va_list __gnuc_va_list[1U];
#line 102 "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include/stdarg.h"
typedef __gnuc_va_list va_list[1U];
In using __builtin_va_arg function:
...
va_list args;
...
__builtin_va_arg ( args , int );
...
this causes problems:
error: first argument to ‘va_arg’ not of type ‘va_list’
I believe that this problem touches not so many drivers.
Indeed the same issue is with all typedefs on arrays, e.g.:
typedef int T[10];
typedef T S;
becomes:
typedef int T[10];
typedef T S[10];
And the first look points to that we need to completely re-implement typedef processing in C back-end (Aspectator processes typedefs even worse).
Actions