help needed on coversin of an char array to an integer

[Flash Gordon]

Old Wolf wrote, On 22/02/08 12:55:

Because they were/are sequential on every single
system that ever had a C compiler?

Are you claiming there were no C compilers for any of the hardware that
uses EBCDIC?
http://groups.google.com/group/comp...ebcdic+hex+group:comp.lang.c#61a1b727af34b029

 

[Willem]

Flash wrote:
) Are you claiming there were no C compilers for any of the hardware that
) uses EBCDIC?
) http://groups.google.com/group/comp...ebcdic+hex+group:comp.lang.c#61a1b727af34b029

On EBCDIC, the characters 'A'..'F' and 'a'..'f' ARE consecutive.

To be more precise: The letters are in sequence, it's just that there
are gaps between i and j, and also between r and s.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[vippstar]

Old Wolf wrote, On 22/02/08 12:55:



Are you claiming there were no C compilers for any of the hardware that
uses EBCDIC?

In EBCDIC, 'a'..'f' and 'A'..'F' are sequential.
Even if there is no charset, the standard does not guarantee it, and I
believe that's all you need to know.

 

[Ben Bacarisse]

Old Wolf wrote, On 22/02/08 12:55:

Are you claiming there were no C compilers for any of the hardware
that uses EBCDIC?
http://groups.google.com/group/comp...ebcdic+hex+group:comp.lang.c#61a1b727af34b029

EBCDIC had 'a' to 'f' and 'A' to 'F' sequential, as that post states.
I don't want to advocate the assumption (since it is not hard to
avoid) but I know of no encoding in which it would not be true.

BTW, I think there *should* be an 'int toxvalue(int c);' in standard C
since the implementation can do a better job of this simple conversion
than any portable code.

 

[Richard Tobin]

Because they were/are sequential on every single
system that ever had a C compiler?

[/QUOTE]

Are you claiming there were no C compilers for any of the hardware that
uses EBCDIC?

The gaps in EBCDIC are between I and J, and R and S.

-- Richard

 

[CBFalconer]

MisterE said:


If we assume everyone on the planet - around 6600000000 people -
uses a computer, then 0.0000000000000000001% of this would be
0.0000000000066 people. Effectively, you're claiming that at
most one person on the planet uses a non-ASCII system.

You are mistaken.

Besides which 'a'..'f' and 'A'..'F' are part of the basic character
set, and required for all C systems. Their sequentiality is
unspecified.

 

[CBFalconer]

Because they were/are sequential on every single
system that ever had a C compiler?

Oh my. You have led a sheltered life. Read the standard.

 

[CBFalconer]

.... snip ...

BTW, I think there *should* be an 'int toxvalue(int c);' in
standard C since the implementation can do a better job of this
simple conversion than any portable code.

There is:

int hexvalue(int c) {
static const char s = "abcdef";
return (strchr(s, c)) - &s + 10;
}

Convert it into a macro if you wish. It returns 16 for a bad c.

 

[Bartc]

Are you claiming there were no C compilers for any of the hardware that
uses EBCDIC?

The gaps in EBCDIC are between I and J, and R and S.[/QUOTE]

Why would whoever put together EBCDIC encoding, put big holes in it like
that?

It would be more understandable if it was accented versions of some
characters, but apparently it's a couple of punctuation characters.

Whoever created it should have been fired.

Even a child would at least have come up with 1 to 26.

 

[CBFalconer]

.... snip ...

Why would whoever put together EBCDIC encoding, put big holes in
it like that? It would be more understandable if it was accented
versions of some characters, but apparently it's a couple of
punctuation characters. Whoever created it should have been fired.

Even a child would at least have come up with 1 to 26.

It made the interface with existing punch card systems easy. You
should ask questions, rather than jumping to illogical conclusions.

 

[Jean-Marc Bourguet]

Why would whoever put together EBCDIC encoding, put big holes in it like
that?

They were already existing in the code that EBCDIC extended (the E is for
extended).

Whoever created it should have been fired.

Why? They probably did a good job of compromizing between conflicting
constraints you are not aware of.

Yours,

 

[Richard Tobin]

Ben Bacarisse wrote:

There is:

int hexvalue(int c) {
static const char s = "abcdef";
return (strchr(s, c)) - &s + 10;
}

Convert it into a macro if you wish. It returns 16 for a bad c.

