WORDS_BIGENDIAN (was RE: [freetds] Running FreeTDS under VMS)

Craig A. Berry craigberry at mac.com
Sun May 4 23:51:27 EDT 2003


At 3:49 PM -0400 5/4/03, James K. Lowden wrote:
>On Sat, 3 May 2003 17:51:47 -0500, "Craig A. Berry" <craigberry at mac.com>
>wrote:
>> At 3:03 PM -0400 5/1/03, Lowden, James K wrote:
>>
>> > >   what is the purpose of emul_little_endian ?
>> >>   That should be only applicable to the client side, shouldn't?
>> >>   Anyway, I had to leave it to 0 with this kind of code:
>> >>
>> >> #ifdef WORDS_BIGENDIAN
>> >>         if (IS_TDS7_PLUS(tds)) {
>> >> #ifndef VMS
> > >>                 /* TDS 7/8 only supports little endian */
>> >>                 tds->emul_little_endian = 1;
>> >> #endif
>> >>         }
>> >> #endif
>> >
>> >See how WORDS_BIGENDIAN is defined and make sure it's 0 for VMS.  On
>> >unixy systems, the configure script sets it based on system
>> >interrogation.  It would be well to note this in the VMS readme.
>>
>> WORDS_BIGENDIAN is currently hard-wired to undef on VMS in our config.h,
>> so it's hard to see how the code above could have been visible to the
>> compiler unless there is some other place it gets defined when found
>> undefined.  Grepping the sources shows that in many cases #ifdef and
>> #ifndef are used to check this macro, but in other cases #if is used.
>> #If we define it to 0, obviously only the latter cases will work as
>> #expected.
>
>Umph, obviously. 
>
>I don't see how or why WORDS_BIGENDIAN would become defined outside
>config.h. 

Me either.  I'm beginning to wonder whether the original poster created his configuration via

$ @[.vms]configure.com

or cooked it up some other way, perhaps by using the standard configuration script on another platform and moving the files across.  I've proven to my own satisfaction that the code quoted will never be visible when configure.com is used to create config.h.

>I wouldn't want logic such as the above to become part of the
>FreeTDS source code, though, because it's patently silly

I agree.

>(afaik, there's
>no big endian VMS platform). 

Itanium purportedly has a feature to switch endianness on the fly, but any program that does that is no longer running on the host OS in the usual sense -- I think it's primarily there for emulators and such.  And certainly OT for our purposes.

>Your message did lead to small insight for me.  Oftentimes, #if and #ifdef
>are functionally the same, and there's a mixture of usages in the FreeTDS
>code.  We should rely on #if[n]def only to see if something is or needs to
>be defined.  That is, #ifdef ... #endif should surround only preprocessor
>logic, and #if ... #endif should surround C code. 

That sounds like a reasonable convention.

>
>GNU[1] prefers "if" to "#if".  I don't know if that's really good practice
>or not, but I agree that preprocessor code tends to obscure rather than
>reveal. 


I sympathize since I frequently get lost in #ifdef jungles.  However, something strikes me as a bit wacky about depending on the compiler's optimizer to do what the pre-compiler has traditionally done.
-- 
________________________________________
Craig A. Berry
mailto:craigberry at mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser



More information about the FreeTDS mailing list