Hi,

Considering usage of "assert" , I want a more informative output from
it. Consider:

// Code:
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{ int b=3;
int a=2;

assert(a==b);

return 0;
}

Output of gcc:
verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
Aborted (core dumped)

Output of clang:
verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
`a==b' failed.
Aborted (core dumped)

I want more details in compiler's output , like for example:
a is 2
b is 3

Supersedes: <assert-20220219084524@ram.dialup.fu-berlin.de>
[changed one "assert_equal" to "ASSERT_EQUAL"]

Mehdi Amini <atorrses@gmail.com> writes:
>I want more details in compiler's output , like for example:
>a is 2
>b is 3

#include <stdio.h>

#ifdef NDEBUG
#define ASSERT_EQUAL(a,b) ((void)0)
#else
#define ASSERT_FORMAT(x) _Generic(x,int:"%d",default:"?")
#define ASSERT_PRINT(x) \
{fprintf(stderr,#x " is ");\
fprintf(stderr,ASSERT_FORMAT(x),x);\
fprintf(stderr,"\n");}
#define ASSERT_FAILURE(a,b) {ASSERT_PRINT(a);ASSERT_PRINT(b);}
#define ASSERT_EQUAL_VARS(a,b) {if(!(a==b))ASSERT_FAILURE(a,b)}while(0)
#endif

int main( void )
{ int const a = 2;
int const b = 3;
ASSERT_EQUAL_VARS(a,b); }

Supersedes: <assert-20220219084844@ram.dialup.fu-berlin.de>
[changed one "ASSERT_EQUAL" to "ASSERT_EQUAL_VARS"]

Supersedes: <assert-20220219084524@ram.dialup.fu-berlin.de>
[changed one "assert_equal" to "ASSERT_EQUAL"]

Mehdi Amini <atorrses@gmail.com> writes:
>I want more details in compiler's output , like for example:
>a is 2
>b is 3

#include <stdio.h>

#ifdef NDEBUG
#define ASSERT_EQUAL_VARS(a,b) ((void)0)
#else
#define ASSERT_FORMAT(x) _Generic(x,int:"%d",default:"?")
#define ASSERT_PRINT(x) \
{fprintf(stderr,#x " is ");\
fprintf(stderr,ASSERT_FORMAT(x),x);\
fprintf(stderr,"\n");}
#define ASSERT_FAILURE(a,b) {ASSERT_PRINT(a);ASSERT_PRINT(b);}
#define ASSERT_EQUAL_VARS(a,b) {if(!(a==b))ASSERT_FAILURE(a,b)}while(0)
#endif

int main( void )
{ int const a = 2;
int const b = 3;
ASSERT_EQUAL_VARS(a,b); }

On Saturday, 19 February 2022 at 06:44:18 UTC, Mehdi Amini Valashani son of Bahram wrote:
> Hi,
>
> Considering usage of "assert" , I want a more informative output from
> it. Consider:
>
> // Code:
> #include <assert.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> int b=3;
> int a=2;
>
> assert(a==b);
>
> return 0;
> }
>
> Output of gcc:
> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
> Aborted (core dumped)
>
> Output of clang:
> verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
> `a==b' failed.
> Aborted (core dumped)
>
> I want more details in compiler's output , like for example:
> a is 2
> b is 3
>
The onyl way to do this would be to patch the compiler itself. You can
easily write your own assert() macro, but the expression a == b just resolves
to either 1 or 0 within the macro. You can stringify it, but you can't link
the string component "a" to the variable a.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Saturday, 19 February 2022 at 06:44:18 UTC, Mehdi Amini Valashani son of Bahram wrote:
>> Hi,
>>
>> Considering usage of "assert" , I want a more informative output from
>> it. Consider:
>>
>> // Code:
>> #include <assert.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> int b=3;
>> int a=2;
>>
>> assert(a==b);
>>
>> return 0;
>> }
>>
>> Output of gcc:
>> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
>> Aborted (core dumped)
>>
>> Output of clang:
>> verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
>> `a==b' failed.
>> Aborted (core dumped)
>>
>> I want more details in compiler's output , like for example:
>> a is 2
>> b is 3
>>
>The onyl way to do this would be to patch the compiler itself. You can
>easily write your own assert() macro, but the expression a == b just resolves
>to either 1 or 0 within the macro. You can stringify it, but you can't link
>the string component "a" to the variable a.

void my_assert_msg(const char* filep, int lineno,
const char* conditionp, const char* fmtp="", ...);

#define MY_ASSERT(condition, ...) \
do if (unlikely(!(condition))) { \
my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
abort(); \
} while(0)

#ifndef ASSERT
# define ASSERT MY_ASSERT
#endif

Am 19.02.2022 um 17:00 schrieb Scott Lurndal:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Saturday, 19 February 2022 at 06:44:18 UTC, Mehdi Amini Valashani son of Bahram wrote:
>>> Hi,
>>>
>>> Considering usage of "assert" , I want a more informative output from
>>> it. Consider:
>>>
>>> // Code:
>>> #include <assert.h>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void)
>>> {
>>> int b=3;
>>> int a=2;
>>>
>>> assert(a==b);
>>>
>>> return 0;
>>> }
>>>
>>> Output of gcc:
>>> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
>>> Aborted (core dumped)
>>>
>>> Output of clang:
>>> verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
>>> `a==b' failed.
>>> Aborted (core dumped)
>>>
>>> I want more details in compiler's output , like for example:
>>> a is 2
>>> b is 3
>>>
>> The onyl way to do this would be to patch the compiler itself. You can
>> easily write your own assert() macro, but the expression a == b just resolves
>> to either 1 or 0 within the macro. You can stringify it, but you can't link
>> the string component "a" to the variable a.
>
> void my_assert_msg(const char* filep, int lineno,
> const char* conditionp, const char* fmtp="", ...);
>
> #define MY_ASSERT(condition, ...) \
> do if (unlikely(!(condition))) { \

Lol, "unlikely", if the performance of debugging-code would be an issue.

> my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
> abort(); \
> } while(0)
>
> #ifndef ASSERT
> # define ASSERT MY_ASSERT
> #endif

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.02.2022 um 17:00 schrieb Scott Lurndal:

