Coder Social home page Coder Social logo

ltcmelo / psychec Goto Github PK

View Code? Open in Web Editor NEW
528.0 528.0 39.0 10.68 MB

A compiler frontend for the C programming language

License: BSD 3-Clause "New" or "Revised" License

CMake 0.91% Shell 0.05% Python 1.24% C++ 94.86% Haskell 1.98% C 0.82% NASL 0.14%
c c-language clanguage compiler compiler-frontend language-semantics parser parsing parsing-library program-analysis static-analysis type-inference

psychec's People

Contributors

aytey avatar ltcmelo avatar ludanpr avatar luigidcsoares avatar rurban avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

psychec's Issues

Implement syntactic support for STD's `__func__` and GNU's `__FUNCTION__` and `__PRETTY_FUNCTION__`

Implement syntactic support for STD's __func__ and GNU's __FUNCTION__ and __PRETTY_FUNCTION__

  1. Add the syntax — follow the guidance from this wiki page.

    • new token syntaxes: Keyword___func__, Keyword_ExtGNU___FUNCTION__, and Keyword_ExtGNU___PRETTY_FUNCTION__.
    • tokens spelling: "func", "FUNCTION", and "PRETTY_FUNCTION".
    • lexing of Keyword___func__ is condition to LanguageDialect::Std::C99.
    • lexing of Keyword_ExtGNU___FUNCTION__ and Keyword_ExtGNU___PRETTY_FUNCTION__ are conditional not yet existing LanguageExtensions::isEnabled_ExtGNU_FunctionNames; this enablement flag, alongside the corresponding LanguageExtensions::enable_ExtGNU_FunctionNames must be created.
    • new node syntax: PredefinedNameSyntax inheriting from NameSyntax.
  2. Parse the syntax

    • at Parser::parseExpressionWithPrecedencePostfix at labels Keyword___func__, Keyword_ExtGNU___FUNCTION__, and Keyword_ExtGNU___PRETTY_FUNCTION__.
    • new method Parser::parsePredefinedName_AtFirst.
  3. Test the syntax

    • for Keyword_ExtGNU___FUNCTION__ and Keyword_ExtGNU___PRETTY_FUNCTION__ in TestParser::case1980' to TestParser::case1989'
    • for Keyword___func__ in TestParser::case3020' to TestParser::case3029'.

Function pointer assignment not supported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

20050202-1.c:3:14 error: declarator may not be initialized
  void (*f)() = foo;
              ^

(return code 0)

Content of file

void foo() {
  void (*f)() = foo;
  f();
}

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Valid compound literal not recognized

Compiled without errors with GCC and Clang (both trunk) with options -c and -pedantic

ISO C Standard
-std=c11

Version
Screenshot of git show --summary plus a local compilation (also tested in Godbolt's Comp. Explorer):

commit

The snippet

int main() {

  struct s_s
  {
    int i;
  };

  return (struct s_s){.i=42}.i;
}

Hope it helps, psyche-c helped us a lot when working on AnghaBench :)

Implement syntactic support for GNU's __builtin_choose_expr

Implement syntactic support for GNU's __builtin_choose_expr.

NOTE: GNU's __builtin_va_arg already is supported and may be used as an example.

  1. Add the syntax — follow the guidance from this wiki page.

    • new token syntax: Keyword_ExtGNU___builtin_choose_expr.
    • token spelling: "__builtin_choose_expr".
    • lexing of Keyword_ExtGNU___builtin_choose_expr is conditional to already existing LanguageExtensions::isEnabled_ExtGNU_InternalBuiltins.
    • new node syntax: ExtGNU_ChooseExprSyntax inheriting from ExpressionSyntax.
  2. Parse the syntax

    • at Parser::parseExpressionWithPrecedencePostfix at labels Keyword_ExtGNU___builtin_choose_expr.
    • new method Parser::parseExtGNU_ChooseExpression_AtFirst.
  3. Test the syntax

    • for Keyword_ExtGNU___builtin_choose_expr, in TestParser::case1970' to TestParser::case1979'.

Handling `#define` in the AST?

Is dealing with macros, i.e. #define, out of the scope of --C-dump-AST? I guess technically macros are preprocessed, and they shouldn't be in the AST (clang discards them).

Handling them would be really useful for my use case parsing The Machinery headers. They make use of a lot of macros to smooth over the API and translating those to another language is one of the biggest failure points for binding generators.

For example with tree-sitter, its C parser can detect if a node is some kind of preprocessor symbol, so it's possible to translate a #define to a constant or a call expression .e.g.:

