h_2_bi.bas, a tool for translating .h files into .bi

[TJF]

h_2_bi.bas is the FB source code of a command line tool to translate one or more header file(s) from programming language C into one single header file for FreeBasic.

It has been developed to translate GTK+ headers and was used successfully on sqlite3 and others as well. Some examples can be found here.

h_2_bi is controlled by a config file with suffix '.h2bi'. It generates exactly one output file in the current folder, named after the config file (suffix '.bi'). The output contains the result from translation, some untranslated C source as a FB-comments and if need be some hints on problems arising from translation process.

h_2_bi is an interactive tool. Be prepared to call it more than one time. It is a 'stupid' translator. That means it does not check types. The check will be done by the fbc later on. It also do not expand macros by default. If you need macro expansion you'll need to copy the desired macro defines into the config file.

The advantage of the 'stupid' translation is any result in all cases. The quality of the translation depends on the parameters h_2_bi gets from the config file.

h_2_bi isn't able to translate all possible C struktures from a C header. A small rest has to be manual translated. h_2_bi is aiming firstly a relaible translation and secondly to help as good as possible to manual translate the rest.

Details and download at http://www.freebasic-portal.de/download ... s-134.html

[JaDogg]

cool

[AGS]

Nice one, TJF. I'll be testing your app for a bit (I hope you don't mind some small(ish) 'bug reports').

[TJF]

Nice one, TJF.

Thank you!

I'll be testing your app for a bit (I hope you don't mind some small(ish) 'bug reports').

I thought about making an 'app' with GUI, but I didn't find real advantages. Your work and feedback on testing and reporting bugs is wellcome.

Hopefully more people will collect ideas for further releases (and translate a lot of up-to-date bindings for the community ;-).

[AGS]

Nice one, TJF.

Thank you!

I'll be testing your app for a bit (I hope you don't mind some small(ish) 'bug reports').

I thought about making an 'app' with GUI, but I didn't find real advantages. Your work and feedback on testing and reporting bugs is wellcome.

Hopefully more people will collect ideas for further releases (and translate a lot of up-to-date bindings for the community ;-).

So I took your program for a spin to see how much C it understands. Using the .rep files helped but I found that in some cases doing a global find - replace on a file gets results I cannot get with the .rep files.

I found that the program removes comments and removes the names of the names of parameters. Keeping a lot of the comments in was not too much of a hack.

With the following change to the source code comments that are at the 'global level' (ie not inside an enum, struct, or union declaration) get preserved.

The routine readcomm takes care of getting rid of the comment. I've altered this function slightly so it keeps comments in.

Code: Select all

SUB readCommTop(BYVAL Rd AS readDaten PTR)
  DIM AS UBYTE lz
  RES += !"/\'"
  WITH *Rd
    WHILE NOT EOF(.fnr)
      GET #.fnr, , .z
      IF .z = ASC("/") THEN IF lz = ASC("*") THEN RES += !"\'/\n":EXIT WHILE
      RES += Chr(.z)
      lz = .z
    WEND
  END WITH
END SUB

The only routine that uses the above routine is

Code: Select all

SUB readWort(BYVAL Rd AS readDaten PTR)

All the other routines call readComm.

I've not looked at the possibility to preserve names of parameters. I think I understand why you throw them away but it makes the header file harder to read.

I think a global .rep file would help to get rid of silly errors. For example, I got a file that contained this:

Code: Select all

U_STABLE UConverter* U_EXPORT2 

U_STABLE and U_EXPORT2 are macros that expand to whatever they expand to and are at the start of every prototype.

I tried to get rid of U_STABLE and U_EXPORT2 using the .rep files but to no avail, I could not get the h_2_bi to yield decent results (either U_STABLE or U_EXPORT2 kept the translation from working correct).

A global find-and-replace before translating the file did the trick (did that using an editor).

So perhaps you could add a global.rep that accepts words or sentences that get replaced regardless of what is represented by the sentence (a bit like post.rep, perhaps pre.rep?).

Other than that I'm actually quite impressed with this program. It's not overly complicated and it works. And if it doesn't work one simple find-and-replace helps out a lot.

Some ideas

I think you might be able to do something more with include files. The standard C header files are known (you could put them in a table) so translating those to something like

Code: Select all

#include "crt/stdio.bi"

I can post the list if you like. If you put it in a text file the user might add files to it so more automatic translation is possible. List could be like

stdio.h>crt/stdio.bi
stdlib.h>crt/stdlib.bi

