binaryanalysisplatform / frontc Goto Github PK

Trying to parse string.h from my system, I get this error:

Syntax error: extern int strerror_r (int __errnum, char *__buf, size_t __buflen) __asm__ ("" "__xpg_strerror_r") __attribute__ ((__nothrow__ , __leaf__))

You can reproduce with something like:

extern int foo() __asm__("") __attribute(());

which doesn't parse, whereas

extern int foo() __attribute(()) __asm__("");

does. I think this is because the rule global has a case for global_type global_proto basic_asm SEMICOLON, and global_proto can have attributes, so the second case is covered.

Example,

/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h[21] Syntax error: extern int __fpclassifyf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__))

Using calipso/FrontC 4.0.0 on Fedora34:

cat >x.c <<EOF
#include "caml/mlvalues.h"
#include "caml/memory.h"
#include "caml/alloc.h"

value dummy(value x) {
  CAMLparam1(x);
  CAMLreturn(x);
}
EOF

calipso_stat -p 'gcc -std=c99 -E -I /home/edwin/.opam/4.11.0/lib/ocaml/ %i -o %o' y.c
/home/edwin/.opam/4.11.0/lib/ocaml/caml/misc.h[214] Syntax error: static inline int caml_uadd_overflow(uintnat a, uintnat b, uintnat * res)
goto total = 0
goto average = -
goto maximum = 0
goto functions = 0
label total = 0
label average = -
label maximum = 0
label functions = 0

Note: std=c99 is needed otherwise it fails at a different place:
/usr/lib/gcc/x86_64-redhat-linux/11/include/stddef.h[416] Syntax error: long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));

(If I save the preprocessed file and delete the inline the next failure will be:
/usr/include/stdio.h[415] Syntax error: extern int sscanf (const char *__restrict __s, const char *__restrict __format, ...) __asm__ ("" "__isoc99_sscanf") __attribute__ ((__nothrow__ , __leaf__)))

Hi,

from latest master, I'm having issues with a file that defines a new type and uses it right after it:

typedef struct my_t {
  int foo;
} my_t;
my_t bar();

gives me a parsing error on my_t on the last line. However:

typedef struct my_t {
  int foo;
} my_t;
int baz();
my_t bar();

gives no parsing error

FrontC fails to parse the following:

typedef int a;
typedef int b;
typedef b a;

even though this is accepted by clang.

Probably related is that FrontC fails to parse the following:

typedef int a;
typedef int a;

even though this is also accepted by clang.

FrontC cannot parse

typedef int int_t;
struct test1{
  int_t a : 4;
  int b : 13;
  int c : 1;
};

If we remove the typedef, then it works

struct test1{
  int a : 4;
  int b : 13;
  int c : 1;
};

Sorry, here's another one :D

struct point {
  int    x;
  int    y;
};

int main() {
  struct point p = { .y = 2, .x = 1 };
}

fails to parse the initialization of variable p.

designated initializer style is a C99 feature.

Hi,

I recently came to learn the existence of another FrontC repository maintained by the TRACES team/University of Toulouse, the original authors (Hugues Cassé).
The repository lives at https://git.renater.fr/anonscm/git/orange/Frontc.git (project is https://sourcesup.renater.fr/scm/?group_id=5026).

You can preview the large diff at https://github.com/BinaryAnalysisPlatform/FrontC/compare/master...jordr:FrontC:sourcesup?expand=1
Do you know what's going on / suggest a course of action?

If we parse and print the following example

const char *foo(const char *q, char const *z){
  return q;
}

shows up as

char  const *foo(char  const *q, char  const *z)
{
	return q;
}

const char * became char const *, which is causing compile errors.

FrontC only has the cma and cmxa files. Please include the cmxs in the distribution.

Frontc can't parse enums which have a trailing comma after the last variant.

// enum-commas.c
typedef enum {
  Little,
  Medium,
  Big,
} Size;

Calling parse_file prints the error message enum-commas.c[5] Syntax error: } Size;.

Hi,

now that the previous issues are fixed, I have more :D. This time, it's about anonymous structs and unions:

struct Scope {
    // Anonymous union
    union {
        char alpha;
        int num;
    };
};

struct Scope2
{
    // Anonymous structure
    struct
    {
        char alpha;
        int num;
    };
};

both structs have a parsing error, because a field is supposed to be a type with names, but the inner union and struct do not have a name. This is apparently part of C11, and also a GNU extension (in the file I have, the anonymous union is even preceded by __extension__). I tried applying the attached patch, but ctoxml gives me back empty structs:

<file>
	<struct id="struct:Scope"/>
	<struct id="struct:Scope2"/>
