Re: [Hamlib-developer] Kylix binding for Hamlib

[Stephane F. <f4...@fr...>]

Quoting Francois Retief <fgr...@su...>:

> I committed a binding for Borland's Kylix to the CVS.

Great! I used to be a Turbo Pascal fan, from the 4.0 version and onwards.
That's fun to see this clear language still alive.

> Included in the tests/ directory is a small demo/test program.
> It can select a rigs and open a very primative frequency display
> dialog box.  Will improve later..

Sorry, I won't be able to give it a try real soon, cause I don't
have Kylix installed yet. Somehow, I have not seen any Makefile.am
in your commit. Do you think it's too early to put it into dist?
Since there's no support in automake for .pas sources, you'll have 
to specify the build process in the Makefile.am, unless this is all 
handled by Kylix itself.

> One problem I found while testing the binding was that there is no
> way to verify that a non-null rig pointer is pointing to a valid 
> rig structure.  During testing I solved this by adding a magic 
> numbers to the rig structure.

You're right. Hamlib is not checking for non-null rig pointers.
But this is a tread-of. It depends how deep we trust the programmer
using the library. Hamlib can very well not check for any error at all.
However, we implicitly decided to test for initialization errors
caused by null pointers, catching most probable bug.
IMHO, verifying non-null rig pointer is a little bit paranoic,
were are not in the Linux kernel.
Anyway, it's fast, it's the C language. Adding code to check everything
with C would advocate for rewritting Hamlib in Java.
But we like to live dangerously, and avoid breeding bugs in our code :)

Hamlib only means to check for this:

        my_rig = rig_init(RIG_MODEL_DUMMY);
            /* imagine malloc failed, my_rig==NULL */

        rig_open(my_rig);  /* seg fault... */

..and not for random memory corruption within the RIG opaque structure.
If the user program messes to much with it, it'll get what ít's looking for.

Now, thinking of it twice (sorry folks, I sometimes happen to not think twice 
when I write code :), Hamlib is not checking the right thing.
It should check for rig_state.comm_state, preventing for example an app
from doing rig_set_freq() on a rig handle that was not rig_open'ed.
What do you all think? 


Btw Francois, you told me earlier you have a patch for the easycomm rotator.
Is it spinning already? Do you have any plan to commit it before 1.1.3?
I was thinking also that the rotator API lacks some capabilities, 
like the angular speed of the rotator (what units are best?),
and also a call like rot_get_destination, useful when the rotator
is still on its way.


Cheers,

Stephane