Those header files are mostly used to get to things like a FILE pointer, standard type definitions (size_t and the like).

And I think that with a little help from a program like ectags you could get even better results. It would introduce an extra tool but it would also help out with recognizing identifiers a lot.

The output of ectags is (simply put) a lot of lines with each line consisting of:

name of identifier
type of identifier (macro or struct or union or enum or typedef or ...)
line number where identifier is defined
name of file where identifier is defined
first line of the text of what the identifier actually defines.

I've already got a program that reads the output of ectags, sorts it and puts the results in an array.

What ectags can do you can find at

http://ctags.sourceforge.net/desire.html

I think a combination of ectags and your approach to translating h2bi could yield results that are very good.

Perhaps using some hashtables would help (I'm afraid lookup time could become an issue when using a symbol table like the one produced by ectags).

Some more ideas:
- give the user a choice between output in UPPERCASE or Firstwordcase or some other type of case (Declare or DECLARE or declare). I am of course referring to FB keywords;
- give the user a choice between keeping comments in yes/no;
- a GUI, yes, a GUI. Thought about this long and hard and
selecting files/setting options is so much nicer using a GUI.
And you could show the result in some screen. The user then could go back to the start, change a setting, try again
and look at the results.

A simple wizard - thingy would do (just a bunch of screens with settings/file selection connected by Next/Prev and then a Translate button at the last screen that leads to a tabbed interface showing the results of the translation).

If the user is not satisfied with the output then a push on something like a Home button would.... you get the general idea.

Aside: the code I added is really bad. It just concatenates bytes to the output. That's about as SLOW as you can write that type of code (really bad) so if you'd want to include that comment stuff it might pay to change it into something better.

Now I'm not sure how to proceed. I could just start hacking away at your code and glue ectags to your tool. If you're not planning on updating h_2_bi then that would be the way to go.

If you, however, are planning to update the tool then...

[TJF]

@AGS:

Thanks a lot for your detailed test report.

Now I'm not sure how to proceed. I could just start hacking away at your code and ...

It seems that you like h_2_bi.bas, fine!
How to proceed? I'll make an update, including some of your ideas:

1.) There are some ideas I do not like:

a.) Including comments means making the fbc slow. During the translation process the comments may help a bit. You'll find them in the C source. Later on there is no need for comments into the FB header, because anyway the user has to look into the library documentation. In case of GTK the FB header is 1.5 Mb (without comments) and will take more than 1 second to compile at my system. With comment it will take more than 3 seconds. I call fbc 100 times a day. Comments costs me several minutes every day.

An other point of view: if I include comments, I'll make it possible to include every comment - main level comments as well as comments in enum, type, ... structures. This is a lot of work (for loosing time).

b.)

I think a global .rep file would help to get rid of silly errors....

A global 'find and replace' can be done by an editor (as you did). This is more userfriendly (WYSIWYG).

c.) The GUI. Your ideas are similar to mine. Additionally I thought about double clicking a line in FB source and the GUI will switch to the coresponding line in the C header, ...

But have a look at the number of views of this topic: less than 300 views in two weeks and just 4 replies. No users out there, no reason for a GUI. BTW I found a configuration for Geany that works fine.

Let me think about this for a while.


2.) There are issues I do not understand:
a.)

Code: Select all

U_STABLE UConverter* U_EXPORT2

Which code do you expect in FB source? (What's the definition of the macros?)

b.) Combining ectags and h_2_bi.bas results to the fact, that h_2_bi.bas isn't a 'stupid' translator any more. As I understand, the output of ectags can help a uman beeing to find good parameters for h_2_bi.bas. But a combination of both programms will result in an lot of work, just to translate a few lines of special C code (please show me that I'm wrong!).

From my point of view there is more potential to improve the translation of '#define' lines, e.g. CASTs. This will have more effect in reducing the manual work.


3.) Anyway, this ideas will find their way into the next h_2_bi.bas version:
a.) Writing names in the parameter lists of FUNCTIONs and SUBs is possible, but it makes the lines pretty long. I will add a switch.

b.)

I think you might be able to do something more with include files. The standard C header files are known (you could put them in a table) so translating those to something like

Code: Select all

#include "crt/stdio.bi"

I can post the list if you like. If you put it in a text file the user might add files to it so more automatic translation is possible. List could be like

stdio.h>crt/stdio.bi
stdlib.h>crt/stdlib.bi

Including standard headers makes sence. I'll add a file 'files.rep' to specify them, using the syntax you proposed (it means the character '>' can not be used in the filenames).