Um, strchr() returns NULL if the character is not present, not a
pointer to the terminating '\0'.

Ben's point was that an implementation can typically do a *better* job
than you can in standard C, noth that you can't write it. And I
strongly suspect he intended it to work for all the hex digits, not
just the alphabetic ones.

On the other hand, unless you are concerned to make the non-existent
non-sequential case work, you would probably do reasonably well with

int toxvalue(int c)
{
#if 'B' == 'A'+1 && ... && 'f' == 'a'+5
... obvious ascii-like algorithm ...
#else
... slower general algorithm ...
#endif
}

-- Richard

 

[Richard Tobin]

Why would whoever put together EBCDIC encoding, put big holes in it like
that?

Because they used punched cards.

Whoever created it should have been fired.

No-one was ever fired for buying IBM.

Wikipedia quotes a joke:

Professor: So the American government went to IBM to come up with
a data encryption standard, and they came up with-
Student: EBCDIC!

-- Richard

 

[Flash Gordon]

Richard Tobin wrote, On 22/02/08 15:13:

Are you claiming there were no C compilers for any of the hardware that
uses EBCDIC?

The gaps in EBCDIC are between I and J, and R and S.[/QUOTE]

OK, the message I spotted giving EBCDIC as a problem was wrong then.

 

[Richard Tobin]

Because they were/are sequential on every single
system that ever had a C compiler?

[/QUOTE]

Oh my. You have led a sheltered life. Read the standard.

I don't have my copy handy. Which system does it mention for which
they are not sequential?

-- Richard

 

[Flash Gordon]

Ben Bacarisse wrote, On 22/02/08 15:11:

EBCDIC had 'a' to 'f' and 'A' to 'F' sequential, as that post states.

Oops, I must have miss-read it.

 

[Bartc]

It made the interface with existing punch card systems easy. You
should ask questions, rather than jumping to illogical conclusions.

OK I didn't realise there were still mechanical limitations to consider in
the 1960s.

 

[Joe Wright]

Why would whoever put together EBCDIC encoding, put big holes in it like
that?

It would be more understandable if it was accented versions of some
characters, but apparently it's a couple of punctuation characters.

Whoever created it should have been fired.

Even a child would at least have come up with 1 to 26.

Why are you kids so much smarter than your forebears?

In the beginning there was the Hollerith Punch Card as presented by IBM
since your grandfather was a boy. The Card was 80 columns wide and 12
rows high. Rows are numbered, top to bottom, 12, 11, 0, 1, 2, 3, 4, 5,
6, 7, 8 and 9. A rectangular 'hole' is 'punched' from the Card to record
alpha-numeric information.

For a given column a numeric digit has a single punch in rows 0 through
9. An alphabetic has two punches per column. For example 'A' is a 12 and
a 1 punch. 'B' is 12 and 2 and so on. 12-9 is 'I'. The next character,
'J', is 11-1, and 'R' will be 11-9.

The next character, 'S' is at 0-2 and finally 'Z' at 0-9.

The Punch Card itself was the data medium for the longest time, until
the advent of magnetic tape. The IBM tape system was 7-channel or six
bits plus parity per character. How shall we translate all this Card
data onto MagTape?

Translate the card column into six bits, 5 and 4 the zone and 3..0 the
field. Translate Card rows 12, 11 and 0 to 11, 10 and 01 such that 0 is
000000 and 9 is 001001. 'A' is 110001, 'J' is 100001 and 'S' is 010010.

This coding system was called BCD or Binary Coded Decimal. It was
limited to 63 characters.

With the advent of the System 360 and 8-bit bytes, IBM extended its
6-bit BCD to 8-bit EBCDIC (Extended Binary Coded Decimal Interchange
Code). EBCDIC includes lower case characters and lots of other
characters in its 255-byte set.

ASCII (American Standard Code for Information Interchange) didn't have
the IBM Punch Card baggage and defined a 7-bit code which survives.

 

[Randy Howard]

OK I didn't realise there were still mechanical limitations to consider in
the 1960s.

Punch cards were still being used in the early 80s, perhaps later.

 

[CBFalconer]

.... snip ...

On the other hand, unless you are concerned to make the non-existent
non-sequential case work, you would probably do reasonably well with

int toxvalue(int c)

Well, one of my reasons for writing the faulty (above) substitute
was to avoid the reserved to... name for the routine. Fixing
it to return a unique error value is not complex.