[cfe-dev] clang-check wrongly adds forward definitions

[James Dennett via cfe-dev]

On Thu, Jul 6, 2017 at 7:33 AM, Yves Rutschle via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hello,
>
> I'm using clang-check (combined with cproto) to fix old K&R
> code that needs to compile with a compiler that doesn't like
> that.
>
> I have an issue with the way it adds an identifier forward
> definition with it's not yet defined, e.g.:
>
>
> #include <stddef.h>
>
> struct foo {
>     int a;
>     struct s* b;
> };
>
> int main(void) {
>     struct foo f;
>
>     f.b = NULL;
>
>     return 0;
> }
>
>
>
> `struct s` was not defined, but this is not a problem for a pointer
> definition.
> Then I run (v4.0.1):
>
>
> $ clang-check -ast-print -fix-what-you-can in.c
> typedef long ptrdiff_t;
> typedef unsigned long size_t;
> typedef int wchar_t;
> typedef struct {
>     long long __clang_max_align_nonce1 __attribute__((aligned(_Alignof(long
> long))));
>     long double __clang_max_align_nonce2 __attribute__((aligned(_Alignof(long
> double))));
> } max_align_t;
> struct foo {
>     int a;
>     struct s;
>     struct s *b;
> };
> int main() {
>     struct foo f;
>     f.b = ((void *)0);
>     return 0;
> }
>
>
> The `struct s` right in the middle of the definition of `struct foo`
> confuse
> all compilers. My understanding of the C standard is that this definition
> should be either *before* the `struct foo` definition, or not exist at all
> (which I think is the usual way to do it). Am I missing some reason it
> would
> appear there?
>

Putting it there would be right for C++, which allows nested record types.
It's possible that the clang-check code doesn't take account of C's rather
different rules in this area.


>
> I'll see if I manage to fix that by myself if no-one is interested :)
>

That'd be great.  I don't know whether it makes sense to have one piece of
functionality that tries to handle both C and C++, or to separate them
out.  That might depend on how much they have in common.

-- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170706/fe261ffc/attachment.html>