Re: [PUSHED] Create OUString and OString number(*) methods.

On 01/21/2013 06:05 PM, Lubos Lunak wrote:
> On Monday 21 of January 2013, Stephan Bergmann wrote:
> > On 01/18/2013 05:20 PM, Luboš Luňák (via Code Review) wrote:
> > > assert( ll <= SAL_MAX_INT64 ); // valueOfInt64 may not be able to handle
> > > the highest bit
> >
> > in the various number() function definitions make me wonder.  That
> > implies that clients of those functions need to ensure to call them with
> > small-enough arguments.  Is that what we want?
>
>   I think "small-enough" gives the wrong idea, it should be rather,
> say, "not-insanely-large" arguments or so :). And despite the smiley, I'm
> actually serious. This can trigger only when needing the topmost unsigned bit
> of 64bit value, which is a 20 digit decimal number, and more importantly
> those are values at the very limit of the supported integer range - there's
> nothing larger than long long.
>
>   So even if there will be a legitimate case when unsigned long long will be
> needed for the extra bit (which is pretty unlikely already), a lot of care
> will be needed to handle it correctly (e.g. involving anything signed will be
> potential trouble). That'll make this problem just a little bit more of
> trouble.
>
> > While the gotcha of printing a large unsigned value as a negative value
> > thanks to calling rtl_ustr_valueOfInt64 internally can be a problem in
> > some call sites, others might be fine with producing just some sort of
> > informative value and won't mind generating negative output.  If we
> > would want to force the latter into using explicit casts to sal_Int64
> > (in case they don't do already anyway), wouldn't it be better to make
> > the relevant large unsigned overloads "= delete"?
>
>   That would mean blocking out all the values of the type, not just the
> problematic ones. Given that a number of system typedefs are internally
> unsigned integers despite all the signed vs unsigned trouble this causes,
> usage of the type is much more likely than usage of a problematic value of
> the type, so IMO it makes more sense to cater to realistic usage rathen than
> handle more problematic but next to impossible scenarios.

I was thinking about scenarios like passing a sal_uIntPtr to 
rtl::OUString::number.  If that sal_uIntPtr is derived from a pointer in 
the obvious way, it could, depending on platform, be highly likely that 
it triggers the assert.

Stephan