>>
>> void my_assert_msg(const char* filep, int lineno,
>> const char* conditionp, const char* fmtp="", ...);
>>
>> #define MY_ASSERT(condition, ...) \
>> do if (unlikely(!(condition))) { \
>
>Lol, "unlikely", if the performance of debugging-code would be an issue.

Indeed, it's quite important from a performance standpoint
to help the compiler generate branch-predictor friendly code. Not
quite sure why you think it is funny.

Am 19.02.2022 um 17:38 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 19.02.2022 um 17:00 schrieb Scott Lurndal:
>
>>>
>>> void my_assert_msg(const char* filep, int lineno,
>>> const char* conditionp, const char* fmtp="", ...);
>>>
>>> #define MY_ASSERT(condition, ...) \
>>> do if (unlikely(!(condition))) { \
>>
>> Lol, "unlikely", if the performance of debugging-code would be an issue.
>
> Indeed, it's quite important from a performance standpoint
> to help the compiler generate branch-predictor friendly code.

No one cares for the performance of debugging-code. And when
you compile a perfomant release the debugging-code is stripped.

On 2/19/22 19:30, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Saturday, 19 February 2022 at 06:44:18 UTC, Mehdi Amini Valashani son of Bahram wrote:
>>> Hi,
>>>
>>> Considering usage of "assert" , I want a more informative output from
>>> it. Consider:
>>>
>>> // Code:
>>> #include <assert.h>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void)
>>> {
>>> int b=3;
>>> int a=2;
>>>
>>> assert(a==b);
>>>
>>> return 0;
>>> }
>>>
>>> Output of gcc:
>>> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
>>> Aborted (core dumped)
>>>
>>> Output of clang:
>>> verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
>>> `a==b' failed.
>>> Aborted (core dumped)
>>>
>>> I want more details in compiler's output , like for example:
>>> a is 2
>>> b is 3
>>>
>> The onyl way to do this would be to patch the compiler itself. You can
>> easily write your own assert() macro, but the expression a == b just resolves
>> to either 1 or 0 within the macro. You can stringify it, but you can't link
>> the string component "a" to the variable a.
>
> void my_assert_msg(const char* filep, int lineno,
> const char* conditionp, const char* fmtp="", ...);
>
> #define MY_ASSERT(condition, ...) \
> do if (unlikely(!(condition))) { \
> my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
> abort(); \
> } while(0)
>
> #ifndef ASSERT
> # define ASSERT MY_ASSERT
> #endif

Complete code :
#include <stdio.h>
#include <stdlib.h>

void my_assert_msg(const char* filep, int lineno,
const char* conditionp, const char* fmtp="", ...);

#define MY_ASSERT(condition, ...) \
do if (unlikely(!(condition))) { \
my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
abort(); \
} while(0)

#ifndef ASSERT
# define ASSERT MY_ASSERT
#endif

int main(void)
{ int a,b;
a=2;
b=3;

MY_ASSERT(a==b);

return 0;
}

I get this :

$ clang -Wall -Wextra -pedantic -std=c11 custom_assert2.c -o
custom_assert2.out
custom_assert2.c:6:61: error: C does not support default arguments
const char* conditionp, const char* fmtp="", ...);
^~~
custom_assert2.c:10:53: warning: token pasting of ',' and __VA_ARGS__ is
a GNU extension [-Wgnu-zero-variadic-macro-arguments]
my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
^
custom_assert2.c:24:5: warning: implicit declaration of function
'unlikely' is invalid in C99 [-Wimplicit-function-declaration]
MY_ASSERT(a==b);
^
custom_assert2.c:9:11: note: expanded from macro 'MY_ASSERT'
do if (unlikely(!(condition))) { \
^
2 warnings and 1 error generated.

On 2/19/22 11:26, Stefan Ram wrote:
> Supersedes: <assert-20220219084844@ram.dialup.fu-berlin.de>
> [changed one "ASSERT_EQUAL" to "ASSERT_EQUAL_VARS"]
>
> Supersedes: <assert-20220219084524@ram.dialup.fu-berlin.de>
> [changed one "assert_equal" to "ASSERT_EQUAL"]
>
> Mehdi Amini <atorrses@gmail.com> writes:
>> I want more details in compiler's output , like for example:
>> a is 2
>> b is 3
>
> #include <stdio.h>
>
> #ifdef NDEBUG
> #define ASSERT_EQUAL_VARS(a,b) ((void)0)
> #else
> #define ASSERT_FORMAT(x) _Generic(x,int:"%d",default:"?")
> #define ASSERT_PRINT(x) \
> {fprintf(stderr,#x " is ");\
> fprintf(stderr,ASSERT_FORMAT(x),x);\
> fprintf(stderr,"\n");}
> #define ASSERT_FAILURE(a,b) {ASSERT_PRINT(a);ASSERT_PRINT(b);}
> #define ASSERT_EQUAL_VARS(a,b) {if(!(a==b))ASSERT_FAILURE(a,b)}while(0)
> #endif
>
> int main( void )
> { int const a = 2;
> int const b = 3;
> ASSERT_EQUAL_VARS(a,b); }
>
>

That is just one example. Another example from
https://en.cppreference.com/w/c/error/assert:

#include <stdio.h>
// uncomment to disable assert()
// #define NDEBUG
#include <assert.h>
#include <math.h>

int main(void)
{ double x = -1.0;
assert(x >= 0.0);
printf("sqrt(x) = %f\n", sqrt(x));

return 0;
}

output with NDEBUG not defined:
a.out: main.cpp:10: main: Assertion `x >= 0.0' failed.

IMHO worth mentioning is:
x is -1.0

Mehdi Amini <atorrses@gmail.com> writes:
>On 2/19/22 11:26, Stefan Ram wrote:
>> #ifdef NDEBUG
>That is just one example. Another example from

What I wrote was also just one example.

On Saturday, 19 February 2022 at 21:06:53 UTC+2, Bonita Montero wrote:
> Am 19.02.2022 um 17:38 schrieb Scott Lurndal:
> > Bonita Montero <Bonita....@gmail.com> writes:
> >> Am 19.02.2022 um 17:00 schrieb Scott Lurndal:
> >
> >>>
> >>> void my_assert_msg(const char* filep, int lineno,
> >>> const char* conditionp, const char* fmtp="", ...);
> >>>
> >>> #define MY_ASSERT(condition, ...) \
> >>> do if (unlikely(!(condition))) { \
> >>
> >> Lol, "unlikely", if the performance of debugging-code would be an issue.
> >
> > Indeed, it's quite important from a performance standpoint
> > to help the compiler generate branch-predictor friendly code.
>
> No one cares for the performance of debugging-code. And when
> you compile a perfomant release the debugging-code is stripped.

No one cares about your speed of giving wrong answers.
Assertion failure indicates an arbitrary and unknowable amount of
brokenness in the program state caused by programming errors.
When the assertion is compiled out then that state can be used to
do maximal damage to the runner of program. When the assertion
is not compiled out then the outcome can be used for denial of
service to the runner of program. That is usually milder. Also
assertion failures lot easier to notice, figure out and to fix. So
programmers often choose to define NDEBUG only for translation
units about what profiling indicates that it is worth doing for
performance. And such are often under 5% of code-base.

Mehdi Amini <atorrses@gmail.com> writes:

It seems you want something like this:

#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>

void my_assert(int cond, const char *fmt, ...)
{
if (!cond) {
va_list al;
va_start(al, fmt);
vfprintf(stderr, fmt, al);
va_end(al);
exit(EXIT_FAILURE);
}
}

#define MY_ASSERT(cond, fmt, ...) \
my_assert(cond, "*** \"%s\" line %d: " fmt, \
__FILE__, __LINE__, __VA_ARGS__)

int main(void)
{
int a = 41, b = 42;
MY_ASSERT(a == b, "%d != %d as required.\n", a, b);
}

Note that this uses string concatenation to build the format, but you
can write a version that will work with non-literal formats.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> void my_assert(int cond, const char *fmt, ...)
> {
> if (!cond) {
> va_list al;
> va_start(al, fmt);
> vfprintf(stderr, fmt, al);
> va_end(al);
> exit(EXIT_FAILURE);
> }
> }
>
> #define MY_ASSERT(cond, fmt, ...) \
> my_assert(cond, "*** \"%s\" line %d: " fmt, \
> __FILE__, __LINE__, __VA_ARGS__)

A slight improvement would be to include the condition as a string:

#define MY_ASSERT(cond, fmt, ...) \
my_assert(cond, #cond " in \"%s\" line %d is false. " fmt, \
__FILE__, __LINE__, __VA_ARGS__)
> int main(void)
> {
> int a = 41, b = 42;
> MY_ASSERT(a == b, "%d != %d as required.\n", a, b);

And, frankly, that could be worded better!

> }

--
Ben.

Am 20.02.2022 um 12:23 schrieb Öö Tiib:
> On Saturday, 19 February 2022 at 21:06:53 UTC+2, Bonita Montero wrote:
>> Am 19.02.2022 um 17:38 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita....@gmail.com> writes:
>>>> Am 19.02.2022 um 17:00 schrieb Scott Lurndal:
>>>
>>>>>
>>>>> void my_assert_msg(const char* filep, int lineno,
>>>>> const char* conditionp, const char* fmtp="", ...);
>>>>>
>>>>> #define MY_ASSERT(condition, ...) \
>>>>> do if (unlikely(!(condition))) { \
>>>>
>>>> Lol, "unlikely", if the performance of debugging-code would be an issue.
>>>
>>> Indeed, it's quite important from a performance standpoint
>>> to help the compiler generate branch-predictor friendly code.
>>
>> No one cares for the performance of debugging-code. And when
>> you compile a perfomant release the debugging-code is stripped.
>
> No one cares about your speed of giving wrong answers.
> Assertion failure indicates an arbitrary and unknowable amount of
> brokenness in the program state caused by programming errors.
> When the assertion is compiled out then that state can be used to
> do maximal damage to the runner of program. When the assertion
> is not compiled out then the outcome can be used for denial of
> service to the runner of program. That is usually milder. Also
> assertion failures lot easier to notice, figure out and to fix.
> So programmers often choose to define NDEBUG only for translation
> units about what profiling indicates that it is worth doing for
> performance. And such are often under 5% of code-base.

The performance of debugging-code doesn't count, so Scott's
unlikely is simply silly.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 20.02.2022 um 12:23 schrieb Öö Tiib:

>> No one cares about your speed of giving wrong answers.
>> Assertion failure indicates an arbitrary and unknowable amount of
>> brokenness in the program state caused by programming errors.
>> When the assertion is compiled out then that state can be used to
>> do maximal damage to the runner of program. When the assertion
>> is not compiled out then the outcome can be used for denial of
>> service to the runner of program. That is usually milder. Also
>> assertion failures lot easier to notice, figure out and to fix.
>> So programmers often choose to define NDEBUG only for translation
>> units about what profiling indicates that it is worth doing for
>> performance. And such are often under 5% of code-base.
>
>The performance of debugging-code doesn't count, so Scott's
>unlikely is simply silly.
>

If the invocation of the MY_ASSERT macro is in a performance
sensitive code path, then of course the performance of the
condition test is important.

As Tiib pointed out, assertions aren't removed from production
code in the real world.

Now personally (and professionally), one generally can find
alternate mechanisms to deal with such failures[*] rather than
blindly terminating the application and thus such asserts are rare.

[*] e.g. an API can return an EINVAL error.

Mehdi Amini <atorrses@gmail.com> writes:
>On 2/19/22 19:30, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On Saturday, 19 February 2022 at 06:44:18 UTC, Mehdi Amini Valashani son of Bahram wrote:
>>>> Hi,
>>>>
>>>> Considering usage of "assert" , I want a more informative output from
>>>> it. Consider:
>>>>
>>>> // Code:
>>>> #include <assert.h>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>>
>>>> int main(void)
>>>> {
>>>> int b=3;
>>>> int a=2;
>>>>
>>>> assert(a==b);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> Output of gcc:
>>>> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
>>>> Aborted (core dumped)
>>>>
>>>> Output of clang:
>>>> verbose_assert.out: verbose_assert.c:10: int main(void): Assertion
>>>> `a==b' failed.
>>>> Aborted (core dumped)
>>>>
>>>> I want more details in compiler's output , like for example:
>>>> a is 2
>>>> b is 3
>>>>
>>> The onyl way to do this would be to patch the compiler itself. You can
>>> easily write your own assert() macro, but the expression a == b just resolves
>>> to either 1 or 0 within the macro. You can stringify it, but you can't link
>>> the string component "a" to the variable a.
>>
>> void my_assert_msg(const char* filep, int lineno,
>> const char* conditionp, const char* fmtp="", ...);
>>
>> #define MY_ASSERT(condition, ...) \
>> do if (unlikely(!(condition))) { \
>> my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
>> abort(); \
>> } while(0)
>>
>> #ifndef ASSERT
>> # define ASSERT MY_ASSERT
>> #endif
>
>Complete code :
>#include <stdio.h>
>#include <stdlib.h>
>
>void my_assert_msg(const char* filep, int lineno,
> const char* conditionp, const char* fmtp="", ...);
>
>#define MY_ASSERT(condition, ...) \
> do if (unlikely(!(condition))) { \
> my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
> abort(); \
> } while(0)
>
>#ifndef ASSERT
># define ASSERT MY_ASSERT
>#endif
>
>int main(void)
>{
> int a,b;
> a=2;
> b=3;
>
> MY_ASSERT(a==b);
>
> return 0;
>}
>
>I get this :
>
>$ clang -Wall -Wextra -pedantic -std=c11 custom_assert2.c -o
>custom_assert2.out
>custom_assert2.c:6:61: error: C does not support default arguments
> const char* conditionp, const char* fmtp="", ...);
> ^~~
>custom_assert2.c:10:53: warning: token pasting of ',' and __VA_ARGS__ is
>a GNU extension [-Wgnu-zero-variadic-macro-arguments]
> my_assert_msg(__FILE__,__LINE__, #condition, ## __VA_ARGS__); \
> ^
>custom_assert2.c:24:5: warning: implicit declaration of function
>'unlikely' is invalid in C99 [-Wimplicit-function-declaration]
> MY_ASSERT(a==b);
> ^
>custom_assert2.c:9:11: note: expanded from macro 'MY_ASSERT'
> do if (unlikely(!(condition))) { \
> ^
>2 warnings and 1 error generated.

Apologies.

#define unlikely(x) __builtin_expect(!!(x), 0)

You'll also need to actually implement my_assert_msg. It will
be a good exercise for you.

And it will probably require changes for C (the code posted was for C++
which supports default arguments - go ahead and remove the '=""' from
the function prototype). Hint - use vsnprintf in my_assert_msg.

On 2022-02-20, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 20.02.2022 um 12:23 schrieb Öö Tiib:
>> On Saturday, 19 February 2022 at 21:06:53 UTC+2, Bonita Montero wrote:
>>> Am 19.02.2022 um 17:38 schrieb Scott Lurndal:
>>>> Bonita Montero <Bonita....@gmail.com> writes:
>>>>> Am 19.02.2022 um 17:00 schrieb Scott Lurndal:
>>>>
>>>>>>
>>>>>> void my_assert_msg(const char* filep, int lineno,
>>>>>> const char* conditionp, const char* fmtp="", ...);
>>>>>>
>>>>>> #define MY_ASSERT(condition, ...) \
>>>>>> do if (unlikely(!(condition))) { \
>>>>>
>>>>> Lol, "unlikely", if the performance of debugging-code would be an issue.
>>>>
>>>> Indeed, it's quite important from a performance standpoint
>>>> to help the compiler generate branch-predictor friendly code.
>>>
>>> No one cares for the performance of debugging-code. And when
>>> you compile a perfomant release the debugging-code is stripped.
>>
>> No one cares about your speed of giving wrong answers.
>> Assertion failure indicates an arbitrary and unknowable amount of
>> brokenness in the program state caused by programming errors.
>> When the assertion is compiled out then that state can be used to
>> do maximal damage to the runner of program. When the assertion
>> is not compiled out then the outcome can be used for denial of
>> service to the runner of program. That is usually milder. Also
>> assertion failures lot easier to notice, figure out and to fix.
>> So programmers often choose to define NDEBUG only for translation
>> units about what profiling indicates that it is worth doing for
>> performance. And such are often under 5% of code-base.
>
> The performance of debugging-code doesn't count, so Scott's
> unlikely is simply silly.

In some software projects, there is a practice of leaving assertions
in production code. There may not even be a provided mechanism to
compile them out. ISO C calls the disabling macro NDEBUG, suggesting
"no debugging", but that doesn't mean that even that ISO C macro
necessarily debugging *instrumentation* that is to be removed from the
product, the way oscilloscope or multimeter probes are removed from a
circuit board. "Debugging" can refer to debug *support*. For instance,
like having test points on a circuit board for easier verification,
which are retained in the production board. Assertions don't just
provide debug support, but a predictable, safe(r) mode of failure for
problems that could go entirely undetected (which also makes the
situation easier to debug, as a side effect).

In the software that I'm currently working on at work, the regression
test suite includes test cases that check that certain violations of
contracts produce the assertions.

For each function, those conditions that are required in such a way
that an assertion will be issued if they are not satisfied are
documented as such.

C. A. R Hoare, wrote

"What would we think of a sailing enthusiast who wears his lifejacket
when training on dry land, but takes it off as soon as he goes to sea?",

evidently in "Hints on programming language design", Stanford Artificial
Intelligence Laboratory memo AIM-24, Stanford University technical
report no. STAN-CS-73-403, 1973.

And so, if you have assertion checks in production code, their overhead
may matter in some cases. If some frequently called function contains an
assert check, a hint to the compiler that the failing branch is not
expected to be taken could save some valuable cycles.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Sunday, 20 February 2022 at 16:28:52 UTC, Scott Lurndal wrote:
>
> As Tiib pointed out, assertions aren't removed from production
> code in the real world.
>
When I was a games programmer, we had a console with a CD. We
were allowed two error messages. "Drive door open" and "disk dirty".

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>On 2022-02-20, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 20.02.2022 um 12:23 schrieb Öö Tiib:

>
>And so, if you have assertion checks in production code, their overhead
>may matter in some cases. If some frequently called function contains an
>assert check, a hint to the compiler that the failing branch is not
>expected to be taken could save some valuable cycles.

And, of even more benefit, move the "then" clause in the codestream
to a different cache line, thus improving the icache hit rate by
some small amount.

Am 20.02.2022 um 17:28 schrieb Scott Lurndal:

> If the invocation of the MY_ASSERT macro is in a performance
> sensitive code path, then of course the performance of the
> condition test is important.

Debugging-code hasn't any optimizations anyway
and therefore is never performance-sensitive.

> In some software projects, there is a practice of leaving assertions
> in production code.

To have an INT3 so that the application crashes at the customer ?

On 2/20/22 10:48, Stefan Ram wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
>> On 2/19/22 11:26, Stefan Ram wrote:
>>> #ifdef NDEBUG
>> That is just one example. Another example from
>
> What I wrote was also just one example.
>
>

Sorry I did not explain my question properly. When using "assert" I want
to read the values of it's variables in case of "assert"'s failure.

On 2/20/22 17:06, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>

[...]

>
> A slight improvement would be to include the condition as a string:
>
> #define MY_ASSERT(cond, fmt, ...) \
> my_assert(cond, #cond " in \"%s\" line %d is false. " fmt, \
> __FILE__, __LINE__, __VA_ARGS__)
>> int main(void)
>> {
>> int a = 41, b = 42;
>> MY_ASSERT(a == b, "%d != %d as required.\n", a, b);
>
> And, frankly, that could be worded better!
>
>> }
>

I wanted to add __FUNCTION__ to above code too. Unfortunately this is
not part of c11 standard.

$ gcc -Wall -Wextra -pedantic -std=c11 verbose_assert2.c -o
verbose_assert2.out
verbose_assert2.c: In function ‘main’:
verbose_assert2.c:29:28: warning: ISO C does not support ‘__FUNCTION__’
predefined identifier [-Wpedantic]
29 | __FILE__, __FUNCTION__ , __LINE__, __VA_ARGS__)
| ^~~~~~~~~~~~
verbose_assert2.c:35:8: note: in expansion of macro ‘MY_ASSERT’
35 | MY_ASSERT(a == b, "%d != %d as required.\n", a, b);
| ^~~~~~~~~

Mehdi Amini <atorrses@gmail.com> writes:
[...]
> I wanted to add __FUNCTION__ to above code too. Unfortunately this is
> not part of c11 standard.

It's spelled __func__ .

__FUNCTION__ is non-standard. gcc's documentation says:

'__FUNCTION__' is another name for '__func__', provided for backward
compatibility with old versions of GCC.

Microsoft's implementation defines __FUNCTION__ as a predefined macro.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */