Skip to Content.
Sympa Menu

freetds - About patch #580072 (Rewritten string_to_numeric)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS <freetds AT franklin.oit.unc.edu>
  • Subject: About patch #580072 (Rewritten string_to_numeric)
  • Date: 15 Aug 2002 07:53:46 +0200


Altough this new function work very better (faster and with less bugs)
it raise some problem (some are present also before this patch)
1- g__numeric_bytes_per_prec
2- sybase and mssql wire representation

1- this variable is static and global. This give a problem:
we cannot access mssql and sybase from the same process (like from a
web server, a complex example with many connection from a single
process)
Also this variable is initialize in connect method (were we know what
sql server we use). But this raise some problem
- user program can just use ctlib, create a context and call
cs_convert. At this point our library access g__numeric_bytes_per_prec
(not initialized) and use it as index to a array.. core dump and other
waiting. A solution to this should initialize at compile time array but
doing so cs_convert can work differently after connection.

2- Sybase and mssql seem to represent numeric on wire differently (mssql
is always little endian, sybase is big endian using lower array position
possible)
Time ago I posted a solution to this problems (I think It was lose in
the ocean of other mails). My solution is to define a library platform
representation for numeric (fixing byte ordering and alignment for big
and little endian machines) and translate suddenly to this
representation (in token.c as we made for int and other types).
Also how user program expect data to be represented?
>From MS docs on ODBC seem always little-endian but MS docs are many time
x86 specific...

Before calling string_to_numeric (from CVS code) we initialize numeric
with (18,0). Is not possible that a library require different numeric
scale and precision values?

This patch use always a little-endian coding (but is simple to change to
previous method) and I commented out numeric precision/scale
initialization.

freddy77





  • About patch #580072 (Rewritten string_to_numeric), Frediano Ziglio, 08/15/2002

Archive powered by MHonArc 2.6.24.

Top of Page