Forgive me, I have forgotten, this may have been discussed before..

Is h2pas the latest tool to convert C headers to pas files?

Is there a competing tool that does more, or is updated more?

I remember Bob Swart AFAIR had a popular tool for delphi.

And some people use multiple tools if one tool is giving them issues.

Is h2pas for example the one that is used for Mysql header translations and other major C headers?

I am looking to convert the GNU MPFR library header files, or hire someone on a bounty to do it if header translation is not so easy with h2pas and requires lots of hand work, and close checking.

The issue I see with header translation is there is no way to prove that the header translation is 100 percent correct, as the compiler will not tell you if it found an issue, it will just link the DLL as you stated to link it. Too bad DLL/DSO libraries could not export some sort of correctness or type verification when you link against the library.

Is there a competing tool that does more, or is updated more?

Recently somebody told me about the following project...

https://github.com/DrDiettrich/CtoPas/

It's specific to Delphi I think. I haven't tried it or looked at the code, so can't say how easy or not it will be to port to say FPC.

Regards,
Graeme

Forgive me, I have forgotten, this may have been discussed before.. Is h2pas the latest tool to convert C headers to pas files?

For FPC, yes.

Yes.

I am looking to convert the GNU MPFR library header files, or hire someone on a bounty to do it if header translation is not so easy with h2pas and requires lots of hand work, and close checking.

I do all header translations with h2pas. Most of the time, I run the code first through gcc -E, which will take care of all macro magic. Usually h2pas has little trouble with the result.

Michael.

In our previous episode, Michael Van Canneyt said:

Before everything I do a couple of substs with an editor, then instead of gcc -E I use small pascal filterprograms to sort the symbols based on heuristics. Usually "clean" defines, structs, function calls and "rest".

The clear files I translate by h2pas, the rest manually or with pascal programs, and then I stitch them together again. I try to preserve comments as much as possible.

In the past, with very large headers, I did this restitching semiautomatically, by inserting marker comments while splitting.

I tried all other headerconvertors, and didn't have a better result.

Is h2pas for example the one that is used for Mysql header translations and other major C headers?

I'm using Chelper. (http://wiki.freepascal.org/Chelper) It's my choice, because it preserves comments (which is usually an important part of open-source libs)
plus, can be configured to handle library header-specific defines. Naturally, the process is semi-automatic, but get be done quite quickly.

I am looking to convert the GNU MPFR library header files, or hire someone on a bounty to do it if header translation is not so easy with h2pas and requires lots of hand work, and close checking.

