Add CPLAtoi function

[Mateusz Łoskot]

This report is a proposal for adding new functions to the CPL port library:
- CPLAtoi
- CPLAtol

The idea is to implement these functions using C function strtol().
The strtol() function is much safer than atoi() because it provides some level of diagnostics (LONG_MAX and LONG_MIN values are returned if input value is out of range, and the errno is set to ERANGE).
When using atoi(), if a value can not be represented as integral type, it results in Undefined Behavior without any chance to detect erroneous state.

Replacing atoi() with strtol() is also suggested by POSIX:

"The atoi() function is subsumed by strtol() but is retained because it is used extensively in existing code."

p.s. Andrey, I've taken some liberty to add you to CC because I think my idea is related to your CPLAtof() function, so perhaps you're interested in this subject.

[warmerdam]

I can't honestly imagine many places where I want to analyse the results of 
an atoi() call to see if they failed and why.  So I'm not too excited about 
this concept. 

I would like to add a CPLAtoIntBig() or similar which returns a GIntBig.

I would note we already have CPLScanUIntBig().  Perhaps it would be
sufficient to add a CPLScanIntBig() for signed integers.  The ackward thing
about the Scan functions is that you have to supply a maximum length. 

[Mateusz Łoskot]

I understand.
The idea behind the proposed function is not to check if atoi() failed or not in terms of data consistency, but the idea is to keep program state unaffected with undefined behaviour.

[Mateusz Łoskot]

The idea has been dropped.

[dron]

I would like to add that atoi() as well as other functions for parsing integers is locale dependent. It may take in account thousand separators. For example, in en_US locale comma is thousand separator, so "1,000,000" will be read as "1000000", not as "1". POSIX does not have any rules on that and declares locale support in these functions as implementation dependent. Glibc manual states:

"All the functions mentioned in this section so far do not handle
alternative representations of characters as described in the locale
data.  Some locales specify thousands separator and the way they have to
be used which can help to make large numbers more readable.  To read   
such numbers one has to use the `scanf' functions with the `'' flag."

So glibc does not honor locale in atoi() functions, but there could be libc implementations that do. I do not want to reopen this bug and suggest to add our own strtol()/atoi() implementations because I never seen such libc's. I am adding this note just for record: in theory it is possible that integer parsing is locale dependent, so we can expect bugs here.

Best regards,
Andrey