Question
· Oct 15

Why Does $c() Behave Differently on Different Systems?

#Debugging #Platforms #Terminal #InterSystems IRIS

Can someone help me understand what type of user error (?) is going on here please?

One one system, I write out a group of $c() values and get the expected results:

USER>for i=250:1:260 { write i," ", $c(i),! }
250 ú
251 û
252 ü
253 ý
254 þ
255 ÿ
256 Ā
257 ā
258 Ă
259 ă
260 Ą

USER>w $zv
IRIS for Windows (x86-64) 2023.1.4 (Build 580U) Fri Apr 19 2024 11:16:07 EDT
USER>

On another system, I get some unexpected results:

USER>for i=250:1:260 { write i," ",$c(i),! }
250 ú
251 û
252 ü
253 ý
254 þ
255 ÿ
256 Ā
257 Ä
258 Ä‚
259 ă
260 Ä„

USER>w $zv
IRIS for Windows (x86-64) 2025.1.1 (Build 308U) Thu Jul 10 2025 16:00:01 EDT
USER>

We've made a general connection between the good values being generated from IRIS hosted on Linux and the unexpected values being generated on IRIS for Windows, although IRIS on one Windows system generates the expected values (see 2nd run above).

Product version: IRIS 2025.1
$ZV: IRIS for Windows (x86-64) 2025.1.1 (Build 308U) Thu Jul 10 2025 16:00:01 EDT
Discussion (3)2
Log in or sign up to continue
DC AI Bot · Oct 15

The difference in behavior of $C() between the two systems can be explained by the differences in the encoding configurations of the systems. $C() (also known as $CHAR) converts an integer to its corresponding ASCII or Unicode character. However:

  1. $CHAR() behavior and the characters it outputs depend on the context of the character encoding (e.g., whether the device supports UTF-8, ASCII, or another encoding standard). If one system is using a different default encoding (e.g., an environment set for UTF-8 versus a different encoding on another system), the results will vary [1].

  2. The unexpected behavior on the second machine (e.g., ú for 250 instead of ú) can be attributed to interpreting the numeric 250 in one encoding and displaying it as encoded bytes in another. For example, ú in UTF-8 is represented by two bytes, which may be displayed as ú if the output device incorrectly assumes an encoding like ISO-8859-1 instead [2].

To fix this:
- Ensure the character set encoding (e.g., UTF-8) is consistent across both machines.
- Check the National Language Support (NLS) configuration of your IRIS environments or terminal configurations.

This issue is tied to encoding discrepancies rather than a $C() function bug or version difference.

Sources:

0 0
Alexander Pettitt · Oct 15

You are using Unicode. On my 8 bit install it stops after 255.

for i=250:1:260 { write i," ", $c(i),! }
250 ú
251 û
252 ü
253 ý
254 þ
255 ÿ
256
257
258
259
260


8 bit or 16 bit storage option on install - https://docs.intersystems.com/iris20252/csp/docbook/DocBook.UI.Page.cls?...
Different character set for the locale - https://docs.intersystems.com/iris20252/csp/docbook/DocBook.UI.Pag
e.cls?KEY=GORIENT_localization#GORIENT_localization_locales or Configuring National Language Support (NLS)

Could even be different character sets in the terminal settings to the linux servers.

4 0
Jean Millette · Oct 15

Thank you for the links; I'll investigate the differences in NLS/locale settings between the systems.

I'm helping to debug an app that uses $c(254) and $c(255) as line and field terminators for parsing a large ASCII data file. I moved the relevant code and the data file to a system I use for general debugging and was surprised by the different behavior of those $c() calls, hence the question.

I'll post what I needed to reconfigure to get the "debugging" system to work like the original system.

Thanks again.

0 0