bad code dept

Phil_aka_Pip

imalone said:

Phil_aka_Pip said:

apart from all the other obvious faults, what it actually does is the opposite of its name

Though I'm not sure what the name actually should do when you analyse it closely either...
Strictly speaking I'm not sure there's a standard C function that does this (character, not string). There's a very quick cheat if you can guarantee ASCII, though you lose a bit of elegance if you properly generalise it and check inputs. Bizarre way to initialise the result all things considered.
(Edit, A-F aren't guaranteed contiguous... though it'd be an evil character set that broke that.)

EBCDIC?

Alnico

Wow so understanding modes and scales is actually quite easy compared to other stuff ?

Thanks for the perspective.

Nomad

Phil_aka_Pip said:

If I had to do that by hand (no library routines available), I'd say

int HexCharToInt (char c)
{
  int result = 0;
  if ((c >= '0') && (c <= '9'))
  {
    result = c - '0'; // numeric
  }
  else
  {
    c &= 0xbf;  // to upper, if alpha
    if ((c >= 'A') && (c <= 'F'))
    {
      result = c - 'A' + 10;  // hexchar
    }
  }
  return(result);
}

I'd be inclined to initialise result to -1 or 255 rather than 0. As it stands, that routine would return a valid value (zero) if it was passed garbage. The calling routine could validate what it passes (by doing the same sort of filtering as is done in HexCharToInt), but checking the return value would be less code.

Cacofonix

Shouldn't it be iterative over the string before it hits the subroutine?

Otherwise it breaks at anything over F.

To do that would be a bit more complex, though.  It would (not a coder so bear with me) need:

a function to convert each element of the string.
a function to compile the data into columnar data to approximate the units/tens/hundreds columns in decimal from the 15s, 225s etc.
a function to calculate down the columns to aggregate the result of the string.




I bet there's a header library for that in Linux.

Phil_aka_Pip

Nomad said:

Phil_aka_Pip said:

If I had to do that by hand (no library routines available), I'd say

int HexCharToInt (char c)
{
  int result = 0;
  if ((c >= '0') && (c <= '9'))
  {
    result = c - '0'; // numeric
  }
  else
  {
    c &= 0xbf;  // to upper, if alpha
    if ((c >= 'A') && (c <= 'F'))
    {
      result = c - 'A' + 10;  // hexchar
    }
  }
  return(result);
}

I'd be inclined to initialise result to -1 or 255 rather than 0. As it stands, that routine would return a valid value (zero) if it was passed garbage. The calling routine could validate what it passes (by doing the same sort of filtering as is done in HexCharToInt), but checking the return value would be less code.

library routine atol does the same (ie initialise result to zero). I'm not saying that's right, but if you follow suit then people know how to code around it.

I'd prefer to pass the address of the sink variable, which the routine would write to if the i/p was valid. The routine would return a yes/no status to indicate validity. 

Emp_Fab

imalone

Cacofonix;420699" said:

Shouldn't it be iterative over the string before it hits the subroutine?



Otherwise it breaks at anything over F.



To do that would be a bit more complex, though.  It would (not a coder so bear with me) need:



a function to convert each element of the string.

a function to compile the data into columnar data to approximate the units/tens/hundreds columns in decimal from the 15s, 225s etc.

a function to calculate down the columns to aggregate the result of the string.









I bet there's a header library for that in Linux.

The thing is it's not a string, otherwise just sscanf or whatever. The lazy way for a single char is whack it into a four char array with a nul at the end and 0x at the start then use one of the standard functions that can read that. But you might care about efficiency and want to do it without string handling. I would go for the -1 error return for a simple function that's returning int with 16 valid values, but just a question of style.


You don't need to worry about the separate decimal digits at all if doing it by hand either, just sum up the converted hex values with their appropriate powers of 16.

Phil_aka_Pip;420655" said:

imalone said:

(Edit, A-F aren't guaranteed contiguous... though it'd be an evil character set that broke that.)


EBCDIC?

I had to check, but that actually works (A-F is contiguous, the whole alphabet is not), I just used to hang out on alt.lang.c and got paranoid about character sets. It's not guaranteed to work (only the decimal digits trick is) but requires something worse than EBCDIC to break it.

Phil_aka_Pip

I just looked up 5-bit Baudot code. That would break it big time. You'd have to use a lookup table indexed by character code ...