Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

Pilcrow <pilcrow@pp.infowrites:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

You could do something like this:

if ('A' == 0x41) {
/* Probably ASCII. */
} else if ('A' == 0xc1) {
/* Probably EBCDIC. */
}
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

On Sep 3, 1:11 am, Pilcrow <pilc...@pp.infowrote:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

No.
But you can check if a certain symbol has been mapped to the same
value as ASCII/EBCDIC:

#if 'A' == 65
/* A is mapped to the same value as ASCII */
#elif
/* A is not mapped to the same value as ASCII */
#endif

That's not telling you much though.

Pilcrow said:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

Almost.

What you can do is check code points for the basic character set. If 'A' is
65, and 'B' is 66, and... (etc) and 'Z' is, er, 90, and 'a' is 97, and 'b'
is 98, and... (etc) and 'z' is 122, and the digits are 48 through 57, and
' ' is 32, and so on and so forth with all the !"%^&*()_-=+<,>.?/\\;:'~#
stuff, and if '\n' is 10 and '\r' is 13 and '\f' is 12 and so on, then the
chances are very good that it's ASCII.

Some trick for EBCDIC, but with different numbers.

Not 100% foolproof, but it may suit your needs - and if those two character
sets are your only two choices, then you can do it with a single
comparison ('A' == 65) and be assured that your result is correct.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On 2 Sep 2008 at 22:11, Pilcrow wrote:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

#include <stdio.h>
#include <time.h>

int main(void)
{
time_t t;
time(&t);
if(gmtime(&t)->tm_year 75)
puts("ASCII!");
return 0;
}

On Sep 3, 1:22 am, vipps...@gmail.com wrote:

On Sep 3, 1:11 am, Pilcrow <pilc...@pp.infowrote:
>

>
No.
But you can check if a certain symbol has been mapped to the same
value as ASCII/EBCDIC:
>
#if 'A' == 65
/* A is mapped to the same value as ASCII */
#elif

^^^^
That should've been 'else'.

On Sep 3, 1:29 am, Richard Heathfield <r...@see.sig.invalidwrote:

Pilcrow said:
>

>
Almost.
>
What you can do is check code points for the basic character set. If 'A' is
65, and 'B' is 66, and... (etc) and 'Z' is, er, 90, and 'a' is 97, and 'b'
is 98, and... (etc) and 'z' is 122, and the digits are 48 through 57, and [...]

You only need to check for one digit, it's guaranteed that '9' - '0'
== 9.

<snip>

Pilcrow wrote:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

You could check some known chars against the EBCDIC and ASCII
numeric values:

if ('0' == 48 && 'A' == 65 && 'z' == 122 && ...)
puts ("Looks like ASCII");
else if ('0' == 240 && 'A' == 193 && 'z' == 169 && ...)
puts ("Looks like EBCDIC");
else
puts ("Now I *know* we're not in Kansas!");

It seems an uncertain business, though, because both ASCII and EBCDIC
define characters that can't be written as portable character literals
(what do you put between the '' to get EBCDIC's RSP character *and*
have it mean something on an ASCII system?), and because I don't see
how you can reliably distinguish between an ASCII system and one that
uses a more modern encoding that includes ASCII as a subset.

What's the purpose?

--
Eric.Sosman@sun.com

Pilcrow wrote:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

You can check character values. Why do you want to?




Brian

vippstar@gmail.com writes:

But you can check if a certain symbol has been mapped to the same
value as ASCII/EBCDIC:
>
#if 'A' == 65
/* A is mapped to the same value as ASCII */
#elif
/* A is not mapped to the same value as ASCII */
#endif

I don't think that's guaranteed to work, because preprocessor
directives are interpreted in the source character set, which may
differ arbitrarily from the execution character set. It could be
the case that the source character set is ASCII and the execution
character set is EBCDIC, as far as I know.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

On September 2, 2008 18:11, in comp.lang.c, Pilcrow (pilcrow@pp.info) wrote:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

Which EBCDIC? There are about 30 EBCDIC variants to choose from. See all the
EBCDIC-xx charts at http://anubis.dkuug.dk/i18n/charmaps/ (the site of the
ISO Internationalization effort)

FWIW, the exclamation mark ('!') is 0x21 in ASCII, 0x5a in EBCDIC-US, and
0x4f in EBCDIC-INT.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

On Sep 3, 2:09 am, Ben Pfaff <b...@cs.stanford.eduwrote:

vipps...@gmail.com writes:

>

>
I don't think that's guaranteed to work, because preprocessor
directives are interpreted in the source character set, which may
differ arbitrarily from the execution character set. It could be
the case that the source character set is ASCII and the execution
character set is EBCDIC, as far as I know.

