Ignore locale for ctype functions isupper() islower() etc in acertain compilation unit

V

Voom

I want to set the locale, and use it in most of my application.
However, in certain legacy compilation units I want the ctype
functions to use the C (ASCII) locale--I want them to be insensitive
to the locale. In particular, I am thinking of the functions:
isalpha()
isalnum()
isgraph()
isupper()
islower()
isspace()

While it is simple enough to write my own version of these functions,
I see in Linux /usr/include/ctype.h the macro __NO_CTYPE. It looks as
if it might do this for me:

// Ignore the locale
#define __NO_CTYPE
#include <ctype.h>
#undef __NO_CTYPE

but that looks very non-portable--I did not even bother trying it.
But it makes me wonder if there is such a thing.

Is there an officially supported macro similar to __NO_CTYPE that
allows me to make some compilation units insensitive to the locale,
while others remain sensitive to the locale?

FYI, I am coding in C++ and compiling with g++, yet posting in
comp.lang.c because these are C functions.
 
S

Seebs

I want to set the locale, and use it in most of my application.
However, in certain legacy compilation units I want the ctype
functions to use the C (ASCII) locale--I want them to be insensitive
to the locale.

I don't think you can. You have a couple of options.

One is to write wrappers which set the locale to the C locale, call
these, and set it back.

Another is to write your own wrappers, and/or just include code from some
open source project to implement your own. Basically, it turns out, you
can implement most of these really easily with a table of the form:

static int ctype_flags_incl_EOF[] = {
[0] = 0, /* flags for EOF */
['a' - 1] = FLAG_LOWER | FLAG_ALPHA,
...
}
static int *ctype_flags = &ctype_flags_incl_EOF[1];


int
myisalpha(int c) {
return ctype_flags;
}

This assumes EOF is -1. There are much, much, better ways to write it,
and of course, you'd probably want to have the table be generated code.

-s
 
B

Ben Bacarisse

Voom said:
I want to set the locale, and use it in most of my application.
However, in certain legacy compilation units I want the ctype
functions to use the C (ASCII) locale--I want them to be insensitive
to the locale. In particular, I am thinking of the functions:
isalpha()
isalnum()
isgraph()
isupper()
islower()
isspace()

While it is simple enough to write my own version of these functions,

I think that is the way to go. Rather then write them "from scratch" so
to speak I'd have a "setup_c_locale_char_tables" function that records
the results of these functions before the locale is set. Your own
versions then use these tables when you need them.

If (as is probable) you can assume that you have only 256 distinct char
values in the C locale you can save the results of these functions in a
small array (256 unsigned chars is enough).

A warning about all table look up methods: beware of signed char systems
and negative char values. If you have

char c;

then you should call

isalpha((unsigned char)c);

but a lot of code does not do this. Most ctype implementations are
written to survive this bug but since you are writing new versions you
will either have to be careful with all your calls or you will need to
take care of the problem inside your versions of the testing functions.
I see in Linux /usr/include/ctype.h the macro __NO_CTYPE. It looks as
if it might do this for me:

// Ignore the locale
#define __NO_CTYPE
#include <ctype.h>
#undef __NO_CTYPE

but that looks very non-portable--I did not even bother trying it.
But it makes me wonder if there is such a thing.

Is there an officially supported macro similar to __NO_CTYPE that
allows me to make some compilation units insensitive to the locale,
while others remain sensitive to the locale?

FYI, I am coding in C++ and compiling with g++, yet posting in
comp.lang.c because these are C functions.

It's worth posting in comp.lang.c++ because C++ has a much more
sophisticated way of handling character properties. There may be a C++
specific solution.
 
B

Ben Pfaff

Seebs said:
Another is to write your own wrappers, and/or just include code from some
open source project to implement your own.

Gnulib has code for exactly this purpose.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,954
Messages
2,570,114
Members
46,702
Latest member
VernitaGow

Latest Threads

Top