Re: isascii/toascii with MSVC

[John W. Eaton]

On 25-Feb-2008, Michael Goffioul wrote:

| On Mon, Feb 25, 2008 at 7:38 AM, John W. Eaton <address@hidden> wrote:
| > Even with the #undef toascii, you still need to use __toascii to get
| > the function instead of the macro?  I don't think that conforms to the
| > C langauge standard.
| 
| You don't expect MSVC to look for 100% standard compliancy, don't you?
| :-)
| 
| In my previous mail, I was slightly wrong when using ANSI C. Actually, a
| trend in MSVC is not being C (especially C99) compliant, because there
| are other possible implementation in ISO C++; typical example is the
| Complex C99 keyword: I don't think MSVC will ever support it because
| you can do complex already in C++.
| 
| When you look at MSVC documentation, it's stated that toascii is
| deprecated, in favour of the ISO C++ __toascii. If you look in the header,
| the actual function declared is __toascii. Then you have a
| 
| #define toascii __toascii
| 
| This definition is conditional to __STDC__ not being defined
| (that is, if __STDC__ is defined, you don't even get toascii).
| 
| > What happens for the following if you compile it as a C program?
| >
| > #include <stdio.h>
| > #include <ctype.h>
| > #undef toascii
| >
| > int
| > main (void)
| > {
| >  typedef int (*fptr) (int);
| >  char c = '*';
| >  int i;
| >  fptr f = toascii;
| >  i = (*f) (c);
| >  printf ("%c: %d\n", c, i);
| >  return 0;
| > }
| >
| > Does that fail because toascii is undefined?
| 
| Obviously, with what I've said before, this fails to compile.
| 
| > I think this is supposed to be one of the accepted ways to avoid
| > macros defined in ctype.h and use the functions instead, so I would
| > expect it to work.
| 
| MSVC implements the function/macro duality with __isascii/__toascii,
| not with isascii/toascii. So basically, what you have is:
| 
| extern int __toascii (int c);
| 
| #define __toascii(c) ...
| 
| #define toascii __toascii
| 
| This weirdness was easy to work around when isascii/toascii were
| only used locally in src/mappers.cc. Now that they are used in various
| headers, it's much more tricky.

So maybe we should replace all

  #include <cctype>

lines in Octave with

  #include "lo-ctype.h"

and create liboctave/lo-cctype.h that does the right thing (undefines
the macros)?

Maybe we should also add a corresponding lo-ctype.c file that provides
xisacii and xtoascii functions, and then use those everywhere in place
of isascii/toascii?  Would that fix the problem for you?  If it does,
then I think this would be a good solution as it would hide these
details in just two files.

jwe