freebasic / fbfrog Goto Github PK

FreeBASIC's OOP is compatible with C++. Generate bindings from simple C++ headers should be possible. This will save much of the work needed to port C++ headers. Of course, one will have to edit them afterward by hand as always.

The candidate for this is the FLTK library. Using very simple C++ and no templates. It's the ideal test case for this feature if it will ever be added.

Please consider update your FreeBSD defines. It's currently target FreeBSD 10. FreeBSD already has FreeBSD 13 released now. And please add support for Solaris (OpenIndiana) and DragonflyBSD, currently they are not on the list of available targets. Thanks.

typedef unsigned int jit_uint;
#define	jit_label_undefined	((size_t)~((jit_uint)0))

(which has value 4294967295 on both x86-linux and x86_64-linux)
is translated by fbfrog (latest git head) to

type jit_uint as ulong
#define jit_label_undefined cuint(not cast(jit_uint, 0))

which has value 4294967295 on x86-linux and 18446744073709551615 on x86_64-linux.

On the other hand

#define	jit_label_undefined	((size_t)~((unsigned int)0))

translates to

const jit_label_undefined = cuint(culng(not culng(0)))

which has the correct value, 4294967295, on x86 and x86_64.

The double casts are necessary to paper over the difference in integer promotion rules between FB and C (which promote to integer and int respectively).

Currently, fbfrog ignores forward struct declarations by default, if no definition of the struct appears later:

struct Typ;
extern Typ *x;

translates to

extern x as Typ ptr

whereas if struct Typ {int a;}; appears later you get

type Typ as Typ_
extern x as Typ ptr

type Typ_
	a as long
end type

Without the definition, adding -addforwarddecl Type is necessary to get a working translation.

Why not add a forward declaration automatically if there is a C declaration but no definition; is it not desirable for some reason, or is it simply not implemented? The only reason to avoid doing so that I can think of is if there's another header that fbfrog wasn't given which will have already defined it. But that would be the exception, not the norm, accommodated with a -noforwarddecl option.

Compiled with FreeBASIC Compiler - Version 1.05.0 (11-01-2015), built for linux-x86_64 (64bit).

I get a null-pointer access on line 53 in util-hash.bas

==5959== Command: ./fbfrog
==5959== 

Aborting due to runtime error 7 (null pointer access) at line 53 of util-hash.bas::GROWTABLE()

Fixing that by checking "item" for being 0, I get this:

==6959== Command: ./fbfrog
==6959== 
==6959== Invalid read of size 8
==6959==    at 0x46036C: THASH::GROWTABLE() (util-hash.bas:53)
==6959==    by 0x460508: THASH::LOOKUP(char*, unsigned int) (util-hash.bas:69)
==6959==    by 0x46093D: THASH::CONTAINS(char*, unsigned int) (util-hash.bas:128)
==6959==    by 0x4696BC: FBKEYWORDSINIT (util.bas:539)
==6959==    by 0x47AAEC: __libc_csu_init (in /home/user/fbfrog/fbfrog)
==6959==    by 0x57E059E: (below main) (in /usr/lib/libc-2.22.so)
==6959==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==6959== 
==6959== 
==6959== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==6959==    at 0x55B3C39: raise (in /usr/lib/libpthread-2.22.so)
==6959==    by 0x57F367F: ??? (in /usr/lib/libc-2.22.so)
==6959==    by 0x46036B: THASH::GROWTABLE() (util-hash.bas:53)
==6959==    by 0x460508: THASH::LOOKUP(char*, unsigned int) (util-hash.bas:69)
==6959==    by 0x46093D: THASH::CONTAINS(char*, unsigned int) (util-hash.bas:128)
==6959==    by 0x4696BC: FBKEYWORDSINIT (util.bas:539)
==6959==    by 0x47AAEC: __libc_csu_init (in /home/user/fbfrog/fbfrog)
==6959==    by 0x57E059E: (below main) (in /usr/lib/libc-2.22.so)

I tried writing a fix, but since I don't fully understand your code and the obvious did not work, I feared I might do more harm than good.

If a .fbfrog file ends on a # comment with no newline after it something goes wrong, apparently an invalid pointer is followed and it errors out.

> fbfrog test.fbfrog test.h 
[ 1/23] linux-x86
#include "E"
(1): could not open file: '/mnt/common/src/!lang/fbbindings/E'

where test.fbfrog contains a single byte, #, and test.h doesn't even contain any #include lines. The #include filenames I've seen are one or two characters of garbage.

An insignificant bug; I'm just filing it so I can ignore it.

To my surprise, on examing the assembly/C, I realise that a boolean is stored as a value of either 0 or 1 in a byte, and is converted to/from 0/-1 when converting to/from a numerical type. This appears to mean it is exactly the same as C's _Bool (or bool with stdbool.h).

Therefore, why doesn't fbfrog convert _Bool to boolean? The fact that it instead translates to 'byte' breaks code such as while not WindowShouldClose() (function returning a bool) from the raylib examples and all previous translations of those examples and headers into FB, so I feel I have no choice but to edit my new translation of raylib.bi to use boolean.

Boolean was only added in 2015, so I guess it was just never implemented.
I'm currently working on this, and have come across no problems so far.
The only concern is whether there's any case where this would break code using existing headers, if the headers are regenerated.