Hi,
      Im kinda stuck in a project at a point where i need an array to
be converted to a
integer using some kind of math.
      This board does not support functions like scanf, sscanf etc as
it does not have enough memory to hold their stack.

      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
'c' , 'a' };
      i need a function which can convert this array to an integer
( 0x0001fbca )

 Expecting a quick response.

Thanks
MAx

On Feb 21, 2:21=A0pm, MAx <mahesh1...@gmail.com> wrote:
> Hi,
> =A0 =A0 =A0 Im kinda stuck in a project at a point where i need an array t=
o
> be converted to a
> integer using some kind of math.
> =A0 =A0 =A0 This board does not support functions like scanf, sscanf etc a=
s
> it does not have enough memory to hold their stack.
>
> =A0 =A0 =A0 given a string =A0char str[8] =3D {'0', '0', '0' , '1' , 'f' ,=
 'b' ,
> 'c' , 'a' };
> =A0 =A0 =A0 i need a function which can convert this array to an integer
> ( 0x0001fbca )
>
> =A0Expecting a quick response.
>
> Thanks
> MAx

I forgot to mention that the contents of the array will be in the
range 0 to 9 and a to f,
its a hex number read inone digit at a time :-)

On 21 Feb, 09:21, MAx <mahesh1...@gmail.com> wrote:
> Hi,
> =A0 =A0 =A0 Im kinda stuck in a project at a point where i need an array t=
o
> be converted to a
> integer using some kind of math.
> =A0 =A0 =A0 This board does not support functions like scanf, sscanf etc a=
s
> it does not have enough memory to hold their stack.
>
> =A0 =A0 =A0 given a string =A0char str[8] =3D {'0', '0', '0' , '1' , 'f' ,=
 'b' ,
> 'c' , 'a' };
> =A0 =A0 =A0 i need a function which can convert this array to an integer
> ( 0x0001fbca )
>
> =A0Expecting a quick response.

really?

On Feb 21, 11:21 am, MAx <mahesh1...@gmail.com> wrote:
> Hi,
>       Im kinda stuck in a project at a point where i need an array to
> be converted to a
> integer using some kind of math.
>       This board does not support functions like scanf, sscanf etc as
> it does not have enough memory to hold their stack.
Which "board" is that?
>       given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
> 'c' , 'a' };
That is not a string as it is not terminated with a 0.
>       i need a function which can convert this array to an integer
> ( 0x0001fbca )
Trivial
>  Expecting a quick response.
Is it you who expects an answer, or your teacher?

"MAx" <mahesh1280@gmail.com> wrote in message 
news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
> Hi,
>      Im kinda stuck in a project at a point where i need an array to
> be converted to a
> integer using some kind of math.
>      This board does not support functions like scanf, sscanf etc as
> it does not have enough memory to hold their stack.
>
>      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
> 'c' , 'a' };
>      i need a function which can convert this array to an integer
> ( 0x0001fbca )
>
> Expecting a quick response.
>
> Thanks
> MAx

int i;
int r = 0;
for (i=0;i<8;i++)
{
    if ((str[i] >= '0')&&(str[i]<='9')) r |= str[i] - '0';
    else if ((str[i] >= 'A')&&(str[i]<='F')) r |= str[i] - 'A' + 10;
    else if ((str[i] >= 'a') && (str[i]<='f')) r |= str[i] - 'a' + 10;
    if (i != 7) r <<=4;
}

On Feb 21, 11:34 am, "MisterE" <Mist...@nimga.com> wrote:
> "MAx" <mahesh1...@gmail.com> wrote in message
>
> news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
>
>
>
> > Hi,
> >      Im kinda stuck in a project at a point where i need an array to
> > be converted to a
> > integer using some kind of math.
> >      This board does not support functions like scanf, sscanf etc as
> > it does not have enough memory to hold their stack.
>
> >      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
> > 'c' , 'a' };
> >      i need a function which can convert this array to an integer
> > ( 0x0001fbca )
>
> > Expecting a quick response.
>
> > Thanks
> > MAx
>
> int i;
> int r = 0;
> for (i=0;i<8;i++)
> {
>     if ((str[i] >= '0')&&(str[i]<='9')) r |= str[i] - '0';
>     else if ((str[i] >= 'A')&&(str[i]<='F')) r |= str[i] - 'A' + 10;
>     else if ((str[i] >= 'a') && (str[i]<='f')) r |= str[i] - 'a' + 10;
>     if (i != 7) r <<=4;
>
> }
What makes you think 'A'..'F' (and lowercase) are indeed sequential?
If you plan on posting C code for the OP, then.. at least post code
that works.

