> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Lunes, 24 de Febrero de 2014 3:17
>
> ~1u is the simplest (on my mind) to get 0xFF...FE
Ok, change it. :-)
C.
--
Flow-based real-tim
Now we have the article in english too
http://www.viva64.com/en/b/0235/
On Mon, Feb 24, 2014 at 9:17 AM, Alex Peshkoff wrote:
> On 02/22/14 13:02, Claudio Valderrama C. wrote:
>
3.- This supposedly dangerous definition
const ULONG END_BUCKET = (~0) << 1; is interesting, would
const
On 02/22/14 13:02, Claudio Valderrama C. wrote:
>>> 3.- This supposedly dangerous definition
>>> const ULONG END_BUCKET = (~0) << 1; is interesting, would
>>> const ULONG END_BUCKET = (~0) ^ 1;
>>> do the trick?
>> What's wrong with "(~0u) << 1" that they suggest instead?
> I don't think it's wron
22.02.2014 6:32, Dmitry Yemanov wrote:
> The problem here may be theoretical rather than practical, but it does
> exist. Memcmp is not guaranteed to return 1 / -1, it's only guaranteed
> to return positive / negative. If one day it will start returning
> 100 for "greater-than", we're in trouble
> -Original Message-
> From: Dmitry Yemanov [mailto:firebi...@yandex.ru]
> Sent: Sábado, 22 de Febrero de 2014 1:33
>
> Claudio,
>
> > Nice, although some of them seem to be false alarms. For example,
> > TextType::compare(). The typical result is -1, 0, 1. I
> would prefer to
> > chang
Claudio,
> Nice, although some of them seem to be false alarms. For example,
> TextType::compare(). The typical result is -1, 0, 1. I would prefer to
> change the result to plain int, but it may not be possible (I would have to
> check all places affected).
The problem here may be theoretical rat
> -Original Message-
> From: marius adrian popa [mailto:map...@gmail.com]
> Sent: Viernes, 21 de Febrero de 2014 9:24
>
> Here you can find result of checking Firebird with PVS-Studio
> (in russian).
> http://habrahabr.ru/company/pvs-studio/blog/213423/
>
> via linkedin
> http://www.lin