Speaking of bounties.
There was a bounty (http://wiki.freepascal.org/Bounties#Linux_bounties) for converting libwebsockets to fpc.
I took it and did the conversion using Chelper.

Is there a competing tool that does more, or is updated more?

How about this list?
http://wiki.freepascal.org/C_to_Pascal

That's a good one, I missed that.. could not find it previously when searching google

Did you write CHelper because H2pas was not to your satisfaction?

In our previous episode, Dmitry Boyarintsev said:

Note that to convert C (as in source code, not headers), I did use other tools in the past. Can't remember which though.

What do you mean by substs..

Search/replace, (substitutions? regex?)

gcc -E I use small pascal filterprograms to sort the symbols based on heuristics. Usually "clean" defines, structs, function calls and "rest".

A custom filter program for each case by case basis, or one major filter program you wrote for all header files?

Thanks for the tips.

I did mean headers, not C source... But C source is also interesting to convert of course
I wonder if the Quake to Delphi and Doom To Delphi folks wrote tools for conversion, or used existing ones to do the bulk of the work. If superman was involved, they likely did it by hand 100 percent the hard way, but if they are A.I. then they have no hands, likely.

If your header looks enough like IDL (which is essentially C++ with annotations), you may also be able to use one of the available IDL compilers. There are a few dialect issues though, so YMMV. I'd say MPFR has a few defines too many for my idlproc (https://github.com/martok/idlproc), but may come closer for others.

As a heads-up: whatever tool you end up using, make sure you do NOT translate the C enums in mpfr.h as enumerations. It will work, but create unpredictable codegen on the FPC side. Use plain constants.

I have used many times C2Pas32 (for translation C source files not only headers) ... it gives good results for me, but some parts I must edit manually of course ...
-Laco.

It is perfectly predictable. Just do not store invalid values in enumeration variables. And invalid is everything not being declared. This is how FPC works and will work.

It is perfectly predictable. Just do not store invalid values in enumeration variables. And invalid is everything not being declared. This is how FPC works and will work.

Aye. The point being, if the store operation is in a library (a getter, such as mpfr_get_default_rounding_mode), there is just no way of absolutely enforcing that - so the FPC side must be defensive. As you say, enums already contain typing assumptions and are not meant to be defensive, so they can't be used here. That's all I wanted to point out.

Never saw FPC acting unpredictably.
(There was an issue back in the days with Delphi. But it's only because delphi packs enumerations to 1 byte, where FPC packs them to 4 bytes in objfpc mode)

Instead, I saw C-enumarations used as non-Pascal-enumerations. (which is actually expected CPascal).

For instance, it's common for C enumerations to be used used in bitwise operations.
ENUM1 | ENUM2
(but report for sdl2 headers
https://github.com/ev1313/Pascal-SDL-2-Headers/issues/44) not available in Pascal, unless an explicit type casting or sets are used.

So, in the end it's better to declare enumeration type elements as constant and the type itself as an alias to integer (or cint)

thanks,
Dmitry

What about the BOOL issue..

We know that Boolean in fpc/delphi is not compatible with a C bool

But it gets worse than that: even fpc/delphi's bool is not always compatible (but is sometimes).

For example:
http://blog.delphi-jedi.net/2008/09/25/bool-boolean-and-integer/

When one must use Integers to do boolean related programming tasks, it makes me want to quit programming ;)

compatible (but is sometimes).

makes me want to quit programming ;)

In FPC you can use the types Boolean16, Boolean32 and Boolean64 to get a type that behaves like Boolean, but has a different size.

Regards,
Sven

Sorry for being naive. Why not simply use a boolean ?

I thought all this BOOL mess was just meant to be able to interface with C libs slightly easier.

Instead of

If (SomeCfunction()0) then
   DoSomethingStupid;

it allows you to write - in appropriate cases - the following:

if (SomeCfunction()) then
   DoSomethingStupid;

I don't think we should promote BOOL and friends too much. They are a convenience (which IMHO should not have been introduced in the first place).

Promoting them to first-class Pascal citizens is IMHO a bad idea.

Michael.

convenience (which IMHO should not have been introduced in the first place).

Promoting them to first-class Pascal citizens is IMHO a bad idea.

Did you read the article that had been linked? That's an important point that is raised in there.
These types as well as the Byte-, Word-, Long- and QWordBool types are mainly for interfacing with C-based interfaces, either on Windows or *nix and there they should definitely be used so that a Pascal user of them can simply use True and False and does not need to worry about the details (but of course the correct type needs to be used as the article shows).

Regards,
Sven

I did read it.

I think the programmer *must* worry about the details and must definitely NOT use the booleans for anything C related. That was my point.

Attempting to cater for C code using BOOL or whatever type is misplaced. C does not have a boolean type.

The standard says for "if" :

"In both forms, the first substatement is executed if the expression compares unequal to 0."

Treat it as such.

Michael.

And I say that the programmer does not need to care about it if the one that translated the interface used the correct type. Also I very much prefer to use "True" and "False" instead of some "INT_TRUE" or "INT_FALSE", because that would show that FPC is not up to the job to correctly handle this.
Please also note that I'm only talking about cases where there is indeed a definition of a boolean type on the C side of things (e.g. the Windows API with its BOOL as well as TRUE and FALSE definitions and GTK for which the Boolean16, -32 and -64 types were introduced).

Regards,
Sven

And this "if" is the cliff on which the ship crashes and sinks...

Please also note that I'm only talking about cases where there is indeed a definition of a boolean type on the C side of things (e.g. the Windows API with its BOOL as well as TRUE and FALSE definitions and GTK for which the Boolean16, -32 and -64 types were introduced).

I understood it like that.

Michael.

But this "if" is also the case for a bunch of other translation cases. There are for example some WinAPI translations that have a "var" parameter for pointers while they should be by-value parameters cause they can take "Nil". It's always possible for the translator to screw up and one needs to take care by hand that it works correctly...

Regards,
Sven

In our previous episode, said:

The QueryServiceConfig2 is a known exception in WINAPI land that in some cases assumes things about what is TRUE.

The GTK headers also use a 0/1 boolean, and for that the boolean8/16/32 types were created. I couldn't quickly find docs, so I filed a bug for that.

IOW that problem has long resolved, you just need to know what convention the C code uses, and map that then to either boolean32 or longbool (or rarer cases)

In our previous episode, Michael Van Canneyt said:

I think the programmer *must* worry about the details and must definitely NOT use the booleans for anything C related. That was my point.

The interface uses bool, either as param or in a structure. So what can you do?

Attempting to cater for C code using BOOL or whatever type is misplaced. C does not have a boolean type.

Since C99 it has:

https://stackoverflow.com/questions/4767923/c99-boolean-data-type

All true, but futile, since one assumes the C side is not written by whoever wants to interface it. He might not even have source.

And sometimes API don't adhere to above statement, and then having chosen the right boolean type (longbool or boolean<x>) saves a lot of trouble.

Michael Van Canneyt wrote

I thought all this BOOL mess was just meant to be able to interface with C libs slightly easier.

But, why is the BOOL in fpc/delphi not compatible with C BOOL, in that it has different semantics?

One value lines up correct... but not always the other.

Why borland chose the bool to not be 100 percent compatible, and only 50 percent compatible?

Bool in delphi:
true = -1

Bool in C:
true = ($FFFFFFFF) 1

Why not just make it exactly compatible, there must be some underlying (possibly obnoxious) reason for this mess.

Another option is to write BOOLEAN wrappers around the lower level functions that interface in to the DLL
So for example, could even use an INTEGER, as the boolean, as the Jedi fellow sometimes does, then write a wrapper around it that makes use of a proper boolean. All this, though, is a headache and obnoxious, tedious .

That's good news, does Delphi need to add a boolean8/16/32 some day, or already has?

As I often switch between using fpc and delphi all the time, almost 50/50

"Marco van de Voort" wrote

The GTK headers also use a 0/1 boolean, and for that the boolean8/16/32 types were created. I couldn't quickly find docs, so I filed a bug for

that.

Please note that there is no Boolean8 as that one is simply Boolean. But there is also a Boolean64 and QWordBool ;)