Given the restrictions of this, here's a solution I suggest:
--
#include <stdio.h>

int main(void) {

  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' , 'c' , 'a' };
  unsigned int i;
  FILE * foo;

  foo = tmpfile();
  if(foo != NULL) {
    fwrite(str, 1, sizeof str, foo);
    rewind(foo);
    fscanf(foo, "%x", &i);
    fclose(foo);
  }

  return 0;
}

vippstar@gmail.com wrote:
> On Feb 21, 11:34 am, "MisterE" <Mist...@nimga.com> wrote:
>> "MAx" <mahesh1...@gmail.com> wrote in message
>>
>> news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
>>
>>
>>
>>> Hi,
>>>      Im kinda stuck in a project at a point where i need an array to
>>> be converted to a
>>> integer using some kind of math.
>>>      This board does not support functions like scanf, sscanf etc as
>>> it does not have enough memory to hold their stack.
>>
>>>      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b'
>>> , 'c' , 'a' };
>>>      i need a function which can convert this array to an integer
>>> ( 0x0001fbca )
>>
>>> Expecting a quick response.
>>
>>> Thanks
>>> MAx
>>
>> int i;
>> int r = 0;
>> for (i=0;i<8;i++)
>> {
>>     if ((str[i] >= '0')&&(str[i]<='9')) r |= str[i] - '0';
>>     else if ((str[i] >= 'A')&&(str[i]<='F')) r |= str[i] - 'A' + 10;
>>     else if ((str[i] >= 'a') && (str[i]<='f')) r |= str[i] - 'a' +
>>     10; if (i != 7) r <<=4;
>>
>> }
> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> If you plan on posting C code for the OP, then.. at least post code
> that works.
>
> Given the restrictions of this, here's a solution I suggest:
Oops, your "-- " makes the rest a signature and snips your code...
Restored manually:
>#include <stdio.h>
>
>int main(void) {
>
>  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' , 'c' , 'a' };
>  unsigned int i;
>  FILE * foo;
>
>  foo = tmpfile();
>  if(foo != NULL) {
>    fwrite(str, 1, sizeof str, foo);
>    rewind(foo);
>    fscanf(foo, "%x", &i);
>    fclose(foo);
>  }
>
>  return 0;
>}
the OP claimed not to be able to use scanf and sscanf as his board doesn't 
have this, so what makes you thing he can created files and/or use fscanf?

Bye, Jojo

On Feb 21, 12:00 pm, "Joachim Schmitz" <nospam.j...@schmitz-
digital.de> wrote:
> vipps...@gmail.com wrote:
> > On Feb 21, 11:34 am, "MisterE" <Mist...@nimga.com> wrote:
> >> "MAx" <mahesh1...@gmail.com> wrote in message
>
> >>news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
>
> >>> Hi,
> >>>      Im kinda stuck in a project at a point where i need an array to
> >>> be converted to a
> >>> integer using some kind of math.
> >>>      This board does not support functions like scanf, sscanf etc as
> >>> it does not have enough memory to hold their stack.
>
> >>>      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b'
> >>> , 'c' , 'a' };
> >>>      i need a function which can convert this array to an integer
> >>> ( 0x0001fbca )
>
> >>> Expecting a quick response.
>
> >>> Thanks
> >>> MAx
>
> >> int i;
> >> int r = 0;
> >> for (i=0;i<8;i++)
> >> {
> >>     if ((str[i] >= '0')&&(str[i]<='9')) r |= str[i] - '0';
> >>     else if ((str[i] >= 'A')&&(str[i]<='F')) r |= str[i] - 'A' + 10;
> >>     else if ((str[i] >= 'a') && (str[i]<='f')) r |= str[i] - 'a' +
> >>     10; if (i != 7) r <<=4;
>
> >> }
> > What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> > If you plan on posting C code for the OP, then.. at least post code
> > that works.
>
> > Given the restrictions of this, here's a solution I suggest:
>
> Oops, your "-- " makes the rest a signature and snips your code...
> Restored manually:
Ah, that was silly.
I should've written "-- snip.c --" as I usually do. Oh well.
> >#include <stdio.h>
>
> >int main(void) {
>
> >  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' , 'c' , 'a' };
> >  unsigned int i;
> >  FILE * foo;
>
> >  foo = tmpfile();
> >  if(foo != NULL) {
> >    fwrite(str, 1, sizeof str, foo);
> >    rewind(foo);
> >    fscanf(foo, "%x", &i);
> >    fclose(foo);
> >  }
>
> >  return 0;
> >}
>
> the OP claimed not to be able to use scanf and sscanf as his board doesn't
> have this, so what makes you thing he can created files and/or use fscanf?
I only wrote a solution given the restrictions. :-)
Ofcourse there is a "better" solution, and I suspect the one that OP
looks for.
However, it sounds like a homework assignment because the task is
quite trivial; furthermore I believe it would "harm" OP and others
more to give a working solution than to make him work it on his own.