</file>

anonymous-union-structs.patch

FrontC reverses the fields in a struct. For example, it parses

struct pair{
  int *first;
  int *second;
  int len;
};

as

struct pair{
  int len;
  int *second;
  int *first;
};

PARSING_OK
 [Cabs.ONLYTYPEDEF
   (Cabs.STRUCT ("pair",
     [(Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN), Cabs.NO_STORAGE,
       [("len", Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN), [], Cabs.NOTHING)]);
      (Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN), Cabs.NO_STORAGE,
       [("second", Cabs.PTR (Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN)), 
         [], Cabs.NOTHING)]);
      (Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN), Cabs.NO_STORAGE,
       [("first", Cabs.PTR (Cabs.INT (Cabs.NO_SIZE, Cabs.NO_SIGN)), [],
         Cabs.NOTHING)])]),
    Cabs.NO_STORAGE, [])]

FrontC 3.4 keeps the original order.

- ocamlc   unix.cma ../frontc/frontc.cma -o calipso_stat gen.cmo reduce.cmo 
- make[1]: Leaving directory `/home/travis/.opam/4.07.0/.opam-switch/build/FrontC.3.4.2/calipso'
- make[1]: Entering directory `/home/travis/.opam/4.07.0/.opam-switch/build/FrontC.3.4.2/frontc'
- make[1]: Circular cparser.cmx <- clexer.cmx dependency dropped.
- make[1]: Circular cparser.cmx <- clexer.cmx dependency dropped.
- install -d /home/travis/.opam/4.07.0/lib/FrontC
- install frontc.cma cabs.cmi cxml.cmi cprint.cmi clexer.cmi cparser.cmi ctoxml.cmi frontc.cmi /home/travis/.opam/4.07.0/lib/FrontC
- install -d /home/travis/.opam/4.07.0/lib/FrontC
- install frontc.cmxa frontc.a cabs.cmi cxml.cmi cprint.cmi clexer.cmi cparser.cmi ctoxml.cmi frontc.cmi /home/travis/.opam/4.07.0/lib/FrontC
- ocamldoc -html -d ../autodoc  -t "FrontC" cabs.ml cxml.ml cprint.ml ctoxml.ml frontc.ml
- ../autodoc/style.css: No such file or directory
- Fatal error: exception Failure("../autodoc/Cabs.html: No such file or directory")
- make[1]: *** [doc] Error 2
- make[1]: Leaving directory `/home/travis/.opam/4.07.0/.opam-switch/build/FrontC.3.4.2/frontc'
- make[1]: Entering directory `/home/travis/.opam/4.07.0/.opam-switch/build/FrontC.3.4.2/ctoxml'
- install -d /home/travis/.opam/4.07.0/lib/bin
- install ctoxml /home/travis/.opam/4.07.0/lib/bin

See the full log here: https://travis-ci.org/BinaryAnalysisPlatform/bap/jobs/570684148#L2032

It is a build failure for 4.07 OCaml version for my 4.08 PR BinaryAnalysisPlatform/bap#957

I am trying to load frontc dynamically. If I compile native, it shows this error:

Warning 58: no `cmx` file was found in path for module `Frontc`, and its interface was not compiled with `-opaque`

When execute, it fails with this error:

Error during dynlink: error loading shared library: Dynlink.Error (Dynlink.Cannot_open_dll "Failure(\"/path/bar.cmxs: undefined symbol: camlFrontc\")")

If I compile byte, it compiles, but when I run,

Error during dynlink: this object file uses unsafe features

FrontC fails to parse __attribute__((__aligned__(__alignof__(long long)))). This appears in stddef.h on my system, or technically in __stddef_max_align_t.h which is #included in stddef.h.

I believe the root cause of the problem is that here, the rule which matches __alignof__(*) expects an identifier, a constant, or another expression involving parens, but instead it gets long long.

FrontC fails to parse the following:

int a() __asm__("" "");

even though this is accepted by clang.

The root cause for this one seems to be that global_dec doesn't include a case where there is __asm__ after the RPAREN; or, alternately, that opt_gcc_attributes, which would be accepted in this position, only allows __attribute__(...) and not __asm__(...).

I think it might be from a mistake during edition.
No complete version of the section has ever been published, so I can't guess what the fix would be.

$ dune.build
File "frontc/cxml.ml", line 43, characters 19-20:
Error: Syntax error

This is because of this code bit:

The following parses fine:

struct foo {
    unsigned int bf : 1;
};

but this does not:

typedef unsigned int uint;
struct foo {
    uint bf : 1;
};

FrontC fails to parse the static parameter in array size

void foo(char array[static 100]){
...
}