Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS dbwillconvert discrepancy

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Joe Losco <joe AT sqpuv.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS dbwillconvert discrepancy
  • Date: Sun, 30 Nov 2008 11:37:27 -0500


James K. Lowden wrote:

My first instinct was to wonder if in fact you're linking to FreeTDS and
not one of the vendor libraries, or perhaps to a version prior to 0.82. I
assume none of those is the case.
My second guess is to wonder if Objective C is looking at the header file
(or something like that), interpreting each nonzero return code as "true",
and returning only 0 or 1. Is there glue code that allows Objective C to
call a C library? Is there some preprocessing that gets done to make C
functions available to it?
If so, the solution might be to define the function as returning DBINT
instead of DBBOOL. Or something like that.

I have thought about this a little more and have thought of something I had "fixed" for Obj-C that I thought was irrelevant, however now with the information about the results that dbwillconvert is returning and the possible issue of the bool, it may not be so irrelevant. When I first compiled the sample program in Obj-C, I had a conflicting declaration of Bool. One was in the FreeTDS header and the other was in the main objective-c header file. I had added a directive to not declare the bool in the FreeTDS header like the other ones were already there to avoid redeclaring it. What I added in the FreeTDS header was to the end of the !defined parts for the bool was as follows. This allowed the program to compile without any errors.

&& !defined(OBJC_BOOL_DEFINED)


But what made me think of it now, is that objc.h declared the bool differently than FreeTDS. This to me is most likely the issue in Obj-C with dbwillconvert.

FreeTDS defines the bool as typedef int BOOL;
objc.h defines the bool as typedef signed char BOOL;
I'm not really sure why, but it has this comment
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C"
// even if -funsigned-char is used.

They also later define YES = a Bool of 1 and NO = bool of 0. I'm not sure why or what implications this has other than when a type is expected to be one thing and its another, there are obvious issues when data is retrived from memory.

Thanks again for any feedback.
Joe





Archive powered by MHonArc 2.6.24.

Top of Page