Thank you all for your feedback to my quite "dirty" ;) posting!
As Mike pointed out 'a'-'z' were not honored, but also blanks in between pairs
of hex digits, which
Rexx allows for.
Rewriting the algorithm a little bit it runs even faster (up to 4.5 times
compared to x2c()):
/* A Rexx hex s
Well, you're missing all of the logic that allows for blanks at the
boundaries and you're also assuming that you have an even number of digits
to convert. If you remove all of the things that x2c() has to account for,
then yes, you can do a faster conversion.
Rick
On Fri, Apr 19, 2019 at 6:51 AM
On 19.04.2019 13:09, Rick McGuire wrote:
> Well, you're missing all of the logic that allows for blanks at the
> boundaries and you're also
> assuming that you have an even number of digits to convert. If you remove all
> of the things that
> x2c() has to account for, then yes, you can do a faste
On 19.04.2019 15:55, Rony G. Flatscher wrote:
> On 19.04.2019 13:09, Rick McGuire wrote:
... cut ...
Sorry, the following error message is correct, the position 6 is correct (had
changed the hex string):
>
> * the hexadecimal string "Ab 0 0 ff 00 ff 00 ff 12" has an illegal
> whitesp
Double-checked the test hex strings and their positions of illegal whitespace
chars, here the native
routine with the corrected position:
int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, char
*data)
{
// check for trailing whitespace
char tmp=(hexData[l
Hi,
looking at ooRexx's implemetation of x2c I find the original code much
easier to understand and to reason about. Instead of hand-tuning an
implementation I'd like to know why the native implementation is slower
than your approach. I'd suspect it's because it's using strchr to validate
each char