MAx wrote:
) Hi,
)       Im kinda stuck in a project at a point where i need an array to
) be converted to a
) integer using some kind of math.
)       This board does not support functions like scanf, sscanf etc as
) it does not have enough memory to hold their stack.
)
)       given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
) 'c' , 'a' };
)       i need a function which can convert this array to an integer
) ( 0x0001fbca )

Since you're talking about a 'board' I assume that you have a single,
fixed platform, and that your character set is ASCII.

I also assume that char is 8 bits and unsigned long is at least 32 bits,
that you will never have malformed input, and that you want a lean and
mean solution.

This makes the following (quite evil) code possible:

unsigned long hex2num(unsigned char str[8])
{
  unsigned long *res, dig;
  res = (unsigned long *)str;
  dig = ((*res & 0x10101010) >> 4) * 0x0f;
  *res = (*res & dig) | ((*res + 0x09090909) & (dig ^ 0x0f0f0f0f));
  res = (unsigned long *)(str + 4);
  dig = ((*res & 0x10101010) >> 4) * 0x0f;
  *res = (*res & dig) | ((*res + 0x09090909) & (dig ^ 0x0f0f0f0f));
 
  return (str[7]      ) + (str[6] << 4)
       + (str[5] << 8 ) + (str[4] << 12)
       + (str[3] << 16) + (str[2] << 20)
       + (str[1] << 24) + (str[0] << 28);
}

Which should translate nicely into assembly.
(The last bit with the return might be sped up a bit, still).


As an exercise to the reader: How many assumptions does this
code make that are outside the C standard ?


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

MAx wrote:
> Hi,
>       Im kinda stuck in a project at a point where i need an array to
> be converted to a
> integer using some kind of math.
>       This board does not support functions like scanf, sscanf etc as
> it does not have enough memory to hold their stack.
> 
>       given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
> 'c' , 'a' };
>       i need a function which can convert this array to an integer
> ( 0x0001fbca )

Then write one. It's not exactly difficult.

   * Start with a running total, set initially to 0.
   * Get a digit at a time, convert it into a numeric value,
     multiply the running total by 16 and add the digit's value.
   * When you run out of digits, you're done

Converting a character (e.g. '9' or 'a') to it's numeric value is a
little more tricky, but not very.

According to the standard, '0' - '9' are contiguous in the character
set, therefore the can always be converted to integers by subtracting
'0', so that's easy.

If you can guarantee that your character set has contiguous alphabetics
(ASCII does, but some representations don't), you can covert alphabetic
characters to their value in the hexadecimal range by subtracting 'a'
(or 'A' as appropriate) and adding 10.

If your character set isn't contiguous (or you're not sure that it will
be so everywhere that your code may need to run), you'll need to use a
lookup table or switch block.

>  Expecting a quick response.

Nice to see an optimist.

