WORDS_BIGENDIAN (was RE: [freetds] Running FreeTDS under VMS)

ZIGLIO Frediano Frediano.Ziglio at vodafoneomnitel.it
Mon May 5 08:26:45 EDT 2003

> On Mon, 5 May 2003 13:49:07 +0200, "Bernard Giroud"
> <bernard.giroud at creditlyonnais.ch> wrote:
> > But one of this change is the hardcoding of UCS-2LE in 
> tds_iconv_open.
> > VMS only knows UCS-2. So iconv_open doesn't work, and because
> > initialization is not aborted, it keeps sending something the server
> > doesn't understand.
> I would never have predicted that one of the first "victims" of iconv
> would be a fellow in Switzerland using VMS.  :-)
> The way I suggest we fix this:
> 1.  Patch sybase_character_sets.h such that tds_canonical_charset_name
> returns "UCS-2" when passed "UCS-2LE", when compiled for VMS.  

This problem is common to many iconv version. ie HP/UX do not have UCS-2LE name.
My intention is:
1- check if we have GNU iconv
2- check names using configure (source use encoded ISO-8859-1, UCS-2LE, UTF-8 and UCS-4, for the moment)

Some platform do not have UCS-4 or UCS-2LE (HP/UX 10.20 have ucs2 but is only big endian)

> 2.  Replace hard-coded entry with 
> 'tds_canonical_charset_name("UCS-2LE")'.

This raise another problem. What's the "canonical charset" definition? Is the name to use for iconv functions? It's the more standard name?
Calling tds_canonical_charset_name("UCS-2LE") in some place reduce performance... My intention is to define source coded in config.h (TDS_CHARSET_UCS4, HAVE_CHARSET_UCS4 and similar).

> I think that will do the trick.  Naturally I'm open to suggestions.  

I'm doing some brute force tests with charset to detect ascii compatibility and others things...


More information about the FreeTDS mailing list