#define TM_VERSION(major, minor, patch) (TM_LITERAL(tm_version_t){ major, minor, patch })
#define tm_api_registry_api_version TM_VERSION(0, 3, 0)
#define tm_get_api(reg, TYPE) \
    (struct TYPE *)reg->get(#TYPE, TYPE##_version)

`__thread` keyword unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

darwin-thread-specifier.c:1:14 warning: missing type specifier, assume `int'
# 1 "<stdin>"
              ^
darwin-thread-specifier.c:2:9 error: expected , or `;' or = after declarator, got `int'
__thread int b;
         ^

(return code 0)

Content of file

__thread int b;

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Function returning function pointer unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

tiny.c:0:23 error: expected `,' or `;' or `=' after declarator, got `{'
void(*foo(void))(void) { return 0; }
                       ^
tiny.c:0:35 warning: missing type specifier, assume `int'
void(*foo(void))(void) { return 0; }
                                   ^
tiny.c:0:35 error: expected <identifier> or `(' starting direct-declarator, got `}'
void(*foo(void))(void) { return 0; }
                                   ^

(return code 0)

Content of file

void(*foo(void))(void) { return 0; }

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

Initialiser list unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

20010124-1.c:5:20 error: expected `]', got `{'
} x[sizeof(struct s){1, 2}];
                    ^

(return code 0)

Content of file

struct s {
  int a;
  int b;
} x[sizeof(struct s){1, 2}];

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

`__WCHAR_TYPE__` unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

wchar.c:0:0 warning: missing type specifier, assume `int'wchar.c:0:15 error: expected `,' or `;' or `=' after declarator, got `wchar_t'
__WCHAR_TYPE__ wchar_t;
               ^

(return code 0)

Content of file

__WCHAR_TYPE__ wchar_t;

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

`__extension__` keyword unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

tiny.c:1:14 warning: missing type specifier, assume `int'
# 1 "<stdin>"
              ^
tiny.c:2:14 error: expected , or `;' or = after declarator, got `int'
__extension__ int x;
              ^

(return code 0)

Content of file

__extension__ int x;

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Have problems in using API

Hello, I am very interested in your project and want to continue to do the generation and analysis of CFG based on your project. But after reading your readme documentation several times, I'm still not sure how I'm going to invoke your API in my own project. For example, which library files should I include in my project, what.h files should I include, etc.

create language bindings for PsycheC's public API

Languages for which bindings are mostly desired:

  • Python
  • Rust
  • Lua
  • OCaml
  • Go
  • C

Perhaps, for all languages that tree sitter has bindings for?

Bindings are expected for the public api, ie, types/methods annotated with PSY_API, PSY_C_API, and PSI_COMMON_API.

For API consistency across languages and productivity, a tool with a common language interface should be used, e.g., SWIG.

`__alignof` keyword unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

x86_64-linux-android.c:2:19 error: expected expression got `double'
int a1_i[__alignof(double)];
                   ^

(return code 0)

Content of file

int a1_i[__alignof(double)];

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Pre-ANSI declarations not supported (but are supported by clang/gcc in `-std=c11`)

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

930506-1.c:2:10 error: expected , or `;' or = after declarator, got `double'
long f(a) double a;
          ^