Regards,
Sven

They are compatible, if you declare like this:
true = (not false);

thanks,
Dmitry

In our previous episode, said:

I think doing this systematically introduces more mistakes than it solves, since all that manual work also has a risk at errors.

In our previous episode, said:

I don't know. FPC needed it for GTK interfacing, but FPC doesn't use it.

The main headers interfaced by Delphi are WINAPI, and they have longbool.

As I often switch between using fpc and delphi all the time, almost 50/50

More importantly, if you still use ancient D7, would you actually buy a new version (for Eur 1500 or so) if they added it ?

In our previous episode, Sven Barth via fpc-pascal said:

Boolean can be packed in ISO mode, Boolean8 has an explicit size so shouldn't :-)

Seriously, without searching for something pedantic to say, I thought that an alias was added for orthogonality. Maybe it should.

Even the Boolean16/32/64 types are bitpacked down to one bit, so that's definitely no reason :P

Seriously, without searching for something pedantic to say, I thought that an alias was added for orthogonality. Maybe it should.

*shrugs* If you think so...

Regards,
Sven

Depends, AFAIK, if the C library checks for an exact value of 1 somewhere, when Delphi/FPC sends in a -1, this could cause problems, but I haven't thought about it enough.

I just don't see why both languages could not just agree to use "1", they must have had some reason, strange or not.

I use ancient versions (D5 and D7) but also have purchased the latest Tokyo and use latest too..

No I would not buy it just for that, but, I wonder if I should ring them an email on their quality central and feature request it, if they haven't got that figured out yet. This header translation stuff, is still bothering us years later since the 1990's already, and many errors in programs exist because of these damn headers that aren't perfectly translated ;-(

Is 2 neither true, nor false? 3? 4?

If false is zero,
Then true is not false.

Also C doesn't have a boolean type per se. Iirc it was introduced in some version of c++ standard.

In C it's very strange to see code like that:

If (b==1)

It's always
If (b)
Or
If (!b)

Of course, that is because, in C, any value that is not zero, is true.

So you can not compare with 1 or -1 or any other value to test if it is true...

Paulo Costa

There were some very rare edge cases, that occur, though, I have heard, where... this is not the case.

But I would have to take the time to look up the article where I found this...

It could even be a rumor, but I think it is serious..

Since it is an edge case, it creeps in like sh*t when you don't expect it.

Even more 'proliferated' may be usage like

- function returns = 0 on success

- function returns > 0 for a success-with-a-hint or soft-failure (allowing for retry)

- returns negative error code on hard-failure (not-allowing for retry)

-L.