Devin Reade <> was heard to say:

> Markus Hoenicka <> wrote:
>> To better deal with your shock: Could you please elaborate what's
>> wrong with atoll()?
> In the particular case of this use in libdbi, I've not looked at the
> code to see to what extent it is an *actual* problem; however as a
> generalization, I would advise against using ato*() functions and instead
> use strto*() functions because the latter provides input error checks
> that the former does not.  For example, if someone provides "073Ah" as
> input (thinking of the old DOS style hex stuff), what do they get?
> atol:   0x49 with no indication that the whole string wasn't parsed
> strtol: 0x3B, with an indication that the "Ah" wasn't parsed (assuming
>         a zero base) or 0x73a with an indication that 'h' wasn't parsed
>         (assuming a base of 16).
> In code inspections, ato*() is something my eye is drawn to as a
> potential source of problems, just as gotos are.  I don't remember if
> ato*() were mentioned in the classic paper
>   "Can't Happen or /*NOT REACHED*/ or Real Programs Drop Core"
> but if not they should have been.

Thanks for elaborating on this. I guess I have incorrectly generalized  
from FreeBSD that ato*() are wrappers around the corresponding  
strto*() functions. If they are indeed separately implemented in other  
OSes, you have a good point in avoiding ato*() functions in libdbi. A  
quick look at the code suggests indeed that there is insufficient  
error checking on the return of the string to number conversions.


Markus Hoenicka
AQ score 38

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers 
libdbi-users mailing list

Reply via email to