"MAx" <mahesh1280@gmail.com> wrote in message 
news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
> Hi,
>      Im kinda stuck in a project at a point where i need an array to
> be converted to a
> integer using some kind of math.
>      This board does not support functions like scanf, sscanf etc as
> it does not have enough memory to hold their stack.
>
>      given a string  char str[8] = {'0', '0', '0' , '1' , 'f' , 'b' ,
> 'c' , 'a' };
>      i need a function which can convert this array to an integer
> ( 0x0001fbca )

I assume sometimes the string will be something else? Otherwise it's rather 
trivial.

Where are the hex digits coming from? If from a hex keyboard, then each 
digit may already be 0 to 15 then combining to an integer value is very easy 
(each digit corresponds to a 4-bit chunk).

Complete solutions have already been posted, the only tricky bit is 
converting each character, 0 1 2 3 4 5 6 7 8 9 a b c d e f (and maybe A B C 
D E F?) to a value 0 to 15.

--
Bart 

On Feb 22, 12:55=A0am, "Bartc" <b...@freeuk.com> wrote:
> "MAx" <mahesh1...@gmail.com> wrote in message
>
> news:6f4d18ab-ae46-4064-9d51-7251a738f646@n77g2000hse.googlegroups.com...
>
> > Hi,
> > =A0 =A0 =A0Im kinda stuck in a project at a point where i need an array =
to
> > be converted to a
> > integer using some kind of math.
> > =A0 =A0 =A0This board does not support functions like scanf, sscanf etc =
as
> > it does not have enough memory to hold their stack.
>
> > =A0 =A0 =A0given a string =A0char str[8] =3D {'0', '0', '0' , '1' , 'f' =
, 'b' ,
> > 'c' , 'a' };
> > =A0 =A0 =A0i need a function which can convert this array to an integer
> > ( 0x0001fbca )
>
> I assume sometimes the string will be something else? Otherwise it's rathe=
r
> trivial.
>
> Where are the hex digits coming from? If from a hex keyboard, then each
> digit may already be 0 to 15 then combining to an integer value is very ea=
sy
> (each digit corresponds to a 4-bit chunk).
>
> Complete solutions have already been posted, the only tricky bit is
> converting each character, 0 1 2 3 4 5 6 7 8 9 a b c d e f (and maybe A B =
C
> D E F?) to a value 0 to 15.
>
> --
> Bart




Hey,
   Thanks guys, got the code to work. MisterE's solution did the
trick. Thanks man.

MAx said:

<snip>
 
> Hey,
>    Thanks guys, got the code to work. MisterE's solution did the
> trick. Thanks man.


Unfortunately, there are circumstances in which that code *won't* do the 
trick. Presumably you have investigated these circumstances and determined 
that they will never apply to your code's user base?


-- 
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

> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> If you plan on posting C code for the OP, then.. at least post code
> that works.

I don't bother assuming he is one of 0.0000000000000000001% of people who 
don't use ASCII character set for raw chars in c.

MisterE said:

> I don't bother assuming he is one of 0.0000000000000000001% of people who
> don't use ASCII character set for raw chars in c.

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.

-- 
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

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:v7mdnQNQLb9E8SPanZ2dnUVZ8vKdnZ2d@bt.com...
> MAx said:
>
> <snip>
>
>> Hey,
>>    Thanks guys, got the code to work. MisterE's solution did the
>> trick. Thanks man.
>
>
> Unfortunately, there are circumstances in which that code *won't* do the
> trick. Presumably you have investigated these circumstances and determined
> that they will never apply to your code's user base?

MisterE has already indicated what he thinks the probability of that is:
something less than one person in the world (was it one trillionth of a
person?) having such a system. Well I wouldn't go that far myself..

MAx was talking about a board, which either gets distributed with the code,
or the customers have the same model.

But, you might be right, maybe in Europe they like keying in hex numbers 
with accents (0001fbc�). That wouldn't work.

--
Bart

On Feb 21, 10:43 pm, vipps...@gmail.com wrote:
>
> What makes you think 'A'..'F' (and lowercase) are indeed sequential?

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

Richard wrote:
) Unfortunately, there are circumstances in which that code *won't* do the 
) trick. Presumably you have investigated these circumstances and determined 
) that they will never apply to your code's user base?

