[fpc-pascal] H2pas tool vs others, C header translation

[n***@z505.com]

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-

[Graeme Geldenhuys]

Post by n***@z505.com
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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailm

[Michael Van Canneyt]

Post by n***@z505.com
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.

Post by n***@z505.com
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?

Yes.

Post by n***@z505.com
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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca

[Marco van de Voort]

Post by Michael Van Canneyt

Post by n***@z505.com
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.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinf

[n***@z505.com]

Post by Marco van de Voort

Post by Michael Van Canneyt

Post by n***@z505.com
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.

Before everything I do a couple of substs with an editor,

What do you mean by substs..

Search/replace, (substitutions? regex?)

Post by Marco van de Voort
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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[Dmitry Boyarintsev]

Post by n***@z505.com
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.

Post by n***@z505.com
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.

[Dmitry Boyarintsev]

Post by n***@z505.com
Is there a competing tool that does more, or is updated more?

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

[n***@z505.com]

Post by Dmitry Boyarintsev

Post by n***@z505.com
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?
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://list

[Marco van de Voort]

Post by Dmitry Boyarintsev
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.

Note that to convert C (as in source code, not headers), I did use other
tools in the past. Can't remember which though.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[n***@z505.com]

Post by Marco van de Voort

Post by Dmitry Boyarintsev
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.

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

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://

[LacaK]

Post by Marco van de Voort

Post by Dmitry Boyarintsev
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.

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

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.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepasc

[Martok]

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.

--
Martok

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis

[Florian Klämpfl]

Post by Martok
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.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepasc

[Dmitry Boyarintsev]

Post by Marco van de Voort

Post by Martok
As a heads-up: whatever tool you end up using, make sure you do NOT

translate

Post by Martok
the C enums in mpfr.h as enumerations. It will work, but create

unpredictable

Post by Martok
codegen on the FPC side.

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.

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 C<>Pascal).

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

[Martok]

Post by Florian Klämpfl
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.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f

[n***@z505.com]

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 ;)

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.

[Sven Barth via fpc-pascal]

Post by n***@z505.com
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).

Post by n***@z505.com
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 ;)
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

[Michael Van Canneyt]

Post by n***@z505.com

Post by n***@z505.com
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).

Post by n***@z505.com
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 ;)
In FPC you can use the types Boolean16, Boolean32 and Boolean64 to get a
type that behaves like Boolean, but has a different size.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/li

[Sven Barth via fpc-pascal]

Post by Michael Van Canneyt

Post by n***@z505.com

Post by n***@z505.com
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).

Post by n***@z505.com
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 ;)
In FPC you can use the types Boolean16, Boolean32 and Boolean64 to get a
type that behaves like Boolean, but has a different size.

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;
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).

Post by Michael Van Canneyt
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

[Michael Van Canneyt]

Post by Michael Van Canneyt

Post by Michael Van Canneyt
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;
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).

Post by Michael Van Canneyt
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.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/

[Sven Barth via fpc-pascal]

Post by Michael Van Canneyt

Post by Michael Van Canneyt

Post by Michael Van Canneyt
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;
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).

Post by Michael Van Canneyt
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.

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.
"In both forms, the first substatement is executed if the expression
compares unequal to 0."
Treat it as such.

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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/li

[Michael Van Canneyt]

Post by Sven Barth via fpc-pascal

Post by Michael Van Canneyt
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.
"In both forms, the first substatement is executed if the expression
compares unequal to 0."
Treat it as such.

And I say that the programmer does not need to care about it if the one
that translated the interface used the correct type.

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

Post by Sven Barth via fpc-pascal
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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.f

[Sven Barth via fpc-pascal]

Post by Michael Van Canneyt

Post by Sven Barth via fpc-pascal

Post by Michael Van Canneyt
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.
"In both forms, the first substatement is executed if the expression
compares unequal to 0."
Treat it as such.

And I say that the programmer does not need to care about it if the one
that translated the interface used the correct type.

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

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists

[n***@z505.com]

Post by Michael Van Canneyt
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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp

[Dmitry Boyarintsev]

Post by n***@z505.com
Why borland chose the bool to not be 100 percent compatible, and only 50
percent compatible?
true = -1
true = ($FFFFFFFF) 1
Why not just make it exactly compatible, there must be some underlying
(possibly obnoxious) reason for this mess.

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

thanks,
Dmitry

[n***@z505.com]

Post by Dmitry Boyarintsev

Post by n***@z505.com
Why borland chose the bool to not be 100 percent compatible, and
only 50 percent compatible?
true = -1
true = ($FFFFFFFF) 1
Why not just make it exactly compatible, there must be some
underlying (possibly obnoxious) reason for this mess.

true = (not false);

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.free

[Dmitry Boyarintsev]

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)

Post by n***@z505.com
Why borland chose the bool to not be 100 percent compatible, and

Post by n***@z505.com
only 50 percent compatible?
true = -1
true = ($FFFFFFFF) 1
Why not just make it exactly compatible, there must be some
underlying (possibly obnoxious) reason for this mess.

true = (not false);

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.
_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[Paulo Costa]

Post by Dmitry Boyarintsev
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.
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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://li

[n***@z505.com]

Post by Paulo Costa

Post by Dmitry Boyarintsev
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.
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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freep

[el es]

Post by Paulo Costa

Post by Dmitry Boyarintsev
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.
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

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.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[Marco van de Voort]

Post by n***@z505.com
But it gets worse than that: even fpc/delphi's bool is not always
compatible (but is sometimes).
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 ;)

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)

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-

[n***@z505.com]

Post by Marco van de Voort

Post by n***@z505.com
But it gets worse than that: even fpc/delphi's bool is not always
compatible (but is sometimes).
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 ;)

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)

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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.f

[Sven Barth via fpc-pascal]

Post by Marco van de Voort
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

[Marco van de Voort]

Post by Michael Van Canneyt
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?

Post by Michael Van Canneyt
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

Post by Michael Van Canneyt
"In both forms, the first substatement is executed if the expression
compares unequal to 0."
Treat it as such.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.free

[n***@z505.com]

Post by Marco van de Voort

Post by Michael Van Canneyt
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?

Post by Michael Van Canneyt
Attempting to cater for C code using BOOL or whatever type is
misplaced.
C does not have a boolean type.

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

Post by Michael Van Canneyt
"In both forms, the first substatement is executed if the expression
compares unequal to 0."
Treat it as such.

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.

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
.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma

[Marco van de Voort]

Post by n***@z505.com

Post by Marco van de Voort
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.

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

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.free

[Marco van de Voort]

Post by n***@z505.com

Post by Marco van de Voort
rarer
cases)

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

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.

Post by n***@z505.com
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 ?

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca

[n***@z505.com]

Post by Marco van de Voort

Post by n***@z505.com

Post by Marco van de Voort
rarer
cases)

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

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.

Post by n***@z505.com
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 ?

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 ;-(
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.

[Marco van de Voort]

Post by Sven Barth via fpc-pascal

Post by Marco van de Voort
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 ;)

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.


_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://list

[Sven Barth via fpc-pascal]

Post by Marco van de Voort

Post by Sven Barth via fpc-pascal

Post by Marco van de Voort
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 ;)

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

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

Post by Marco van de Voort
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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m