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

On Monday 21 of January 2013, Stephan Bergmann wrote:
> On 01/21/2013 06:05 PM, Lubos Lunak wrote:
> > On Monday 21 of January 2013, Stephan Bergmann wrote:
> > > 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.

 I did not think of that. It's probably still rather unlikely, but at least 
realistically possible. I think the simplest solution is just adding another 
valueOf helper that handles unsigned 64bit integer.

-- 
 Lubos Lunak
 l.lunak@suse.cz