930506-1.c:2:20 warning: missing type specifier, assume `int'
long f(a) double a;
                    ^
930506-1.c:2:20 error: expected <identifier> or `(' starting direct-declarator, got `{'
long f(a) double a;
                    ^
930506-1.c:3:12 warning: missing type specifier, assume `int'
{ return a; }
            ^
930506-1.c:3:12 error: expected <identifier> or `(' starting direct-declarator, got `}'
{ return a; }
            ^

(return code 0)

Content of file

long f(a) double a;
{ return a; }

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

sizeof of expression with bit-field

Hello,

The snippet

struct S
{
  signed int i: 32;
};

int main()
{
  int z;
  struct S x = {32};
  z = sizeof(x.i+0);
  return 0;
}

Screenshot with gcc, clang, cnip compiled and code:

Captura de tela de 2021-02-23 12-21-47

Literal suffix `lu` and `llu` not accepted

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

suffix.c:0:23 error: expected expression got `#error#'
int foo(void) { return 0xcccclu; }
                       ^

(return code 0)

Content of file

int foo(void) { return 0xcccclu; }

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

`__builtin_offsetof` unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

memset.c:4:28 error: expected expression got `struct'
  return __builtin_offsetof(struct s, i);
                            ^

(return code 0)

Content of file

struct s {
  char i;
};
int offset() {
  return __builtin_offsetof(struct s, i);
}

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

Cnip can't handle Duff's device — K&R style function declarations

Tested with GCC and Clang with options: -c -std=c11 -pedantic test.c, no warnings or errors reported.

ISO C Standard
-std=c11

Version
Tag, branch, commit, or screenshot of git show --summary: 66415a2
image

Cnip outputs quite a few more errors, which were not included in the screenshot.

The snippet
The infamous Duff's device

void send(to, from, count)
register short *to, *from;
register int count;
{
    register int n = (count + 7) / 8;
    switch (count % 8) {
    case 0: do { *to = *from++;
    case 7:      *to = *from++;
    case 6:      *to = *from++;
    case 5:      *to = *from++;
    case 4:      *to = *from++;
    case 3:      *to = *from++;
    case 2:      *to = *from++;
    case 1:      *to = *from++;
            } while (--n > 0);
    }
}

In particular, it seems like there are two bugs here:

  1. Cnip can't handle K&R style function declarations.
  2. Cnip can't handle intertwined switch and do while statements.

Hope this can be of help :)

Switch fall-through unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

uninit-exhaustive-switch-bug.c:5:2 error: `case' label not within a switch statement
  case 1:
  ^

(return code 0)

Content of file

void test(int i) {
  switch (i) {
  case 0:
  case 1:
    break;
  }
}

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Re-enable tests on Win32

In #46, psychec's test-suite.exe was disabled (on Win32) as it does not correctly link on that platform.

They were disabled because (at the time of #46) psychec's tests live in psychecfe.{so,dll} and are not correctly exposed (on Windows) in a way that allows test-suite.exe to link against them without link-time errors.

This is a "reminder issue" such that it is not forgotten to re-enable the building/running of those tests later on.

Cannot declare variable called `true` or `false`

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

bool.c:0:4 error: expected <identifier> or `(' starting direct-declarator, got `false'
int false;
    ^

(return code 0)

Content of file

int false;

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

`__complex__` unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

complex.c:0:0 warning: missing type specifier, assume `int'complex.c:0:12 error: expected `,' or `;' or `=' after declarator, got `float'
__complex__ float foo;
            ^

(return code 0)

Content of file

__complex__ float foo;

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

Compiling on Windows?

Do you have any advice for getting this to compile on Windows? I'm using MSYS with the Windows version of cmake so I can call the generator for "MSYS Makefiles", but calling make I've run into these errors.

[ 15%] Linking CXX shared library libpsychecommon.dll
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(TextElement.cpp.obj):TextElement.cpp:(.text+0x17): undefined reference to `__imp__ZTVN3psy11TextElementE'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(TextElement.cpp.obj):TextElement.cpp:(.text+0xb7): undefined reference to `__imp__ZTVN3psy11TextElementE'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(Diagnostic.cpp.obj):Diagnostic.cpp:(.text+0xae): undefined reference to `__imp__ZNK3psy20DiagnosticDescriptor15defaultSeverityEv'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(Diagnostic.cpp.obj):Diagnostic.cpp:(.text+0x208): undefined reference to `__imp__ZNK3psy20DiagnosticDescriptor11descriptionEv'
collect2: error: ld returned 1 exit status
make[2]: *** [common/CMakeFiles/psychecommon.dir/build.make:259: common/libpsychecommon.dll] Error 1
make[1]: *** [CMakeFiles/Makefile2:191: common/CMakeFiles/psychecommon.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

`__attribute__` keyword unaccepted (needs `-Wno-unused-variable`)

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -Wno-unused-variable -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -Wno-unused-variable -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

vector-2.c:3:2 error: expected expression got `__attribute__'
  __attribute__((vector_size(16))) float t1;
  ^

(return code 0)

Content of file

void getCapsule() {
  __attribute__((vector_size(16))) float t1;
}

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

Implement the parse of parameters in K&R style functions

Implement the parse of parameters in K&R style functions

This article illustrates the syntax of a function in K&R C.

  1. Add the syntax — follow the guidance from this wiki page.

    • new node syntax: ExtKR_ParameterDeclarationSyntax (similar to ParameterDeclarationSyntax but with a semicolon token).
    • new list: typedef SyntaxNodePlainList<ExtKR_ParameterDeclarationSyntax*> ExtKR_ParameterDeclarationListSyntax;.
    • new field for the K&R parameters in FunctionDefinitionSyntax.
  2. Parse the syntax

  • at Parser::parseDeclarationOrFunctionDefinition_AtFollowOfSpecifiers at label default, after the parse of an initializer syntax.
  • pre: Backtracker BT(this);
    (mind the non-K&R parameter functions Parser::parseParameterDeclarationList and parseParameterDeclaration).
  • post: BT.backtrack(); or BT.discard();
  1. Test the syntax
  • TestParser::case0280' to TestParser::case0299'.

Update Psychec's CI to use C++17

Is your feature request related to a problem? Please describe.

PR #40 "fell over" because it used the legally-allowed C++17 header filesystem, but this does not actually exist in psychec CI base image:

Describe the solution you'd like

Update the GitHub actions to use a more-modern Ubuntu or look at using a later GCC within 18.04

Describe alternatives you've considered

Change PR #40 to not use filesystem (even though it is in C++17 😞)

Additional context

Build log from #40: https://github.com/ltcmelo/psychec/pull/40/checks?check_run_id=2161399189#step:4:65

Implement syntactic support for STD's offsetof and GNU's __builtin_offsetof

Implement syntactic support for STD's offsetof and GNU's __builtin_offsetof.

NOTE: GNU's __builtin_va_arg already is supported and may be used as an example.

  1. Add the syntax — follow the guidance from this wiki page.

    • new token syntaxes: Keyword_ExtGNU___builtin_offsetof and Keyword_MacroStd_offsetof.
    • tokens spelling: "__builtin_offsetof" and "offsetof".
    • lexing of Keyword_ExtGNU___builtin_offsetof is conditional to already existing LanguageExtensions::isEnabled_ExtGNU_InternalBuiltins.
    • lexing of Keyword_MacroStd_offsetof is conditional to not yet existing MacroTranslations::isEnabled_Translate_offsetof_AsKeyword; this enablement flag, alongside the corresponding MacroTranslations::enable_Translate_va_arg_AsKeyword must be created.
    • new nodes syntaxes: OffsetOfExpressionSyntax inheriting from ExpressionSyntax; OffsetOfDesignatorSyntax inheriting from DesignatorSyntax; FieldOffsetOfDesignatorSyntax and ArrayOffsetOfDesignator both inheriting OffsetOfDesignatorSyntax.
  2. Parse the syntax

    • at Parser::parseExpressionWithPrecedencePostfix at labels Keyword_ExtGNU___builtin_offsetof and offsetof.
    • new method Parser::parseOffsetOfExpression_AtFirst.
    • new method Parser::parseOffsetOfDesignator, Parser::parseFieldOffsetOfDesignator_AtFirst, and Parser::parseArrayOffsetOfDesignator_AtFirst.
  3. Test the syntax

    • for Keyword_ExtGNU___builtin_offsetof, in TestParser::case1960' to TestParser::ca.se1969'
    • for Keyword_MacroStd_offsetof, in TestParser::case3010' to TestParser::case3019'.

Emit C code from user-defined AST?

In Python I can do this:

class_reduction_v2 = ClassDef(
    name="ReductionV2",
    bases=[],
    keywords=[],
    body=[
        Expr(value=set_value("foo")),
        Assign(targets=[Name(id="AUTO", ctx=Store())], value=set_value("auto")),
        Assign(targets=[Name(id="NONE", ctx=Store())], value=set_value("none")),
        Assign(targets=[Name(id="SUM", ctx=Store())], value=set_value("sum")),
        Assign(
            targets=[Name(id="SUM_OVER_BATCH_SIZE", ctx=Store())],
            value=set_value("sum_over_batch_size"),
        ),
    ],
    decorator_list=[],
)

Which produces:

class ReductionV2:
    """ foo """
    AUTO = 'auto'
    NONE = 'none'
    SUM = 'sum'
    SUM_OVER_BATCH_SIZE = 'sum_over_batch_size'

Looks like neither LLVM LibTooling nor LLVM libclang have support for this:
https://discourse.llvm.org/t/create-and-emit-ast-for-struct-clang-recorddecl/61383

Is this something you would consider adding to Psyche-C? 🥇

`_Atomic` keyword unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

atomic.c:0:0 warning: missing type specifier, assume `int'atomic.c:0:8 error: expected `,' or `;' or `=' after declarator, got `int'
_Atomic int i;
        ^

(return code 0)

Content of file

_Atomic int i;

psychec version

commit ca31d32becabd3abf70fc8c82a86f4f57d1b6323
Author: Leandro T. C. Melo <[email protected]>
Date:   Sat Mar 13 14:56:40 2021 -0300

    disable certain lang. extensions by default

Fail with "cnip: preprocessor invocation failed" on large file

Description

Generate a large large file:

for i in $(seq 1 100000); do echo "int i$i;" >> a.c; done

Run cnip:

./cnip a.c

Get the error:

cnip: preprocessor invocation failed

Version

commit cb578e9d10c2cc67980e9f383f9afd542f784e17 (HEAD -> master, origin/master, origin/HEAD)
Author: Leandro T. C. Melo <[email protected]>
Date:   Mon Feb 22 10:24:11 2021 -0300

    add Psyche-C logo

Expected behavior

I would expect cnip run without any error.

Something wrong when I dumped AST with codes like"sum = 3 * M + 4 * M + 5 * M;"

source code:

int main() {
int sum=5;
sum = 3 * M + 4 * M + 5 * M;
int test=assgin(sum);
printf(sum);
return 0;
}

AST:

TranslationUnit
|--FunctionDefinition <54:2162..54:2173> int main() {
|--BuiltinTypeSpecifier <54:2162..54:2164> int
|--FunctionDeclarator <54:2166..54:2170> main(
| |--IdentifierDeclarator <54:2166..54:2169> main
| |--ParameterSuffix <54:2170..54:2171> ()
|--CompoundStatement <54:2173..60:2260> { int sum=5; sum = 3 * M + 4 *...
|--DeclarationStatement <55:2175..55:2177> int
| |--VariableAndOrFunctionDeclaration <55:2175..55:2184> int sum=5;
| |--BuiltinTypeSpecifier <55:2175..55:2177> int
| |--IdentifierDeclarator <55:2179..55:2183> sum=5
| |--ExpressionInitializer <55:2183..55:2183> 5
| |--IntegerConstantExpression <55:2183..55:2183> 5
|--ExpressionStatement <56:2186..56:2213> sum = 3 * M + 4 * M + 5 * M;
| |--BasicAssignmentExpression <56:2186..56:2192> sum = 3
| |--IdentifierName <56:2186..56:2188> sum
| |--AddExpression <56:2192..56:2208> 3 * M + 4 * M + 5
| |--AddExpression <56:2192..56:2200> 3 * M + 4
| | |--MultipliyExpression <56:2192..56:2196> 3 * M
| | | |--IntegerConstantExpression <56:2192..56:2192> 3
| | | |--IdentifierName <56:2196..56:2196> M
| | |--MultipliyExpression <56:2200..56:2204> 4 * M
| | |--IntegerConstantExpression <56:2200..56:2200> 4
| | |--IdentifierName <56:2204..56:2204> M
| |--MultipliyExpression <56:2208..56:2212> 5 * M
| |--IntegerConstantExpression <56:2208..56:2208> 5
| |--IdentifierName <56:2212..56:2212> M
|--DeclarationStatement <57:2215..57:2217> int
| |--VariableAndOrFunctionDeclaration <57:2215..57:2235> int test=assgin(sum);
| |--BuiltinTypeSpecifier <57:2215..57:2217> int
| |--IdentifierDeclarator <57:2219..57:2229> test=assgin
| |--ExpressionInitializer <57:2224..57:2229> assgin
| |--CallExpression <57:2224..57:2234> assgin(sum)
| |--IdentifierName <57:2224..57:2229> assgin
| |--IdentifierName <57:2231..57:2233> sum
|--AmbiguousCallOrVariableDeclaration <58:2237..58:2242> printf
| |--DeclarationStatement <58:2237..58:2242> printf
| | |--VariableAndOrFunctionDeclaration <58:2237..58:2248> printf(sum);
| | |--TypedefName <58:2237..58:2242> printf
| | |--ParenthesizedDeclarator <58:2243..58:2247> (sum)
| | |--IdentifierDeclarator <58:2244..58:2246> sum
| |--ExpressionStatement <58:2237..58:2248> printf(sum);
| |--CallExpression <58:2237..58:2247> printf(sum)
| |--IdentifierName <58:2237..58:2242> printf
| |--IdentifierName <58:2244..58:2246> sum
|--ReturnStatement <59:2250..59:2258> return 0;
|--IntegerConstantExpression <59:2257..59:2257> 0

ERROR:

  |     |--IdentifierDeclarator  <57:2219..57:2229>  `test=assgin`
  |        |--ExpressionInitializer  <57:2224..57:2229>  `assgin`

  |--ExpressionStatement  <56:2186..56:2213>  `sum = 3 * M + 4 * M + 5 * M;`
  |  |--BasicAssignmentExpression  <56:2186..56:2192>  `sum = 3`
  |     |--IdentifierName  <56:2186..56:2188>  `sum`

I think there is something wrong with ‘=’. The content next to '=' will be always extracted with the variable before '='.

Segfault in SyntaxNode::kind() on Else-If-Statement

Description

Trying to compile the appended code snippet with ./cnip --C-infer causes the program to segfault in SyntaxNode::kind() as the node appears to be a null pointer. I also appended a full stack trace.

static void ccid3_hc_tx_update_x(struct sock *sk, ktime_t *stamp)
{
 struct ccid3_hc_tx_sock *hc = ccid3_hc_tx_sk(sk);
 __u64 min_rate = 2 * hc->tx_x_recv;
 const __u64 old_x = hc->tx_x;
 ktime_t now = stamp ? *stamp : ktime_get_real();

 if (ccid3_hc_tx_idle_rtt(hc, now) >= 2) {
  min_rate = rfc3390_initial_rate(sk);
  min_rate = max(min_rate, 2 * hc->tx_x_recv);
 }

 if (hc->tx_p > 0) {

  hc->tx_x = min(((__u64)hc->tx_x_calc) << 6, min_rate);
  hc->tx_x = max(hc->tx_x, (((__u64)hc->tx_s) << 6) / TFRC_T_MBI);

 } else if (ktime_us_delta(now, hc->tx_t_ld) - (s64)hc->tx_rtt >= 0) {

  hc->tx_x = min(2 * hc->tx_x, min_rate);
  hc->tx_x = max(hc->tx_x,
          scaled_div(((__u64)hc->tx_s) << 6, hc->tx_rtt));
  hc->tx_t_ld = now;
 }

 if (hc->tx_x != old_x) {
  ccid3_pr_debug("X_prev=%u, X_now=%u, X_calc=%u, "
          "X_recv=%u\n", (unsigned int)(old_x >> 6),
          (unsigned int)(hc->tx_x >> 6), hc->tx_x_calc,
          (unsigned int)(hc->tx_x_recv >> 6));

  ccid3_update_send_interval(hc);
 }
}

Full stack trace below:

#0  0x00007ffff7cd3b1c in psy::C::SyntaxNode::kind (this=0x0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:47
#1  0x00007ffff7d242df in psy::C::Disambiguator::visitMaybeAmbiguousStatement<psy::C::StatementSyntax> (this=0x7fffffffc6d0, node=@0x5555556dca58: 0x0)
    at /home/user/psychec/C/reparser/Disambiguator.cpp:87
#2  0x00007ffff7d23bc9 in psy::C::Disambiguator::visitIfStatement (this=0x7fffffffc6d0, node=0x5555556dca10) at /home/user/psychec/C/reparser/Disambiguator.cpp:373
#3  0x00007ffff7d1ff94 in psy::C::IfStatementSyntax::dispatchVisit (this=0x5555556dca10, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNodes_Statements.h:185
#4  0x00007ffff7cd4302 in psy::C::SyntaxNode::acceptVisitor (this=0x5555556dca10, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:129
#5  0x00007ffff7cdbd1f in psy::C::SyntaxNode::acceptVisitor (node=0x5555556dca10, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.h:96
#6  0x00007ffff7cdb4c1 in psy::C::SyntaxVisitor::visit (this=0x7fffffffc6d0, node=0x5555556dca10) at /home/user/psychec/C/syntax/SyntaxVisitor.cpp:39
#7  0x00007ffff7d24438 in psy::C::Disambiguator::visitMaybeAmbiguousStatement<psy::C::StatementSyntax> (this=0x7fffffffc6d0, node=@0x5555556dd0d0: 0x5555556dca10)
    at /home/user/psychec/C/reparser/Disambiguator.cpp:114
#8  0x00007ffff7d23ade in psy::C::Disambiguator::visitCompoundStatement (this=0x7fffffffc6d0, node=0x5555556dbed8) at /home/user/psychec/C/reparser/Disambiguator.cpp:345
#9  0x00007ffff7d1f60c in psy::C::CompoundStatementSyntax::dispatchVisit (this=0x5555556dbed8, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNodes_Statements.h:79
#10 0x00007ffff7cd4302 in psy::C::SyntaxNode::acceptVisitor (this=0x5555556dbed8, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:129
#11 0x00007ffff7cd4201 in psy::C::SyntaxNode::visitChildren (this=0x5555556dbe88, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:107
#12 0x00007ffff7cd431e in psy::C::SyntaxNode::acceptVisitor (this=0x5555556dbe88, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:131
#13 0x00007ffff7cdbd1f in psy::C::SyntaxNode::acceptVisitor (node=0x5555556dbe88, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.h:96
#14 0x00007ffff7cdb4c1 in psy::C::SyntaxVisitor::visit (this=0x7fffffffc6d0, node=0x5555556dbe88) at /home/user/psychec/C/syntax/SyntaxVisitor.cpp:39
#15 0x00007ffff7d24526 in psy::C::SyntaxCorrelationDisambiguator::visitTranslationUnit (this=0x7fffffffc6d0, node=0x5555556dba20) at /home/user/psychec/C/reparser/Disambiguator_SyntaxCorrelation.cpp:47
#16 0x00007ffff7cf7834 in psy::C::TranslationUnitSyntax::dispatchVisit (this=0x5555556dba20, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNodes_Declarations.h:600
#17 0x00007ffff7cd4302 in psy::C::SyntaxNode::acceptVisitor (this=0x5555556dba20, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.cpp:129
#18 0x00007ffff7cdbd1f in psy::C::SyntaxNode::acceptVisitor (node=0x5555556dba20, visitor=0x7fffffffc6d0) at /home/user/psychec/C/syntax/SyntaxNode.h:96
#19 0x00007ffff7cdb4c1 in psy::C::SyntaxVisitor::visit (this=0x7fffffffc6d0, node=0x5555556dba20) at /home/user/psychec/C/syntax/SyntaxVisitor.cpp:39
#20 0x00007ffff7d2353a in psy::C::Disambiguator::disambiguate (this=0x7fffffffc6d0) at /home/user/psychec/C/reparser/Disambiguator.cpp:41
#21 0x00007ffff7d2aa83 in psy::C::Reparser::reparse (this=0x7fffffffc760, tree=0x5555556d3340) at /home/user/psychec/C/reparser/Reparser.cpp:65
#22 0x00007ffff7cb6c38 in psy::C::SyntaxTree::buildFor (this=0x5555556d3340, syntaxCategory=psy::C::SyntaxTree::SyntaxCategory::UNSPECIFIED) at /home/user/psychec/C/SyntaxTree.cpp:290
#23 0x00007ffff7cb6447 in psy::C::SyntaxTree::parseText (text=..., textPPState=psy::C::TextPreprocessingState::Preprocessed, textCompleteness=psy::C::TextCompleteness::Fragment, parseOptions=..., 
    filePath="test.c", syntaxCategory=psy::C::SyntaxTree::SyntaxCategory::UNSPECIFIED) at /home/user/psychec/C/SyntaxTree.cpp:136
#24 0x0000555555634883 in cnip::CCompilerFrontend::constructSyntaxTree (this=0x5555556d5130, 
    srcText="# 1 \"<stdin>\"\n# 1 \"<built-in>\"\n# 1 \"<command-line>\"\n# 31 \"<command-line>\"\n# 1 \"/usr/include/stdc-predef.h\" 1 3 4\n\n# 1 \"/usr/include/stdc-predef.h\" 3 4\n/* Copyright (C) 1991-2020 Free Software Foundati"..., fi=...) at /home/user/psychec/cnippet/CompilerFrontend_C.cpp:158
#25 0x0000555555634539 in cnip::CCompilerFrontend::preprocess (this=0x5555556d5130, 
    srcText="static void ccid3_hc_tx_update_x(struct sock *sk, ktime_t *stamp)\n{\n struct ccid3_hc_tx_sock *hc = ccid3_hc_tx_sk(sk);\n __u64 min_rate = 2 * hc->tx_x_recv;\n const __u64 old_x = hc->tx_x;\n ktime_t n--Type <RET> for more, q to quit, c to continue without paging--
ow "..., fi=...) at /home/user/psychec/cnippet/CompilerFrontend_C.cpp:128
#26 0x0000555555633cdc in cnip::CCompilerFrontend::run (this=0x5555556d5130, 
    srcText="static void ccid3_hc_tx_update_x(struct sock *sk, ktime_t *stamp)\n{\n struct ccid3_hc_tx_sock *hc = ccid3_hc_tx_sk(sk);\n __u64 min_rate = 2 * hc->tx_x_recv;\n const __u64 old_x = hc->tx_x;\n ktime_t now "..., fi=...) at /home/user/psychec/cnippet/CompilerFrontend_C.cpp:65
#27 0x000055555566751c in cnip::Driver::execute (this=0x7fffffffd4d7, argc=1, argv=0x7fffffffd5e8) at /home/user/psychec/cnippet/Driver.cpp:131
#28 0x00005555556104ca in main (argc=3, argv=0x7fffffffd5e8) at /home/user/psychec/cnippet/Main.cpp:32

Version

fe1dabb

Expected behavior

Ideally cnip should be able to process else-if-statements, as they are covered by the C-Standard, but at least terminate gracefully if this kind of error cannot be recovered from.

Thank you very much!

Cannot parse functions that return pointers

Compiled without errors with GCC and Clang with options -c -std=c11 -pedantic.

ISO C Standard
-std=c11

Version

commit cb578e9d10c2cc67980e9f383f9afd542f784e17 (HEAD -> master, origin/master, origin/HEAD)
Author: Leandro T. C. Melo <[email protected]>
Date:   Mon Feb 22 10:24:11 2021 -0300

    add Psyche-C logo

The snippet

int *f() {
  return 0;
}

Help needed to run psychec

Hi, thanks for your contribution. This project is very interesting.

I'm trying to run pyschec and I've found 2 issues:

  1. Even after running cmake and make as advised in the README, the psychecgen binary is not generated.
  2. Executing the cnip binary doesn't produce any output/file, except when I ask it to dump the AST. For instance, the command: ./cnip --file node.c --C-infer has no effect at all.

What am I doing wrong? Many thanks in advance.

__builtin_va_arg variadic arguments unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

varargs.c:0:57 error: expected expression got `long'
long a(__builtin_va_list b) { return __builtin_va_arg(b, long); }
                                                         ^

(return code 0)

Content of file

long a(__builtin_va_list b) { return __builtin_va_arg(b, long); }

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

`volatile` keyword unsupported on structure declaration

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

volatile_typedef_struct.c:4:2 error: expected <identifier> or `(' starting direct-declarator, got `volatile'
} volatile st;
  ^

(return code 0)

Content of file

struct {
  int m;
} volatile st;

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

`unsigned` modifier on `__INT32_TYPE__ ` unsupported

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

llvm.c:0:24 error: expected `,' or `;' or `=' after declarator, got `uint32_t'
unsigned __INT32_TYPE__ uint32_t;
                        ^

(return code 0)

Content of file

unsigned __INT32_TYPE__ uint32_t;

psychec version

commit d10dc1ddfb7ea845f59274a4d6ca5d021ab31423
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Mar 9 21:18:30 2021 -0300

    fix postfixing on compound literal

Parsing does not finish; `cnip` eats RAM

When testing this, I left cnip running for 3 minutes; it ate > 13.8 GiB of RAM

Edit: I didn't file this as a parser bug, because I don't actually get a "[e]rror and/or warning in snippet cleanly compiled by both GCC and Clang", so I can't say it is a parsing bug.

GCC version:

gcc (SUSE Linux) 10.2.1 20210303 [revision 85977f624a34eac309f9d77a58164553dfc82975]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

Command terminated by signal 9
	Command being timed: "/home/avj/clones/psychec/master/build/cnip test.c"
	User time (seconds): 180.03
	System time (seconds): 2.93
	Percent of CPU this job got: 99%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 3:02.97
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 14518888
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 3626106
	Voluntary context switches: 10
	Involuntary context switches: 251
	Swaps: 0
	File system inputs: 0
	File system outputs: 0
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
(return code 0)

Content of file

extern char array[11];
int foo(void) {
  return sizeof(struct {
    _Static_assert(
        !__builtin_types_compatible_p(__typeof(array), __typeof(&(array)[0])),
        "");
    int x;
  });
}

psychec version

commit 603ac817fbb27c9391687ff708fde41ed6e9ab0d
Author: Leandro T. C. Melo <[email protected]>
Date:   Fri Mar 19 17:32:08 2021 -0300

    support _Atomic type specifier

`_Complex` keyword is unsupported

If eligible for the bounty, I wish this to be donated to a local animal charity of the maintainer's choice

GCC version:

gcc (SUSE Linux) 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9]

clang version:

clang version 11.0.1

Output of gcc -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of clang -Werror -Wall -Wextra -Wpedantic -pedantic -std=c11 -c $FNAME

(return code 0)

Output of cnip $FNAME

pr90840.c:1:14 warning: missing type specifier, assume `int'
# 1 "<stdin>"
              ^
pr90840.c:2:9 error: expected , or `;' or = after declarator, got `double'
_Complex double qux_c;
         ^

(return code 0)

Content of file

_Complex double qux_c;

psychec version

commit 6d7b8249e0f28af105112b217cb33a24f666e148
Author: Leandro T. C. Melo <[email protected]>
Date:   Tue Feb 23 07:47:25 2021 -0300

    link expression-parsing table in Doxygen documentation

psychecsolver-exe: user error (Cannot unify types with different constructors: char void)

Hi, thanks for this really interesting project.

I am interested in the type inference offered by psyche-c. I see this is only available in the "original" branch of the project at the moment.

I have successfully built all components on this branch and I have been able to use cnip.sh to compile some simple examples, like the one given in the readme.

However, when I try to use cnip.sh on more complex examples I nearly always receive this:

psychecsolver-exe: user error (Cannot unify types with different constructors:
char and void)

(sometimes with different types e.g. bool or int)

I looked at some of the examples in the accompanying research paper and I attempted to get cnip.sh to work with them. For example, I tried to compile basename.c from the GNU Coreutils project (version 8.27) after commenting out the includes and top level declarations. However, this resulted in the same error.

I read that macros can also cause issues, so included the correct definitions for the macros identified in the research paper as causing syntax errors. Despite this I'm still unable to compile the code.

I have attached the code I am attempting to use cnip.sh with as an example.
basename.c.txt
macros.h.txt

Is this due to limitations of psyche-c or am I doing something wrong?

Version

The "original" branch.

Expected behavior
cnip.sh is able to compile the attached basename.c file (with or without the macros.h).

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.