[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isascii/toascii with MSVC
From: |
John W. Eaton |
Subject: |
Re: isascii/toascii with MSVC |
Date: |
Mon, 25 Feb 2008 04:27:29 -0500 |
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
- isascii/toascii with MSVC, Michael Goffioul, 2008/02/24
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/25
- Re: isascii/toascii with MSVC, John W. Eaton, 2008/02/25
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/25
- Re: isascii/toascii with MSVC,
John W. Eaton <=
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/25
- Re: isascii/toascii with MSVC, John W. Eaton, 2008/02/25
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/25
- Re: isascii/toascii with MSVC, John W. Eaton, 2008/02/25
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/25
- Re: isascii/toascii with MSVC, John W. Eaton, 2008/02/25
- Re: isascii/toascii with MSVC, Michael Goffioul, 2008/02/26
- Re: isascii/toascii with MSVC, Daniel J Sebald, 2008/02/25