Thank you once more for your report - and have fun and success using h_2_bi.bas!

[AGS]

1.) There are some ideas I do not like:


a.) Including comments

Okay so no comments. You do the version without comments, and at some point of development I'll hack the code so it will do comments and make it an option.

c.) The GUI. Your ideas are similar to mine. Additionally I thought about double clicking a line in FB source and the GUI will switch to the coresponding line in the C header, ...

But have a look at the number of views of this topic: less than 300 views in two weeks and just 4 replies. No users out there, no reason for a GUI. BTW I found a configuration for Geany that works fine.

So no GUI. The views and replies have to do with the existing h2bi SWIG tool I think. You have to come up with something that's better than the h2bi SWIG tool. Stripping comments is one of the downsides of the SWIG tool.....

2.) There are issues I do not understand:
a.)

Code: Select all

U_STABLE UConverter* U_EXPORT2

Which code do you expect in FB source? (What's the definition of the macros?)

The definiton of the macros U_STABLE and U_EXPORT2 are either defined as empty or some removable C construct.

They should be removed from source but I could not get it done with a .rep file. The issue is that the converter got it wrong while I added U_STABLE and U_EXPORT2 to just about every .rep file so I was hoping h_2_bi would remove them (as I defined them like
U_STABLE>
U_EXPORT2>
) but the two persisted.

As this is a kind of construct that's used quite a lot it would be nice if the program could take care of it. The current program treats the two as types so you get

Code: Select all

Function <identifier>(<param_list>) AS U_STABLE U_EXPORT2

b.) Combining ectags and h_2_bi.bas results to the fact, that h_2_bi.bas isn't a 'stupid' translator any more. As I understand, the output of ectags can help a uman beeing to find good parameters for h_2_bi.bas. But a combination of both programms will result in an lot of work, just to translate a few lines of special C code (please show me that I'm wrong!).

If you're feeling lazy you can just use the tag information and walk through the tag file looking for enums, structs, typedefs and macros. You can use it as an index if you like.

Lines that are not in the tagfile are either preprocessor lines (#ifdef .... and the like) or not of interest (code or comment).

Combining it with your tool would mean that your program would go from scanning C code to looking up values in an index (the tags) and extracting-converting code text based on that index.

Same goes for enum, union etc... etc... ectags is for lazy people like me that like to use tools built by others (instead of building one myself).

From my point of view there is more potential to improve the translation of '#define' lines, e.g. CASTs. This will have more effect in reducing the manual work.

Casts? Are you planning to parse C expressions? An example:

Code: Select all

#define SYM_IS_FREE(sym)          (((MachineWord)(sym) & 1) == 1)

The cast is there: (MachineWord)(sym) and then there is the operator (&) and the == to.

Another one (really great stuff this):

Code: Select all

#define AT_isValidSymbol(sym) (((Symbol)sym >= 0 && (unsigned int)(Symbol)sym < AT_symbolTableSize() \
                                 && !SYM_IS_FREE(at_lookup_table[(Symbol)sym])) ?  ATtrue : ATfalse)

Examples were given to show that I'm seeing the potential and translating macros to FB looks to be a not so easy task. Can your program parse an (almost) arbitrary C expression?

3.) Anyway, this ideas will find their way into the next h_2_bi.bas version:
a.) Writing names in the parameter lists of FUNCTIONs and SUBs is possible, but it makes the lines pretty long. I will add a switch.

Break the paramlist after two parameters and add a line continuation just like you do in FB source code. You'd need to find some way of getting the indentation right but it should look great (it would certainly better than what the SWIG h2bi produces ;) ).

[TJF]

... and at some point of development I'll hack the code so it will do comments and make it an option.

Fine!

You have to come up with something that's better than the h2bi SWIG tool. Stripping comments is one of the downsides of the SWIG tool.....

From my point of view stripping untranslated C source is the main downside of SWIG. You'll have to spend a lot of time to find out which C source is translated and which isn't.
On this issue, h_2_bi.bas works much better than SWIG. It copies all untranslated C source as a comment into the FB code.

Anyway, I'm happy that you spend some time to improve h_2_bi.bas to make it a useful tool for both of us, and hopefully some further users.

CASTs:

Code: Select all

#define AT_isValidSymbol(sym) (((Symbol)sym >= 0 && (Unsigned Int)(Symbol)sym < AT_symbolTableSize() \
                                 && !SYM_IS_FREE(at_lookup_table[(Symbol)sym])) ?  ATtrue : ATfalse)

