Skip to Content.
Sympa Menu

freetds - Re: TDS_END3_TOKEN on Solaris(sparc)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: TDS_END3_TOKEN on Solaris(sparc)
  • Date: Mon, 8 Feb 1999 18:19:46 -0500 (EST)




On Mon, 8 Feb 1999, Gregg Jensen wrote:

> OK,
> Maybe, this will be the last time about this particular item. The problem
> turns out to be on the caluclation of more_results when the marker is
> TDS_END3_TOKEN. The output of the get_incoming function gave
> me the thought that maybe the byte that it was looking for was reversed
> (endianness stuff). Well it looks like that may be the case. At least,it
> fixed the two queries I was having problems with (and the other queries
> run too). The sp_help tablename dumped core in sqsh, but I think it was
> due to a different problem (float conversion, which still may be an
> endianness problem).
>
>
> This is what I did in tds_process_end:
>
> unsigned char tmp = tds_get_byte(tds);
>
> #if defined(HW_BIG_ENDIAN)
> tmp = tds_get_byte(tds);
> *more_results = (tmp & 0x1) != 0;
> tds_unget_byte(tds);
> #else
> *more_results = (tmp & 0x1) != 0;
> #endif
>
> instead of just:
>
> *more_results = (tmp & 0x1) != 0;
>
this sounds like it is a 16bit field, maybe better to call
tds_get_smallint() on it and let that deal with it. Then just shorten the
subsequent call to tds_get_n from 7 to 6 bytes.

> There are two places where this exists, the one mentioned above and
> in tds_process_default_tokens (look for '& 0x1'). This is a first cut
> so please take pot shots at this to make it more production worthy.
>
> Gregg
>

Brian






Archive powered by MHonArc 2.6.24.

Top of Page