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.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