The logic ('&&', '!') will be tranlated in the current h_2_bi.bas version. Also the IIF ('?', ':') structure. I'm thinking about doing the CASTs as well, but I have to learn more about C expressions first (I never coded a C program longer than 20 lines).

Break the paramlist after two parameters and add a line continuation just like you do in FB source code. You'd need to find some way of getting the indentation right but it should look great (it would certainly better than what the SWIG h2bi produces ;) ).

Breaking parameter lines is a 'nice to have' feature. I'll add it if there is time left.

Your 'silly error':
Sorry for asking again: a C source like

Code: Select all

U_STABLE UConverter* U_EXPORT2;

h_2_bi.bas will never translate to

Code: Select all

Function <identifier>(<param_list>) As U_STABLE U_EXPORT2

Can you explain it again? I like to make h_2_bi.bas taking care of this construct, but I do not realy understand the problem nor the aim.

I think I had similar problems translating the GTK headers. They make use of the GSEAL macro. A line like

Code: Select all

GList *GSEAL (children);

has to be translated to

Code: Select all

children As GList Ptr

Is this want you need?

[TJF]

- give the user a choice between output in UPPERCASE or Firstwordcase or some other type of case (Declare or DECLARE or declare). I am of course referring to FB keywords;

Solution:
You may use the file 'post.rep' to get the desired character cases. Write lines like

Code: Select all

SUB>Sub
TO>To
END>End
DECLARE>Declare
...

[AGS]

- give the user a choice between output in UPPERCASE or Firstwordcase or some other type of case (Declare or DECLARE or declare). I am of course referring to FB keywords;

Solution:
You may use the file 'post.rep' to get the desired character cases. Write lines like

Code: Select all

SUB>Sub
TO>To
END>End
DECLARE>Declare
...

Tried changing casing using post.rep and it worked like a charm.


I've tested your program some more. And what I stated earlier about the // - style comments (or did I not mention those?) messed up translation. You see those a lot in C programs (most C compilers will allow using // inside C source).

I tried h_2_bi on a header file taken from the vtd-xml project.

I found the following issues:

C

Code: Select all

UByte* XMLDoc; // byte buffer containing
int docLen; // length of XML (can be a segment of XMLDoc)

Translation(FB)

Code: Select all

XMLDoc AS UByte PTR
docLen AS // byte buffer containing Integer

The // is not handled correctly.

A bug I found has to do with macro - translation (same header file, same project).

C

Code: Select all

#define MAX_TOKEN_LENGTH ((1<<20)-1)
#define MAX_PREFIX_LENGTH ((1<<9)-1)
#define MAX_QNAME_LENGTH ((1<<11)-1)

FB(translation)

Code: Select all

#DEFINE MAX_TOKEN_LENGTH ((1SHL20)-1)
#DEFINE MAX_PREFIX_LENGTH ((1SHL9)-1)
#DEFINE MAX_QNAME_LENGTH ((1SHL11)-1)

I tested the first macro with the following code

Code: Select all

Var x = MAX_TOKEN_LENGTH

and got an error.


D:\Program Files (x86)\FreeBASIC>fbc 1test.bas
1test.bas(5) error 7: Expected ')', found 'SHL20' in 'Var x = MAX_TOKEN_LENGTH'


Solution was simple: adding a space after the SHL removed the compiler error.

FB

Code: Select all

#DEFINE MAX_TOKEN_LENGTH ((1SHL 20)-1)
#DEFINE MAX_PREFIX_LENGTH ((1SHL 9)-1)
#DEFINE MAX_QNAME_LENGTH ((1SHL 11)-1)

And I found an issue with the word unsigned. In C unsigned on it's own means 'unsigned int'. In FB unsigned needs to be followed by some typespecifier (Integer, Byte etc...).

I tried to solve this by specifying

unsigned>Unsigned Integer

in the types.rep file. But then the program turned something like

unsigned char

into Unsigned Integer char (not what I want).

If I changed types.rep like so

unsigned char>UByte
unsigned>Unsigned Integer

it did work but when confonted with

unsigned MACRO_NAME


my solution will no doubt fail as MACRO_NAME does not match char and the program will produce UNSIGNED INTEGER MACRO_NAME which might not be correct.

You might be able to deal with this unsigned issue in some way during processing of a file.


I'm using the 0.20 version of FBC on Windows 7 Professional (64 bit).

And as an aside: would you like to have the header files I've tested your program on for regression testing (or other) purposes?

[TJF]

Tried changing casing using post.rep and it worked like a charm.