For the record, EBCDIC has A..F in sequential order, (and a..f as well).


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

On Feb 22, 2:55 pm, Old Wolf <oldw...@inspire.net.nz> wrote:
> On Feb 21, 10:43 pm, vipps...@gmail.com wrote:
>
>
>
> > What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>
> Because they were/are sequential on every single
> system that ever had a C compiler?
Let us assume you are correct here, what does that guarantee about the
future?
The standard only mentions '0'..'9' to be sequential.

In article <8f9482d4-5c87-4624-ab19-1129e304cabd@b29g2000hsa.googlegroups.com>,
 <vippstar@gmail.com> wrote:

>> > What makes you think 'A'..'F' (and lowercase) are indeed sequential?

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

>Let us assume you are correct here, what does that guarantee about the
>future?

That the chance of your program being used on a computer with a
character set with non-sequential A-F is less than, say, the chance of
the computer being eaten by beetles?

-- Richard
-- 
:wq

Old Wolf wrote, On 22/02/08 12:55:
> On Feb 21, 10:43 pm, vipps...@gmail.com wrote:
>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> 
> 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.lang.c/browse_thread/thread/2070e61dda32870f/61a1b727af34b029?lnk=st&q=ebcdic+hex+group%3Acomp.lang.c#61a1b727af34b029
-- 
Flash Gordon

Flash wrote:
) Are you claiming there were no C compilers for any of the hardware that 
) uses EBCDIC?
) http://groups.google.com/group/comp.lang.c/browse_thread/thread/2070e61dda32870f/61a1b727af34b029?lnk=st&q=ebcdic+hex+group%3Acomp.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

On Feb 22, 3:47 pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
> Old Wolf wrote, On 22/02/08 12:55:
>
> > On Feb 21, 10:43 pm, vipps...@gmail.com wrote:
> >> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>
> > 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?
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.

Flash Gordon <spam@flash-gordon.me.uk> writes:

> Old Wolf wrote, On 22/02/08 12:55:
>> On Feb 21, 10:43 pm, vipps...@gmail.com wrote:
>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>>
>> 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.lang.c/browse_thread/thread/2070e61dda32870f/61a1b727af34b029?lnk=st&q=ebcdic+hex+group%3Acomp.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.

-- 
Ben.

In article <ed0395xaos.ln2@news.flash-gordon.me.uk>,
Flash Gordon  <spam@flash-gordon.me.uk> wrote:

>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?

>> 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?

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

-- Richard
-- 
:wq

Richard Heathfield wrote:
> MisterE said:
> 
>> I don't bother assuming he is one of 0.0000000000000000001% of
>> people who don't use ASCII character set for raw chars in c.
> 
> 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Old Wolf wrote:
> vipps...@gmail.com wrote:
> 
>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> 
> 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Ben Bacarisse wrote:
> 
.... 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

"Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message 
news:fpmor7$25da$2@pc-news.cogsci.ed.ac.uk...
> In article <ed0395xaos.ln2@news.flash-gordon.me.uk>,
> Flash Gordon  <spam@flash-gordon.me.uk> wrote:
>
>>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>
>>> 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?
>
> The gaps in EBCDIC are between I and J, and R and S.

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.

--
Bart 

Bartc wrote:
> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote:
>
.... snip ...
>>
>> The gaps in EBCDIC are between I and J, and R and S.
> 
> 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

"Bartc" <bc@freeuk.com> writes:

> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message 

> > The gaps in EBCDIC are between I and J, and R and S.
> 
> 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,

-- 
Jean-Marc

In article <47BF195F.4783FB87@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:

>Ben Bacarisse wrote:

>> 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.

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
-- 
:wq

In article <I0Gvj.11656$XI.4140@text.news.virginmedia.com>,
Bartc <bc@freeuk.com> wrote:

>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
-- 
:wq

Richard Tobin wrote, On 22/02/08 15:13:
> In article <ed0395xaos.ln2@news.flash-gordon.me.uk>,
> Flash Gordon  <spam@flash-gordon.me.uk> wrote:
> 
>>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
> 
>>> 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?
> 
> The gaps in EBCDIC are between I and J, and R and S.

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

