Convert HEX string to bin

[Mark McIntyre]

It is, however, true in both ASCII and EBCDIC.

Do you know anyone using a different character set?

Only a couple of billion of them.

"All the world's a Vax" as someone once said.

 

[CBFalconer]

.... snip ...

char *p
unsigned int v;
int d;

.....
p = &instring[0];
v = 0;
while ((d = unhexify(*p)) >= 0) {
v = 16 * v + d;
++p;
}
/* desired result in v */

Calling a function for each char is another brake. I had not used
pointers because I'm not sure that the OP is ready to understund
pointer arithmetc yet and any good compiler should create even the
same code.

By that, the separate p++ can be another brake as many real CPU
can do *p++ in an single instruction instead of *p and some times
later p += 1.

That combination is a trap. It would allow the pointer to be
advanced past the known area of instring, which may or may not be
legitimate.

And that is really wrong. As the standard allows to build the address
of the first member directly behind the array.

Not if one of the objectives is to examine the termination
character. It is an extremely minor point anyhow, and closer to a
style criterion than anything else.

 

[CBFalconer]

It has the same bug that I deliberately left unfixed in my
version, posted to the original thread ;-)

What's that? I am offline here, and no such posting remains on my
machine.

AHA - I think I see it. It needs:

if (c && (p = strchr(hexchars, c))) {

 

[The Real OS/2 Guy]

Not if one of the objectives is to examine the termination
character. It is an extremely minor point anyhow, and closer to a
style criterion than anything else.

Even then can you build legally the address of the member directly
behind the last one. You may not allowed to dereference it, so it may
useless for other than decrement it.

 

[Dan Pop]

That's the most dangerous kind of typos: the ones that aren't caught
by the compiler and are hard to find, even when you *know* they are
there (and yes, I know that you already knew that .

Not at all: if I actually needed that function for one of my programs,
I would have tested it. All the results produced for the "digits" A to F
being off by one, the origin of the bug is obvious: an extraneous
character between 9 and A in the string literal. No need to actually
reread it, because I know the exact the position of the character that
needs to be deleted.

Dan

 

[Dan Pop]

'A' exists in both the basic source and basic execution character sets.

True, but how does it look like in the basic execution character set?

One of my most important objections to the C standard is that it doesn't
guarantee the semantics of the characters in the basic execution character
set. Therefore, you have no idea how the output of the canonical hello
world program would look on a conforming implementation. One performing
Rot13 to convert from source characters to execution characters would
be perfectly conforming, as far as the standard is concerned.

Dan

 

[goose]

The trivial, assumption free approach is to define the hex digits
yourself:

int hex2dec(char c)
{
char *hexdigs = "01234567890ABCDEF";

^

char *p = strchr(hexdigs, toupper((unsigned char)c));

if (p != NULL)
return p - hexdigs;

return (int) (p - hexdigs);

else
return -1;
}

Trivia quiz: find the bug in this code.

printf (A is %i\n", hex2dec ('A'));

should result in

A is 11

what do i get ?

goose,

 

[Dan Pop]

printf (A is %i\n", hex2dec ('A'));

should result in

A is 11

That was the typo in the code, not the bug ;-)

Dan

 

[Anupam]

Which one? The c == 0 bug?

'0' surely??

Actually it will return the actual represenation + 1 for all the
digits from 'A' to 'F'.
Change to :
char *hexdigs = "0123456789ABCDEF";

Regards,
Anupam

 

[Irrwahn Grausewitz]

'0' surely??

No. Hint: what does strchr return if c == 0?

Actually it will return the actual represenation + 1 for all the
digits from 'A' to 'F'.
Change to :
char *hexdigs = "0123456789ABCDEF";

That was the typo, not the bug.

Regards

 

[Anupam]

No. Hint: what does strchr return if c == 0?

Oh that's quite Ok. I understand that strchr returns a pointer
to the terminating '\0' at the end of the string, so the return will
not be -1 to indicate that its not a hex digit. Rather it will be
16.
But I thought that the double '0' inside the string was a more evident
bug. Should have guessed at it not being quite so simple .

 

[Anupam]

No. Hint: what does strchr return if c == 0?


That was the typo, not the bug.

Beg your pardon. You had already posted the answer. I was too fast at
the typing trigger.

 

[Anupam]

printf (A is %i\n", hex2dec ('A'));

^
printf ("A is %i\n", hex2dec ('A'));

Comprendo

 

[goose]

^

ooohh ... the *irony* of me pointing out a typo

printf ("A is %i\n", hex2dec ('A'));

Comprendo

yup. good catch (most others missed it

goose,
i cnt spll wrth a dam!!!