AFAOS and encodings

[Georg]

is MOS strtolong enhanced that strtolong support too hex values ?

Yes.

Was that a good idea considering that autodocs say "Converts decimal string into LONG value."?

[Georg]

It automagically gave hex support for ReadArgs /N, too, so yes I consider it a good move.

Also, to specify a hex number you need a identifier before such number, thus I can't possibly see any disadvantages in it either.

Backwards compatibility. If you have a function which takes an input string and splits it into int_number and string_remainder then a input string "0x10Hello" would give

0 x10Hello

in the old AOS style implementation (not accepting hex), but
would give

16 Hello in the new MOS style implementation (accepting hex).


Okay, I would probably (have) to think much harder for an example which makes some more (any) sense, but OTOH how likely do you think it is that a similiar enhancement is ever done for clib/atoi() and why.

[Georg]

Piru wrote:

Considering the AROS StrToLong() isn't AmigaOS compatible either, that is a bit silly argument IMO.

Well, if so (which is very likely after a quick look at the source: for example the space/tab check should be in a loop I guess), it's because of buggy implementation not intended implementation.

Never.

And why?

[Georg]

bernd_afa wrote:

Do you have MOS source with stringtolong ?
I do it in a separate command.

No, we only have DOS sources from 2001 or 2002 which did not yet have hex support in. It's not something hard to implement but I would rather change ftmanager to use strtol() instead. Because for running ftmanager under AOS using StrToLong() would only work if you patch it to work like MOS.

[Georg]

Piru wrote:

The particular change was made in 2002. Georg himself had access to the source code at that time.

cvs access I had did not include dos sources. DOS sources from 2001 or 2002 were sent as archive by Emm (initial plan was to have final thing compilable for both AROS and MOS from same source (reason for added AROS_DOS_COMPATIBLE) but at end Emm/MOS coders did not have enough time and/or possibility to test)).