In article <47BF1481.C6E21BED@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:

>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?

>> 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.

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

-- Richard
-- 
:wq

Ben Bacarisse wrote, On 22/02/08 15:11:
> Flash Gordon <spam@flash-gordon.me.uk> writes:

<snip>

>> http://groups.google.com/group/comp.lang.c/browse_thread/thread/2070e61dda32870f/61a1b727af34b029?lnk=st&q=ebcdic+hex+group%3Acomp.lang.c#61a1b727af34b029
> 
> EBCDIC had 'a' to 'f' and 'A' to 'F' sequential, as that post states.

Oops, I must have miss-read it.
-- 
Flash Gordon

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:47BF311E.77C2C132@yahoo.com...
> Bartc wrote:
>> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote:
>>
> ... snip ...
>>>
>>> The gaps in EBCDIC are between I and J, and R and S.
>>
>> 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.

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

--
Bart 

Bartc wrote:
> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message 
> news:fpmor7$25da$2@pc-news.cogsci.ed.ac.uk...
>> In article <ed0395xaos.ln2@news.flash-gordon.me.uk>,
>> Flash Gordon  <spam@flash-gordon.me.uk> wrote:
>>
>>>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>>>> 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?
>> The gaps in EBCDIC are between I and J, and R and S.
> 
> 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.

-- 
Joe Wright
"Everything should be made as simple as possible, but not simpler."
                     --- Albert Einstein ---

On Fri, 22 Feb 2008 16:45:26 -0600, Bartc wrote
(in article <agIvj.11745$XI.11601@text.news.virginmedia.com>):

> 
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message 
> news:47BF311E.77C2C132@yahoo.com...
>> Bartc wrote:
>>> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote:
>>> 
>> ... snip ...
>>>> 
>>>> The gaps in EBCDIC are between I and J, and R and S.
>>> 
>>> 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.
> 
> 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.



-- 
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those 
 who have not got it."  - George Bernard Shaw

Richard Tobin wrote:
> CBFalconer  <cbfalconer@maineline.net> wrote:
>> Ben Bacarisse wrote:
> 
>>> 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;
>>  }
>
.... 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Richard Tobin wrote:
> CBFalconer  <cbfalconer@maineline.net> wrote:
> 
>>>> What makes you think 'A'..'F' (and lowercase) are indeed
>>>> sequential?
> 
>>> 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.
> 
> 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

On Feb 22, 10:52 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <47BF195F.4783F...@yahoo.com>,
>
> CBFalconer  <cbfalco...@maineline.net> wrote:
> >Ben Bacarisse wrote:
> >> 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.
>
> 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.

On Fri, 22 Feb 2008 20:09:58 -0500, CBFalconer wrote:
> Richard Tobin wrote:
>> CBFalconer  <cbfalconer@maineline.net> wrote:
>>>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>> 
>>>> 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.
>> 
>> 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.

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'.

Harald van Dijk <truedfx@gmail.com> writes:

> On Fri, 22 Feb 2008 20:09:58 -0500, CBFalconer wrote:
>> Richard Tobin wrote:
>>> CBFalconer  <cbfalconer@maineline.net> wrote:
>>>>>> What makes you think 'A'..'F' (and lowercase) are indeed sequential?
>>> 
>>>>> 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.
>>> 
>>> 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.
>
> 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).

-- 
Ben.

Willem wrote:
> Flash wrote:
>
>> Are you claiming there were no C compilers for any of the
>> hardware that uses EBCDIC?
>
.... 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?

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

On Sat, 23 Feb 2008 13:17:05 +0000, Ben Bacarisse wrote:
> Harald van Dijk <truedfx@gmail.com> writes:
>> [...] 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.

"Joe Wright" <joewwright@comcast.net> wrote in message 
news:x82dnSszMOcuwCLanZ2dnUVZ_remnZ2d@comcast.com...
> Bartc wrote:
>> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message 
>> news:fpmor7$25da$2@pc-news.cogsci.ed.ac.uk...

>>> The gaps in EBCDIC are between I and J, and R and S.
>>
>> Why would whoever put together EBCDIC encoding, put big holes in it like 
>> that?

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

....
> 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.

--
Bart