Re: [lmi] strtoul() vs the worlds (was: expand_html() msw64: 'SIZE_MAX <= index' always false)

[Vadim Zeitlin]

On Sun, 24 Mar 2019 21:27:27 +0000 Greg Chicares <address@hidden> wrote:

GC> But why use that C function anyway, instead of std::stringstream?

 Because it's much more efficient and I don't want to pessimize this code
unnecessarily.

GC> Granted, std::string and std::stringstream aren't as good as they
GC> could be if they were redesigned today, but OTOH when I examine:
GC>   /opt/lmi/src/lmi[0]$grep strto *.?pp |less -S
GC> I see your comment here (which I heartily agree with):
GC>   rate_table.cpp:// Helper function wrapping std::strtoull() and hiding its 
peculiarities:

 I admit that I've simply forgotten about strict_parse_number() from
rate_table.cpp, but looking at it now, I don't think it's appropriate for
use in pdf_command_wx.cpp as it's too strict: I see no reason to forbid
leading spaces or even zeroes in the latter, for example.

GC> and great pains are taken in 'numeric_io_*.?pp' to hide those same
GC> peculiarities;

 But it does it again for a slightly different purpose, I think.

 BTW, looking at this code I'm not sure if it ought to test for overflow as
I did in pdf_command_wx.cpp. And if not, why not?

GC> this
GC>   pdf_command_wx.cpp:  auto const index = std::strtoul(s.c_str() + open_pos 
+ 1, &stop, 10);
GC> is the only line that uses any of these functions directly.

 I'm afraid I don't see any better choice here. If anything, it might make
sense to use std::from_chars[1], which is even more efficient than
strtoul() and does have a marginally better API, but I'm not sure about
its implementation state in MinGW version we use.

 Regards,
VZ

[1] https://en.cppreference.com/w/cpp/utility/from_chars