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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,60e2922351e0e780 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-21 20:20:32 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3FBEE403.623B5387@nospam.cogeco.ca> From: Warren Gay Reply-To: warren@cogeco.ca X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Re-Marketing Ada (was "With and use") References: <3FB0B57D.6070906@noplace.com> <3FB22125.1040807@noplace.com> <3FB3751D.5090809@noplace.com> <3FB8B9BC.5040505@noplace.com> <3FBA1118.4060105@noplace.com> <0fxub.48425$bQ3.12107@nwrdny03.gnilink.net> <3FBB6527.4040702@noplace.com> <3FBCBA38.8040000@noplace.com> <067vb.13803$iT4.1718658@news20.bellglobal.com> <3FBE0ABA.4090801@noplace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 21 Nov 2003 23:20:19 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1069475220 24.150.168.167 (Fri, 21 Nov 2003 23:27:00 EST) NNTP-Posting-Date: Fri, 21 Nov 2003 23:27:00 EST Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:2837 Date: 2003-11-21T23:20:19-05:00 List-Id: "Chad R. Meiners" wrote: > "Warren W. Gay VE3WWG" wrote in message > news:PPrvb.1623$NB4.26040@news20.bellglobal.com... > > > The one problem that I constantly have to hand craft a solution > > to is the interfacing with C components on different platforms. > > A value in a C header file for FreeBSD may or may not be the > > same as the same on a Linux host. That same value (or type > > size) may differ again on a Linux/Alpha host for another. > > Instead of a hint file, perhaps a better reproach would be a to have an api > specification which declares the types and subroutines that you want to > appear in the thin binding, and where in the C header file to get there > definition? This way you can guarantee the resulting thin binding will have > a consistent interface despite the changing representations. OK, I think were on similar wavelengths here. So instead of using a hints file, specify what you hope to get out of the header file. Well, I suppose this works very well for the API functions, structures, types etc. One area where this falls down perhaps is for macro constants (imagine trying to specify all the error code constants from something like errno.h). But I suppose you could do the following: - Choose all or nothing folded macro constant definitions - Choose all including or all except according to a set of regular expressions matching the macro name. For example, you could specify: Defines include "HAVE_.*" to grab those macros out of the MySQL my_config.h file. Actually, the more I think about your idea, the more I like it. It has the additional advantage that you only expose yourself to areas that are important to your application. IOW, there is a much greater chance of success on all platforms, if you stick to only what you need, rather than everything and the kitchen sink. I like that idea. Maybe you should be writing this tool? ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg [Remove the nospam from the email address: blame the worms]