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 peshk...@mail.ru 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
-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-time
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 wrong, I'm asking what's
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: 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
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 rather
-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
change the result
