Skip to Content.
Sympa Menu

freetds - Re: Help Freetds 0.53 - removing messages printed to- STDERR

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Michael Horowitz" <michael.horowitz AT storagenetworks.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: Help Freetds 0.53 - removing messages printed to- STDERR
  • Date: Fri, 4 Jan 2002 15:43:42 -0500


Hey Mark,

I was wondering if you looked into any of this stuff in my last email?

Seems to me if the server is supposed to do the swapping if the client
reports it is big endian(emulate little endian turned off), then the
client shouldn't do any swapping at all. If a big endian machine emulates
little endian, then the client has to do the swapping.
If that is not the case and I am wrong, then at the least that second swap
of the message number should have "if (!tds->emul_little_endian)" around
it so it doesn't undo the previous swap in the tds_get_int function.

Sorry I keep bugging you on this, I am not trying to argue with you, I
just really want to know what is correct. I am not familiar with the code
and have only read parts of it, so I am counting on you to verify all this
for me.

Thanks,

Mike

> If that is a case then my fix would cause a problem. I am not really
> familiar with the TDS protocol. I thought big endian was sort of the
> standard for network protocol stuff?
> I did a few greps through the code and it seemed that in all other
> instances, the only place any of the swap functions were called were
> wrapped in an "if (tds->emul_little_endian)" statement, so I figured that
> emul_little_endian was set whenever big endian was needed emulating or
> not, and that the config value in freetds.conf just forced it to be true.
> I also thought I read in a few places when trying to trace down the byte
> order swap issue with the datetime fields with an older version of the
> libraries that the server was supposed to send in big endian if the client
> reported it was big endian and vice versa. I know that Microsoft probably
> didn't let big endian support slide accidentally ;).
> Oh, while I am at it, I tried to use the "swap broken dates" config option
> at first to fix the byte order issue with the datetime fields, but it
> didn't seem to affect the datetime fields at all. It wasn't until I used
> "emulate little endian" that it fixed the problem, and the "swap broken
> dates" option didn't seem to do anything then either. Does that only work
> under certain conditions? I was using it with MSSQL 7.0 with SP2, which I
> believe had the problem.
>
> Let me know what the final resolution of the swapping issue is.
>
> Thanks,
>
> Mike
>
>
> > At 9:01 PM -0500 1/2/02, Michael Horowitz wrote:
> > >Hello again,
> > >
> > >I am not really familiar with the code, but I used some the hints you
> > >gave
> > >me and took a quick look through the code. I think I have spotted the
> > >problem.
> >
> >
> > But the bytes are only swapped in tds_get_int if emulating little
> > endian, but they need to be swapped in this case for bigendian
> > systems not emulating little endian -- that's why I put that swap
> > there. I've never tried emulating little endian, so I never saw the
> > problem there.
> >
> > I'll test the code and check the mod into cvs.
> >
> > --
> > __________________________________________________________________________
> > "They that can give up essential
> > liberty
> > Mark J. Lilback to obtain a little temporary safety
> > <mark AT lilback.com> deserve neither liberty or safety."
> > http://www.lilback.com/ -- Benjamin Franklin




Archive powered by MHonArc 2.6.24.

Top of Page