FreeTDS Development Group

["Dann Corbit" <DCorbit AT connx.com>]

[snip]
I said:
> > There are no guarantees on the addresses alignments that clients
want to
> > bind to.
> >
> > Consider:
> > The client creates a memory buffer with the following properties:
> > For every field there is a leading character which will be 1 if the
> > field is null and zero if the field is not null.  Every field will
also
> > be stored in the memory buffer using its exact width.  Now, suppose
that
> > the first field in the result set is a single character.  Then the
next
> > field will start at offset 3.  For many CPUs, this will cause a bus
> > error if the succeeding data is simply assigned to a pointer that
wants
> > alignment to a type and the type does not support character
alignment.
> >
> > The reason that we made the changes above is that we *were* getting
bus
> > errors in running some of our regression tests on some platforms.
> >
> 
> Mmmm... from msdn (linked from SQLBindCol reference)
> 
> http://msdn2.microsoft.com/en-us/library/ms709306(VS.85).aspx
> 
> So data should be aligned by program. It's also true that we don't
live
> in a perfect world so if you tested that others drivers works in all
> cases it's worth to write such a workaround. Personally I currently
> don't have a test environment like this.

You're quite right.  The specification clearly says that the data should
be properly aligned.  I guess we just altered our source to placate the
customers, and added the problem generator to our regression tests.

I think we will probably just maintain our own version of this file.
Even though the FreeTDS clearly does the right thing, I think it will be
cheaper for us than fielding technical support calls.  So I do repent
and retract in dust and ashes.
;-)