From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,874959b8413ac400 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-20 09:58:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-was.dfn.de!news-koe1.dfn.de!news-han1.dfn.de!news.fh-hannover.de!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Book to learn GtkAda Date: Sat, 20 Oct 2001 19:03:21 +0200 Organization: Enyo's not your organization Message-ID: <87d73iutuu.fsf@deneb.enyo.de> References: <9qn2t5$7pu1@news.cis.okstate.edu> <9qnc4s$gl7$1@drcomp.erfurt.thur.de> <9qpc58$8a21@news.cis.okstate.edu> <9qpsh8$lf5$2@drcomp.erfurt.thur.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: archiver1.google.com comp.lang.ada:14970 Date: 2001-10-20T19:03:21+02:00 List-Id: Adrian Knoth 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.