FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Tue, 9 Jul 2002, Lowden, James K wrote:

> Eric, 
> 
> Your remarks are on the money.  Please ignore my last message.  I now like
> your "radical" solution best, because it's both simple and funny.  
> 
> I should have looked at cs.c, at cs_convert().  I was fixing dblib in
> tdslib, with the consequence of breaking ctlib.  The weird termination
> behavior described in the dblib docs shouldn't be embedded in a shared
> library.  dbconvert() is what needs attention.  
> 
> Brian, I'd like to suggest a policy about conversions for the project; if
> you like it then it should be explicitly noted somewhere.  
> 
> <policy>
> tds_convert copies from src to dest and returns the output data length,
> period.  All padding and termination is the responsibilty of the API library
> and is done post conversion.  There may be some shared utility padding &
> termination functions, but they're really not "conversion".  Trying to do
> anything nonstraightforward in tds_convert will only confuse and confound
> the higher levels, us among them.  
> </policy>

I think that dblib was cleaning up before, the difference being we had 
tds_convert always null terminating.  I like yours better.
 
> An alternative would be to pass the padding & termination policy argument as
> an enumerated type, which tds_convert would carry out if the basic
> conversion succeeds.  

I'm not sure tds has all the info it needs to do this always...for 
instance padding, how big is the column? and remember that dbconvert can 
be called without a dbproc...better to leave the fixups to the API layer.

> 
> You have more experience with this (obviously), and have some idea where
> UTF-8 is taking us, so I'm curious how you see things.  

UTF-8 touches more on the dbdatlen() type functions, once you call 
*convert() with sizes it's all over but the crying.

> --jkl
> 

Brian