Ah - I did not think of that. Then perhaps change it to `if'.

if('A' == 65) { ... }

Pilcrow <pilcrow@pp.infowrites:

Is there a way that a proram can detect whether it is operating in an
ASCII or an EBCDIC environment?

As others have suggested, testing the numeric values of some
characters will probably tell you.

But note that there are several different variants of EBCDIC. As for
ASCII, remember that it's only a 7-bit character set. There are
numerous larger sets based on ASCII. There are the 8-bit ISO 8859-N
sets, with N running from 1 to about 15 last I heard. There's
Unicode. There's a Windows-specific 8-bit extension to ASCII. And
there are national variants that replace some of the punctuation
characters with accented letters, though these aren't used much
anymore.

If at all possible, it's better to write your code so it will work
with *any* character set. For example, if you want to know whether a
character is a lowercase letter, don't use (c >= 'a' && c <= 'z'), use
isascii(unsigned char(c)).

What problem are you really trying to solve?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Sep 3, 3:47 am, Keith Thompson <ks...@mib.orgwrote:

Pilcrow <pilc...@pp.infowrites:

>
As others have suggested, testing the numeric values of some
characters will probably tell you.
>
But note that there are several different variants of EBCDIC. As for
ASCII, remember that it's only a 7-bit character set. There are
numerous larger sets based on ASCII. There are the 8-bit ISO 8859-N
sets, with N running from 1 to about 15 last I heard. There's
Unicode. There's a Windows-specific 8-bit extension to ASCII. And
there are national variants that replace some of the punctuation
characters with accented letters, though these aren't used much
anymore.
>
If at all possible, it's better to write your code so it will work
with *any* character set. For example, if you want to know whether a
character is a lowercase letter, don't use (c >= 'a' && c <= 'z'), use
isascii(unsigned char(c)).

That should be islower((unsigned char)c) of course.
(it's not the unsigned char mistake that bugs me; it's the isascii()
one :S)

vippstar@gmail.com writes:

On Sep 3, 3:47 am, Keith Thompson <ks...@mib.orgwrote:

[...]

>
That should be islower((unsigned char)c) of course.
(it's not the unsigned char mistake that bugs me; it's the isascii()
one :S)

D'oh! You're right, of course (and both mistakes bug me equally).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 02 Sep 2008 15:11:49 -0700, Pilcrow <pilcrow@pp.infowrote:

>Is there a way that a proram can detect whether it is operating in an
>ASCII or an EBCDIC environment?

OK, it seems I have my answer: if('i' + 1 != 'j') we definitely don't
have ASCII. Most likely we have some flavor of EBCDIC. But, since the
compiler will have been compiled in either the ASCII or the EBCDIC
environment, it seems that there could have been some macro that would
have told us so directly.

IBM definitely is MS's predecessor in promoting incompatibility. But I
knew that years ago.

Again, I apologize for inadvertantly casting aspersions on your favorite
language. People often (and in clc) make slurs against Perl; it doesn't
bother me.

On Sep 3, 7:41 am, Pilcrow <pilc...@pp.infowrote:

On Tue, 02 Sep 2008 15:11:49 -0700, Pilcrow <pilc...@pp.infowrote:

>
OK, it seems I have my answer: if('i' + 1 != 'j') we definitely don't

That expression invokes undefined behavior if 'i' equals INT_MAX.

<snip>

On Tue, 2 Sep 2008 21:49:51 -0700 (PDT), vippstar@gmail.com wrote:

>On Sep 3, 7:41 am, Pilcrow <pilc...@pp.infowrote:

>
>That expression invokes undefined behavior if 'i' equals INT_MAX.
>
><snip>

Would it ever? and when?

On Tue, 02 Sep 2008 21:49:51 -0700, vippstar wrote:

On Sep 3, 7:41 am, Pilcrow <pilc...@pp.infowrote:

>
That expression invokes undefined behavior if 'i' equals INT_MAX.

If the character set is either ASCII or EBCDIC, 'i' cannot equal INT_MAX.
If it is not, the check is insufficient anyway.

Harald van Dijk wrote:

On Tue, 02 Sep 2008 21:49:51 -0700, vippstar wrote:

>
If the character set is either ASCII or EBCDIC, 'i' cannot equal INT_MAX.
If it is not, the check is insufficient anyway.

if ('a' != 97) puts("Not ASCII");
if ('a' != 129) puts("Not EBCDIC");

--
pete

On Sep 3, 8:03 am, Harald van D©¦k <true...@gmail.comwrote:

On Tue, 02 Sep 2008 21:49:51 -0700, vippstar wrote:

>

>

>
If the character set is either ASCII or EBCDIC, 'i' cannot equal INT_MAX.

So? 'i' + 1 still invokes undefined behavior :)

If it is not, the check is insufficient anyway.

I agree.

On 2 Sep, 23:25, Antoninus Twink <nos...@nospam.invalidwrote:

On 2 Sep 2008 at 22:11, Pilcrow wrote:

>
#include <stdio.h>
#include <time.h>
>
int main(void)
{
time_t t;
time(&t);
if(gmtime(&t)->tm_year 75)
puts("ASCII!");
return 0;
}

despite what twink implies I believe EBCDIC machines do still
exist. The IBM mainfram world is still alive and well.


--
Nick Keighley

Nick Keighley <nick_keighley_nospam@hotmail.comwrites:

On 2 Sep, 23:25, Antoninus Twink <nos...@nospam.invalidwrote:

>

>
despite what twink implies I believe EBCDIC machines do still
exist. The IBM mainfram world is still alive and well.

Yes. But one has to wonder how many routines written by people looking
for help here will end up running on them....

<vippstar@gmail.comwrote in message
news:f00bebcc-8539-4240-bca8-9ff3c5ed388e@z66g2000hsc.googlegroups.com...

On Sep 3, 7:41 am, Pilcrow <pilc...@pp.infowrote:

>
That expression invokes undefined behavior if 'i' equals INT_MAX.

If one has to continually worry about a+1 invoking undefined behaviour, then
no line of code is ever going to get written.

Anyway your example should give a compile-time error.

--
Bartc

On Sep 3, 12:15 pm, "Bartc" <b...@freeuk.comwrote:

<vipps...@gmail.comwrote in message
>
news:f00bebcc-8539-4240-bca8-9ff3c5ed388e@z66g2000hsc.googlegroups.com...
>

>

>

>
If one has to continually worry about a+1 invoking undefined behaviour, then
no line of code is ever going to get written.

a+1 no. 'i' + 1 perhaps, and I disagree. There's already many lines of
code written that do not invoke undefined behavior.

Anyway your example should give a compile-time error.

I know. I have written a correction in a follow-up
Message-ID:
<795a77f1-1dd2-4d6f-834f-43ec772b398b@y21g2000hsf.googlegroups.com>
Unless you are referring to something else.

Pilcrow wrote:

On Tue, 02 Sep 2008 15:11:49 -0700, Pilcrow <pilcrow@pp.infowrote:
>

>
OK, it seems I have my answer: if('i' + 1 != 'j') we definitely don't
have ASCII. Most likely we have some flavor of EBCDIC. But, since the
compiler will have been compiled in either the ASCII or the EBCDIC
environment, it seems that there could have been some macro that would
have told us so directly.

I think you're assuming that ASCII and EBCDIC are the only two
possibilities. There are LOTS of other possibilities, including a fairly
large number that are in wide use. Unicode, in particular, is very
widely used.

Pilcrow wrote:

On Tue, 02 Sep 2008 15:11:49 -0700, Pilcrow <pilcrow@pp.infowrote:
>

>
OK, it seems I have my answer: if('i' + 1 != 'j') we definitely don't
have ASCII. Most likely we have some flavor of EBCDIC. But, since the
compiler will have been compiled in either the ASCII or the EBCDIC
environment, it seems that there could have been some macro that would
have told us so directly.

I don't see how. When you take into account the fact that
things like "code pages" can change at run-time, the compiler
seems at a disadvantage in trying to predict them ...

Again, what's the purpose? What are you trying to accomplish
that requires you to know whether the system uses ASCII (which
variant?), EBCDIC (which variant?), ISO 8859-1, ...?

--
Eric.Sosman@sun.com

Eric Sosman <Eric.Sosman@sun.comwrites:

Pilcrow wrote:

>
I don't see how. When you take into account the fact that
things like "code pages" can change at run-time, the compiler
seems at a disadvantage in trying to predict them ...

ISTR that the characters in the basic characters set have their code the
same in all supported locale (ie you can't have support for both a
EBCDIC-based and a ASCII-based locale without having one of them remap the
characters).

Yours,

--
Jean-Marc

Jean-Marc Bourguet wrote:

Eric Sosman <Eric.Sosman@sun.comwrites:
>

>
ISTR that the characters in the basic characters set have their code the
same in all supported locale (ie you can't have support for both a
EBCDIC-based and a ASCII-based locale without having one of them remap the
characters).

If the question is restricted to the encoding of the
basic execution set -- the characters that the Standard
requires to be present -- then a straightforward exhaustive
test can determine whether the encoding for those characters
is "consistent with ASCII" or "consistent with EBCDIC" or
"consistent with neither." But is that enough for the O.P.?
Again, yet again, we get back to the question: What is he
*really* trying to find out, and why? (Since the question
has been asked at least four times by at least three people
and has elicited no answer, I'm beginning to think he doesn't
know.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

"Eric Sosman" writes:

If the question is restricted to the encoding of the
basic execution set -- the characters that the Standard
requires to be present -- then a straightforward exhaustive
test can determine whether the encoding for those characters
is "consistent with ASCII" or "consistent with EBCDIC" or
"consistent with neither." But is that enough for the O.P.?
Again, yet again, we get back to the question: What is he
*really* trying to find out, and why? (Since the question
has been asked at least four times by at least three people
and has elicited no answer, I'm beginning to think he doesn't
know.)

My guess is that he is one of those annoying (to many of the regulars on
this froup) curious guys who just likes to know things.

Pretty pathetic, huh?

On Wed, 3 Sep 2008 20:03:51 -0700, "osmium" <r124c4u102@comcast.net>
wrote:

>"Eric Sosman" writes:
>

>
>My guess is that he is one of those annoying (to many of the regulars on
>this froup) curious guys who just likes to know things.
>
>Pretty pathetic, huh?
>

Thank you, Os.


----
If you refrain from asking questions from fear of seeming
stupid, you'll never learn, and that would be stupid.

On Tue, 02 Sep 2008 21:41:45 -0700, Pilcrow <pilcr