Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#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)

mapsde-utf16le.patch (539 bytes ) - added by russellmcormond 15 years ago.
Simple patch to use UTF-16LE rather than UTF-16

Download all attachments as: .zip

Change History (7)

by russellmcormond, 15 years ago

Attachment: mapsde-utf16le.patch added

Simple patch to use UTF-16LE rather than UTF-16

comment:1 by russellmcormond, 15 years ago

Component: MapServer C LibraryInput - Native SDE Support
Owner: changed from sdlime to hobu
Version: unspecified5.2

comment:2 by hobu, 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:3 by hobu, 15 years ago

And the backwards logic in r8503 :)

comment:4 by russellmcormond, 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 hobu, 15 years ago

Milestone: 5.2.2 release
Resolution: fixed
Status: newclosed

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 russellmcormond, 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?

Note: See TracTickets for help on using tickets.