curses vs non-ASCII

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I'm writing a program with a curses(3) interface, and I'm finding that
non-ASCII octets in strings are getting completely lost somewhere
between the addstr()/printw()/etc argument and the display.  (This is
with 5.2 at the moment, but if someone has answers for other versions,
I'd be interested in those too.)

Looking at addbytes.c and checking with nm, I believe the curses I'm
dealing with was built with HAVE_WCHAR (addbytes.o shows a reference to
mbrtowc) and, thus, it is probably multibyte foo that's causing the
trouble.  Also, libc contains multibyte_amd1.o rather than
multibyte_sb.o.

I have, however, been unable to find any documentation on what I need
to put where in the environment, and/or what API I need to call, to
make this get out of the way and give me the "each octet is one
character" semantic I want for this application.  mbrtowc(3) (as used
by libcurses) says that its behaviour "is affected by the LC_CTYPE
category of the current locale", but I have so far completely failed to
find any documentation on what I need to do to make this work.  nls(7)
seems to imply that setting LC_ALL or LANG might help, but gives only
tiny hints what settings might do what I want.  I tried setting LANG to
en_CA.ISO8859-1 (this guessed based on the da_DK.ISO8859-1 example in
the nls(7) manpage); when that didn't help I instead tried setting
LC_ALL to that same value.  That didn't help either.

If necessary I'll rebuild libcurses with HAVE_WCHAR turned off.  But I
find it hard to believe NetBSD would make it this hard to use
single-byte character sets like ISO 8859-1 or KOI-8, so I am inclined
to assume there's something I'm missing.

Any hints what?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B