Fine! I tried changing it in the source but the code gets pretty unreadable.

... And what I stated earlier about the // - style comments (or did I not mention those?) messed up translation.

You did not mention it before and sorry, I didn't know about this kind of comment yet (also Kerninghan/Ritchie didn't write about that in their 2. Edition from 1989). I suppose this kind of comment ends at the line end?! I'll add this feature.

I'm using the 0.20 version of FBC on Windows 7 Professional (64 bit).

Nice to know that. I also use fbc 0.20 on Ubuntu 9.10 (32 Bit) and I didn't test on win32 yet.

And as an aside: would you like to have the header files I've tested your program on for regression testing (or other) purposes?

Your bug reports are pretty good. So if you don't mind, please keep on testing and inform me just about the errors.


I'm working on version 0.2 now. Already implemented:

• * The file 'files.rep' is implemented.
  * Variable names in parameter lists can be switched on/off.
  * The 'SHL20' bug and similar bugs are fixed.
  * 'unsigned' without a variable type is handled as 'UINTEGER' now.

Would you like to have an intermediate version? (If so, how to send?)

[AGS]

... And what I stated earlier about the // - style comments (or did I not mention those?) messed up translation.

You did not mention it before and sorry, I didn't know about this kind of comment yet (also Kerninghan/Ritchie didn't write about that in their 2. Edition from 1989). I suppose this kind of comment ends at the line end?! I'll add this feature.

// is the C version of the FB linecomment , it ends at the line end. It's part of C99 (ISO standard).

I use the offical ISO C99 definition as a C reference. You can get the document here

http://www.open-std.org/JTC1/SC22/wg14/www
/docs/n1124.pdf

I'm working on version 0.2 now. Already implemented:

• • * The file 'files.rep' is implemented.
    * Variable names in parameter lists can be switched on/off.
    * The 'SHL20' bug and similar bugs are fixed.
    * 'unsigned' without a variable type is handled as 'UINTEGER' now.

Would you like to have an intermediate version? (If so, how to send?)

I'll wait until the release.

In the meantime I'm going to be translating header files to see if some bugs turn up.

And I've found a 'bug'.

C

Code: Select all

struct USet;

FB (translation)

Code: Select all

TYPE USet
END TYPE

Example testing code:

Code: Select all

TYPE USet
END TYPE

Extern "C"

Declare Function x(ByVal s As USet) As Integer

End Extern

when compiled will yield the following error
> "D:\Program Files (x86)\FreeBASIC\fbc.exe" -g -exx 2test.bas
2test.bas(2) error 208: An ENUM, TYPE or UNION cannot be empty, found 'END' in 'END TYPE'

The forward declaration gets used in parameter lists.The only? way to fix this kind of thing is by declaring the struct as an alias for ANY.

Code: Select all

TYPE USet As Any

Removing the empty struct declaration completely is usually not possible as the type needs to get declared. Otherwise compilation of the header file will fail (USet gets used as a type in the paramlist of several function declarations).

I've come across a similar problem in a header file I translated by hand where I could not solve the problem using the ANY approach.

When a struct gets used inside a macro you usually need a type other than ANY or ANY PTR (the number of operations you can perform on a variable types as ANY or ANY PTR are limited). There is a workaround for this but that's an ugly one and I think it's beyond the scope of what h_2_bi does.

I think the feature I'd like to see added that has to do with lengthy paramlists (breaking them up as they get too long) or other code beautyfying (or uglification?) features should be done by a code beautfier, not h_2_bi.

Translating h2bi is hard enough as it is without having to take care of source layout.

I have decided to write a GUI frontend for h_2_bi as it's something that can be developed independent of h_2_bi.

[TJF]

I use the offical ISO C99 definition as a C reference. You can get the document here

http://www.open-std.org/JTC1/SC22/wg14/ ... /n1124.pdf

Thank you for the link. I think I will not read it completly (550 pages).

I'll wait until the release.

From my point of view it is best that you make a final test before I upload it. So we can avoid the effects of my organizational blindness. Shall we set a deadline, e.g. the next weekend?

In the meantime I'm going to be translating header files to see if some bugs turn up.

And I've found a 'bug'.

C

Code: Select all

struct USet;

Good job! I fixed it. Version 0.2 will generate

Code: Select all

TYPE USet As Any

I think only emtpy 'struct' can occur?! I mean the following C code will not occur?

Code: Select all

enum USet;

union USet;

I think the feature I'd like to see added that has to do with lengthy paramlists (breaking them up as they get too long) or other code beautyfying (or uglification?) features should be done by a code beautfier, not h_2_bi.

