Ugly verbose pseudo code:
1) RET := Fisme(pArr)
2) if (RET is false) print-assert-line-and-abort
3) RET := "Non memory in array normalization" (This always evaluates
to 'true', since RET conatins a non null pointer)
4) if (RET is false) print-assert-line-and-abort (Never occurs)
The reason the string is in there is simply so that it will be printed
when the assert fails.
Assuming that ASSERT is similar to the assert macro defined in <assert.h>...
And assuming that 782 is the line number and not actually part of the code...
Fisme(pArr) is tested first, and if it's false the && short-circuits yielding
a false result, and an assertion failure has occurred.
if Fisme(pArr) is true, the string literal is evaluated next. The value of a
string literal is a pointer to the first character in the string. Since it's
a pointer, and it's not a null pointer, it has The Truthiness. Its value in
true/false context is true. true&&true is true, so the assertion as a whole
is true. Nothing happens and the program moves on to whatever's after the
ASSERT.
Add it all up and the effect is the same as
ASSERT (Fisme(pArr));
except for what gets printed when a failure occurs.
When an assertion fails, the text of the asserted expression is printed
exactly as it appears in the source code. So instead of getting a message
like:
foo.c:782: Fisme(pArr)
Aborted (core dumped)
you'll get something more like:
foo.c:782: Fisme(pArr) && "Non memory in array normalization"
Aborted (core dumped)
The string literal is there to make the error message slightly more
meaningful for the poor user who runs into it.
--
Alan Curry
>782 ASSERT (Fisme(pArr) && "Non memory in array normalization");
The token ASSERT is not a token defined by the C standard. Chances
are it is a macro defined somewhere in the code you quoted it from. We
will need to see the definition of that macro to answer the question.
In the future, please include the question in the body of your
message.
--
Remove del for email
#define ASSERT(cond) \
do { if (!(cond)) { fputs(#cond, stderr); abort(); } } while (0)
(untested)
DES
--
Dag-Erling Smørgrav - d...@des.no