FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> If there is no 64bit integer type on the box we default to 
> whatever "long" 
> is, so there is a potential for buffer overflows where the size of 
> TDS_INT8 is assumed within the code, so I've added a 
> HAVE_INT64 macro such 
> that we can test for that and handle it gracefully 

For consistency, I wish "HAVE_INT64" was "HAVE_INT8".  Would that be OK?
Not to mix bits and bytes.  

> Thinking about it, I 
> maybe should have made the unsupported value "double" so the 
> sizes matched anyway, not sure.

It would be good if the size were consistent, less likely to lead to
segfaults.  

Something like:

#ifdef HAVE_INT8
#       define TDS_INT8 @longlong@ /* or whatever */
#else
        typedef struct _bogus8 { char buf[8]; } bogus8;
#       define TDS_INT8 bogus8;
#endif

That at least would fail to compile if you tried to assign something to/from
a TDS_INT8 variable on a system without a 64-bit int.  Using a double would
be highly misleading, IMHO, and using a straight char array would lead to
occasionally reading its address by mistake.  

If you want to try to support such systems (I think that's misdirected
effort), we'd need a uniform definition of TDS_INT8 that gracefully dealt
with the missing bits.  That would make me want to reach for C++ with its
operator overloading.  

As it so happens, I have a system lacking a 64-bit int.  It might be helpful
in cleaning the code.  

--jkl











The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.