#2878 closed defect (fixed)
endianness setting with NSTRING data from SDE
Reported by: | russellmcormond | Owned by: | hobu |
---|---|---|---|
Priority: | normal | Milestone: | 5.2.2 release |
Component: | Input - Native SDE Support | Version: | 5.2 |
Severity: | normal | Keywords: | |
Cc: |
Description
It turns out that we need to specify the endianness for the NSTRING data (UTF-16 encoded) coming from libsde. The glibc version of the iconv() functions seem to assume little-endian for "UTF-16", while the libiconv version seems to assume network order or big-endian.
If we specify "UTF-16LE", it will always work regardless of which iconv() version we are using.
Attached is a simple patch to mapsde.c , changing 'UTF-16" to "UTF-16LE"
Attachments (1)
Change History (7)
by , 15 years ago
Attachment: | mapsde-utf16le.patch added |
---|
comment:1 by , 15 years ago
Component: | MapServer C Library → Input - Native SDE Support |
---|---|
Owner: | changed from | to
Version: | unspecified → 5.2 |
comment:2 by , 15 years ago
I have attempted to resolve this a little more thoroughly with r8502. Russell, if you could please confirm that it works that would be wonderful. I will backport to the 5.2 branch when I hear back.
Howard
comment:4 by , 15 years ago
I have tested the patches from these changesets in my test environment here.
What I'm wondering is if it is safe to assume that the endianness of the data coming out of libsde will always be the same as the local machine. This may not be something ESRI has clearly defined. Do you have anyone that is running on a non-Intel machine to test? Does ESRI provide ArcSDE for non-Intel machines?
comment:5 by , 15 years ago
Milestone: | → 5.2.2 release |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Oh dear, that would suck. Over the network is big-endian though, so I would presume the SDK has to coerce the data into the endianness of its host.
I can't find anything in the docs that hint as to what might be going on though. As long as this patch works for you now, let's sit on that and if someone else has any more trouble they can reopen the bug. Thanks for all the hard work on this. I'm sure it was a huge pain to track down.
backported to the 5.2 branch in r8504
comment:6 by , 15 years ago
I am curious: If you are making this into something that is fixed based on the platform rather than configurable by the end user in some way, why not make it a macro rather than C code?
Simple patch to use UTF-16LE rather than UTF-16