Bug #1258
closedC back-end processes typedefs on arrays incorrectly
0%
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).
Updated by Evgeny Novikov over 13 years ago
Moreover it seems that CIL doesn't treat this as a error. So it isn't so important.
Updated by Evgeny Novikov over 13 years ago
- Subject changed from C-backend processes variable arguments builtin typedefs incorrectly to C-backend processes variable arguments builtin typedefs and functions incorrectly
As was noticed in #1156 issue variable arguments functions are also printed incorrectly.
So someday we should discover what is variable argument processing at all and fix all problems. Small note: with Alexey we have found quickly that if we will eliminate all nonoriginal pointers, arrays and castings than we will obtain compilable sources :) But it isn't easy to do this may be. At the moment we can be glad that sources are checkable.
Updated by Evgeny Novikov over 13 years ago
Updated by Evgeny Novikov about 12 years ago
- Project changed from Linux Driver Verification to C Instrumentation Framework
- Category deleted (
15)
Updated by Evgeny Novikov over 10 years ago
- Priority changed from Normal to High
Vadim mentioned that the issue is unpleasant.
Updated by Vadim Mutilin over 10 years ago
Yes, it appears quite often when I prepare benchmarks for the competition.
Updated by Evgeny Novikov about 10 years ago
- Subject changed from C-backend processes variable arguments builtin typedefs and functions incorrectly to C-backend processes typedefs on arrays incorrectly
- Description updated (diff)
Updated by Vadim Mutilin almost 10 years ago
The same problem appeares for SVGA3dCapPair from drivers/gpu/drm/vmwgfx/vmwgfx_kms.h (e.g. function vmw_fill_compat_cap http://lxr.free-electrons.com/source/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c?v=3.16#L141)
typedef uint32 SVGA3dCapPair[2U];
struct svga_3d_compat_cap
{
SVGA3dCapsRecordHeader
header;
SVGA3dCapPair pairs[94U][2U];
};
should be
SVGA3dCapPair pairs[94U];
Updated by Evgeny Novikov almost 9 years ago
- Subject changed from C-backend processes typedefs on arrays incorrectly to C back-end processes typedefs on arrays incorrectly
- Description updated (diff)
- Category set to C back-end
Updated by Evgeny Novikov almost 9 years ago
#5323 likely duplicates this issue.
Updated by Evgeny Novikov over 5 years ago
- Has duplicate Bug #7111: CIF causes a EMG failure due to incorrect result of inforequest provided for sound/oss/ad1848.ko added
Updated by Evgeny Novikov almost 4 years ago
- Priority changed from High to Urgent
Though this issue is not crucial for Linux drivers since it is seldom, it is crucial, say, for LiteOS, where it breaks processing of the BSD part.
Updated by Evgeny Novikov almost 4 years ago
- Status changed from Open to Closed
I hope that I finally fix this issue in b9a4c06. Some parts of this issue were fixed before. Now C back-end supports structure fields that are arrays of typedefs.