Bug #1258
Updated by Evgeny Novikov over 9 years ago
While implementing #1159 issue I noticed (also I have noticed it a long ago) that such typedefs: <pre><code class="c"> <pre> #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; </code></pre> </pre> are printed as: <pre><code class="c"> <pre> #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]; </code></pre> </pre> In using ___builtin_va_arg_ function: <pre><code class="c"> <pre> ... va_list args; ... __builtin_va_arg ( args , int ); ... </code></pre> </pre> this causes problems: <pre> error: first argument to ‘va_arg’ not of type ‘va_list’ </pre> I believe that this problem touches not so many drivers. Indeed the same issue is with all typedefs on arrays, e.g.: <pre><code class="c"> typedef int T[10]; typedef T S; </code></pre> becomes: <pre><code class="c"> typedef int T[10]; typedef T S[10]; </code></pre> And the first look points to that we need to completely re-implement typedef processing in C-backend (Aspectator processes typedefs even worse).