Re: Book to learn GtkAda

[Florian Weimer <fw@deneb.enyo.de>]

Adrian Knoth <adi@drcomp.erfurt.thur.de> writes:

> Think of PostgreSQL: there is a thick binding, I need libpq for it,
> but it works very well. Ok, that's what you're saying: it works, use
> it and do something interesting with it.

There are some drawbacks.  For example, notifications are handled in a
way which is not very Ada-friendly, and by writing a binding to libpq,
you can hardly get rid of this.

> OTOH libpq itself could be implemented in Ada. I guess you'll find
> a wrapped socket()-function in it. If there is a better abstraction
> we even can get rid of this by providing a direct kernel-Interface.

That's the way I'm going to implement the next PostgreSQL binding.  (I
think it's the third one.)

> Don't ask me why, but I think this is better. You can use the main
> Ada-features across your libraries, you don't need to convert types
> between C and Ada, get all the checkings and so on.

I agree.  In addition, on GNU/Linux on 32 bit systems, you can avoid
some problems the C API currently has: 16 bit UID/GID types and 32
bit file offsets and inode numbers.  Of course, you can compile your
software with the appropriate flags (at least for the 64 bit file
system interface), but you still don't know if the library you use
works with large files, for example.

Starting mostly from scratch is quite a bit of work. but you can
correct such mistakes (and introduce others).  However, some problems
are very hard to correct, e.g. the interaction of seteuid(), open()
and tasking, or fork(), signals and tasking.