help needed on coversin of an char array to an integer

[CBFalconer]

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

Please preserve attributions for any material you quote.

The standard simply does not insist on sequential coding for
non-numeric characters. It never mentions specific systems.

 

[vippstar]

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

#include <ctype.h>
int tohex(int c) {
static const char s[] = "0123456789abcdef";
return isxdigit((unsigned char)c) ? strchr(s, tolower((unsigned
char)c)) - s : 16;
}
It doesn't make sense for a tohex to return anything other than 0-15,
so the error value here is 16, but it could also be -1.

 

[Harald van Dijk]

Please preserve attributions for any material you quote.

The standard simply does not insist on sequential coding for non-numeric
characters. It never mentions specific systems.

So _you_ don't actually have any example of a system where 'A'..'F' are
not sequential? Would you drop the attitude, then? It's not required by
the standard, but if it's true that no conforming implementation of C has
ever yet been produced where 'A'..'F' are not sequential, then it's more
likely that some future C standard will guarantee it, than that someone
produces a system where other characters exist between 'A'..'F'.

 

[Ben Bacarisse]

So _you_ don't actually have any example of a system where 'A'..'F' are
not sequential? Would you drop the attitude, then? It's not required by
the standard, but if it's true that no conforming implementation of C has
ever yet been produced where 'A'..'F' are not sequential, then it's more
likely that some future C standard will guarantee it, than that someone
produces a system where other characters exist between 'A'..'F'.

I'd be happy with that option too (a guarantee that they be
consecutive and increasing). Writing either the string lookup or the
switch statement solution always seems daft when I know the
subtraction would have worked on all machines I've ever used[1].
However, something in me balks at making an assumption not guaranteed
by the language.

Is it worth asking for 'int toxvalue(int c)', or a guarantee that 'a' to
'f' and 'A' to 'F' are consecutive? It seems a small matter, but an
irritating one.

[1] The oddest being a CDC with a 6-bit character code, OK, you can't
implement C in a conforming way on such a machine, but even that had
consecutive A-F (no lowercase).

 

[CBFalconer]

.... snip ...

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.

I have built char sets that go "aAbBcC...zZ". Very handy for some
sorting problems. What ever gave you the idea that char sets had
to be ASCII or EBCDIC?

 

[Harald van Dijk]

[...] if it's true that no conforming implementation of C
has ever yet been produced where 'A'..'F' are not sequential, then it's
more likely that some future C standard will guarantee it, than that
someone produces a system where other characters exist between
'A'..'F'.

I'd be happy with that option too (a guarantee that they be consecutive
and increasing).

To clarify, I don't consider the chance of a guarantee in the standard
particularly high, just higher than that of an implementation where the
stated assumption doesn't hold.

Is it worth asking for 'int toxvalue(int c)', or a guarantee that 'a'
to 'f' and 'A' to 'F' are consecutive? It seems a small matter, but an
irritating one.

If all systems had 'A' to 'Z' as consecutive, I doubt it would have been
much of a problem to get that standardised, but 'A' to 'F' seems like a
silly restriction on an otherwise much more useful guarantee.

toxvalue is a nice idea, though.

 

[Bartc]

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

Thanks, all interesting stuff.

But thinking of it, I remember doing a programming course with punch cards,
on a machine that was definitely not EBCDIC!

So presumably it was just confined to the card reader, immediately converted
to ASCII or SIXBIT, whatever was used.

Only IBM it seems wanted to inflict EBCDIC on all parts of their systems.