I'll make some tests now. Anyway, I'll implement switches, so a code beautyfier can run later on.

I have decided to write a GUI frontend for h_2_bi as it's something that can be developed independent of h_2_bi.

Sounds good! I'll take care, that further versions of h_2_bi can be controled by a GUI frontend.

What kind of GUI do you have in mind (cross platform: wxWidgets, GTK+)?

[TJF]

I think the feature I'd like to see added that has to do with lengthy paramlists (breaking them up as they get too long) or other code beautyfying (or uglification?) features should be done by a code beautfier, not h_2_bi.

I'll make some tests now. Anyway, I'll implement switches, so a code beautyfier can run later on.

I implemented some switches. Standard code is (no line wrapping - fast):

Code: Select all

DECLARE FUNCTION gtk_ctree_insert_node CDECL(BYVAL AS GtkCTree PTR, BYVAL AS GtkCTreeNode PTR, BYVAL AS GtkCTreeNode PTR, BYVAL AS gchar PTR, BYVAL AS guint8, BYVAL AS GdkPixmap PTR, BYVAL AS GdkBitmap PTR, BYVAL AS GdkPixmap PTR, BYVAL AS GdkBitmap PTR, BYVAL AS gboolean, BYVAL AS gboolean) AS GtkCTreeNode PTR
DECLARE FUNCTION g_input_stream_get_type CDECL() AS GType
DECLARE FUNCTION g_input_stream_read_all CDECL(BYVAL AS GInputStream PTR, BYVAL AS ANY PTR, BYVAL AS gsize, BYVAL AS CONST gsize PTR, BYVAL AS GCancellable PTR, BYVAL AS GError PTR PTR) AS gboolean

using '-n' (= NAMES) and '-w' (=WRAP parameter lists) h_2_bi generates code like

Code: Select all

DECLARE FUNCTION gtk_ctree_insert_node CDECL( _
	BYVAL ctree AS GtkCTree PTR, _
	BYVAL parent AS GtkCTreeNode PTR, _
	BYVAL sibling AS GtkCTreeNode PTR, _
	BYVAL text AS gchar PTR, _
	BYVAL spacing AS guint8, _
	BYVAL pixmap_closed AS GdkPixmap PTR, _
	BYVAL mask_closed AS GdkBitmap PTR, _
	BYVAL pixmap_opened AS GdkPixmap PTR, _
	BYVAL mask_opened AS GdkBitmap PTR, _
	BYVAL is_leaf AS gboolean, _
	BYVAL expanded AS gboolean) AS GtkCTreeNode PTR
DECLARE FUNCTION g_input_stream_get_type CDECL() AS GType
DECLARE FUNCTION g_input_stream_read_all CDECL( _
	BYVAL stream AS GInputStream PTR, _
	BYVAL buffer AS ANY PTR, _
	BYVAL count AS gsize, _
	BYVAL bytes_read AS CONST gsize PTR, _
	BYVAL cancellable AS GCancellable PTR, _
	BYVAL error AS GError PTR PTR) AS gboolean

For standard indents now I use a tabulator. The parameter '-s' switches to space indents, e. g. '-s2' will use two spaces for indents. ('-s' or '-s0' = no indents at all.)

With regard to beautyfying is there anything else you'd like?

[AGS]

From my point of view it is best that you make a final test before I upload it. So we can avoid the effects of my organizational blindness. Shall we set a deadline, e.g. the next weekend?

Mail the code to <address removed>

In the meantime I'm going to be translating header files to see if some bugs turn up.

And I've found a 'bug'.

C

Code: Select all

struct USet;

Good job! I fixed it. Version 0.2 will generate

Code: Select all

TYPE USet As Any

I think only emtpy 'struct' can occur?! I mean the following C code will not occur?

Code: Select all

enum USet;
union USet;

According to the C standard both are legal constructs.

In practice I mostly come across the struct IDENTIFIER; construct.

But union USet; and enum USet; are perfectly legal C constructs as well.

Check out http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

for a C syntax specification (it's just one, not too long, page).

I have decided to write a GUI frontend for h_2_bi as it's something that can be developed independent of h_2_bi.

Sounds good! I'll take care, that further versions of h_2_bi can be controled by a GUI frontend.

What kind of GUI do you have in mind (cross platform: wxWidgets, GTK+)?

Cross platform using IUP. It uses GTK+ on Linux and native controls on Windows.

Edit 25-04-2010: removed email address