On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen <tom.haco...@samsung.com> said:
> On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen <tom.haco...@samsung.com> > > said: > > > >> On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote: > >>> On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen <tom.haco...@samsung.com> > >>> said: > >>> > >>>> On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote: > >>>>> On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen <tom.haco...@samsung.com> > >>>>> said: > >>>>> > >>>>>> On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote: > >>>>>>> On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen > >>>>>>> <tom.haco...@samsung.com> said: > >>>>>>> > >>>>>>>> On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote: > >>>>>>>>> On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen > >>>>>>>>> <tom.haco...@samsung.com> said: > >>>>>>>>> > >>>>>>>>>> Where did you get that on? > >>>>>>>>>> Anyhow, what do you think about changing it to unsigned wchar_t? > >>>>>>>>> > >>>>>>>>> on my pentium-m test machine... unicode val 0 was < 0 and thus > >>>>>>>>> walked below the array. yes. literally a negative. wouldnt that be > >>>>>>>>> wuchar_t or something? as wchar_t .. is a typedef... :) > >>>>>>>>> > >>>>>>>> > >>>>>>>> Hm... Annoying. There's no wuchar_t though. > >>>>>>> > >>>>>>> then we have... a problem... and it requires we check for < 0. :( > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> I think me might be better off casting to unsigned. Damn you people for > >>>>>> not doing all the char type unsigned, wth?! > >>>>> > >>>>> chances are the compiler will produce the exact same code regardless... > >>>>> a cast or what is there now. > >>>>> > >>>> > >>>> Nah, the whole point of the cast is to convert it to unsigned, I'm quite > >>>> certain the compiler is capable of doing that. > >>> > >>> but your casting inside the func to just avoid if (x < 0)... which a > >>> compiler will figure out to be the same as the cast to unsigned... > >>> > >>> > >> > >> The cast will work for unicode values that are greater than the signed > >> limit (less than 0), while the if just fail for them. > > > > there are no unicode values of that magnitude... unicode by definition > > doesnt even get close to using the most significant bit... :) it's by > > definition an invalid code if < 0 (for 32bit signed)... > > > > > > Oh, forgot to mention, I was thinking about boxes where wchar_t is > signed and 16bit. :) There we'll have trouble. > If you got negative values it must mean you've reached big enough > unicode values, so the issue I'm describing is indeed real. on boxes where its 16bit.. we will have problems... because unicode does not fit into 16bit.... we explicitly MUSt have it be a 32bit type in order to have enough space to store the hmmm... 22? bits needed for unicode? quick check... 10ffff is the top unicode value... that means 21bits... so unicode needs 21bits. if we have 16bit wchar_t's we are not able to do unicode. signed or not is irrelevant here. if its 32bit... we don't care :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
