Mehdi Amini <atorrses@gmail.com> writes:

> 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.

(Noted: the macro __func__ is standard.)

The ring is calling for my hat. Some notes follow, below.

File check.h:

#ifndef HAVE_CHECK_dot_H
#define HAVE_CHECK_dot_H

/* Sole public interface: the check() macro */
#define check( p, ... ) \
check_FLC( __FILE__, LINE__STRING, #p, p, __VA_ARGS__ )

/* Private implementation - support macros */
#define check_FLC( f, l, c, p, ... ) ( \
(p) ? 1 : check_OOPS( f, l, c, __func__, __VA_ARGS__ ) \
)

#define check_OOPS( f, l, c, fu, ... ) \
check_failed( f ":" l ": check( " c " )", fu, __VA_ARGS__ )

#define LINE__STRING LINE__STRING_a( __LINE__ )
#define LINE__STRING_a( line ) LINE__STRING_b( line )
#define LINE__STRING_b( line ) #line

/* Private implementation - need to declare function check_failed() */
extern int
check_failed( const char *, const char *, const char *, ... );

/* That's all folks! */
#endif/*HAVE_CHECK_dot_H*/

File check.c:

#include "check.h"

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

typedef const char *String; // convenience typedef

extern int
check_failed( String flc, String function, String format, ... ){
va_list ap;
fprintf( stderr, "%s [ in %s() ]\n", flc, function );

va_start( ap, format );
fprintf( stderr, " Note: " );
vfprintf( stderr, format, ap );
fprintf( stderr, "\n" );
va_end( ap );

return exit( EXIT_FAILURE ), 0;
}

File try-check.c to test the functionality:

#include "check.h"

int
main(){
int a = 1, b = 0;
check( a < b, "a is %d, b is %d", a, b );
return 0;
}

Output:

try-check.c:7: check( a < b ) [ in main() ]
Note: a is 1, b is 0

Additional remarks start here.

My macro is named 'check()' rather than 'assert()'. Another name might
be better, but IMO the name 'assert' is best avoided.

The output format is chosen to match standard error messages, such as
those given by gcc. This format allows "next error" to position to
the file and line indicated.

The form of expansions of check() calls are syntactically expressions.
This choice allows calls to check() to be written in places where
expressions are allowed but statements are not, such as

while( check( p && *p >= 0, "wtf?" ), c = *p++ ){ ... }

IMO it is good practice to write macros that expand to expressions
rather than statements whenever practicable, and it very much is
so in this case.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Mehdi Amini <atorrses@gmail.com> writes:
[...]
>> I wanted to add __FUNCTION__ to above code too. Unfortunately this is
>> not part of c11 standard.
>
> (Noted: the macro __func__ is standard.)

Quibble: __func__ is a predefined identifier, not a macro (N1570 6.4.2.2).

--
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 */

On 2/21/22 01:49, Mehdi Amini wrote:
> 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.

Reading those values is not the point, I thought. Printing out the
values is - and that's the purpose of the ASSERT_PRINT() macro in his
example. As written, ASSERT_FORMAT can only handle int values, but if
you understand how it works, it's trivial to extend it to handle other
types.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Mehdi Amini <atorrses@gmail.com> writes:
>
> [...]
>
>>> I wanted to add __FUNCTION__ to above code too. Unfortunately this is
>>> not part of c11 standard.
>>
>> (Noted: the macro __func__ is standard.)
>
> Quibble: __func__ is a predefined identifier, not a macro (N1570 6.4.2.2).

Quite right. And it cannot be a macro, since function names
are not known during the preprocessor phases.

By the way, personally I think it's more significant than
just a quibble, but I won't quibble over that.

On 2022-02-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>> [...]
>>
>>>> I wanted to add __FUNCTION__ to above code too. Unfortunately this is
>>>> not part of c11 standard.
>>>
>>> (Noted: the macro __func__ is standard.)
>>
>> Quibble: __func__ is a predefined identifier, not a macro (N1570 6.4.2.2).
>
> Quite right. And it cannot be a macro, since function names
> are not known during the preprocessor phases.

Well, of course it could be macro, if it were permitted; just not one
that expands into a string literal token during preprocessing, for the
above reason.

For instance:

#define __func__ __func__impl

Since __func__ is already in a reserved namespace, there is little
motivation for another indirection like the above.

Since __func__ is standard, there is also little value in having
a macro just for the sake of being able to test for its presence:

#ifdef __func__
#define function_name __func__
#else
#define function_name ""
#endif

since condition be checked indirectly via testing for >= C99.

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

On Sat, 2022-02-19, Mehdi Amini wrote:
> Hi,
>
> Considering usage of "assert" , I want a more informative output from
> it. Consider:
....
>
> Output of gcc:
> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
> Aborted (core dumped)

Note that you just got the most informative output possible: a core dump.

It depends on what your goal is. For me, who tries to use assert() to
catch programming errors[1], a core dump is good. Assertions will happen
rarely, and will always need a thorough investigation followed by bug
fixing.

I believe this is the intended use of assert.

/Jorgen

[1] assert(foo) then means "the condition foo holds at this point in
the program, and if it doesn't, I messed up and need to rethink
the logic".

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <slrnt1h0d4.1rfm.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>On Sat, 2022-02-19, Mehdi Amini wrote:
>> Hi,
>>
>> Considering usage of "assert" , I want a more informative output from
>> it. Consider:
>...
>>
>> Output of gcc:
>> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
>> Aborted (core dumped)
>
>Note that you just got the most informative output possible: a core dump.

Most modern systems don't generate core dumps anymore (even though the
message you see says that they do). I personally don't know what you have
to do to configure the system so that it does generate the dump (*), and I
assume that most of the people posting these kinds of threads don't know
either.

>It depends on what your goal is. For me, who tries to use assert() to
>catch programming errors[1], a core dump is good. Assertions will happen
>rarely, and will always need a thorough investigation followed by bug
>fixing.
>
>I believe this is the intended use of assert.

Yup.

(*) No, I'm not really asking for you to tell me. I assume I could figure
it out with enough Googling. And I also assume it varies from system to
system and from shell to shell.

--
Debating creationists on the topic of evolution is rather like trying to
play chess with a pigeon --- it knocks the pieces over, craps on the
board, and flies back to its flock to claim victory.

On Friday, 25 February 2022 at 09:49:44 UTC+2, Kenny McCormack wrote:
> In article <slrnt1h0d4.1r...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
> >On Sat, 2022-02-19, Mehdi Amini wrote:
> >> Hi,
> >>
> >> Considering usage of "assert" , I want a more informative output from
> >> it. Consider:
> >...
> >>
> >> Output of gcc:
> >> verbose_assert.out: verbose_assert.c:10: main: Assertion `a==b' failed.
> >> Aborted (core dumped)
> >
> >Note that you just got the most informative output possible: a core dump.
> Most modern systems don't generate core dumps anymore (even though the
> message you see says that they do). I personally don't know what you have
> to do to configure the system so that it does generate the dump (*), and I
> assume that most of the people posting these kinds of threads don't know
> either.
> >It depends on what your goal is. For me, who tries to use assert() to
> >catch programming errors[1], a core dump is good. Assertions will happen
> >rarely, and will always need a thorough investigation followed by bug
> >fixing.
> >
> >I believe this is the intended use of assert.
> Yup.
>
> (*) No, I'm not really asking for you to tell me. I assume I could figure
> it out with enough Googling. And I also assume it varies from system to
> system and from shell to shell.

Google "post-mortem debugging". I thought most people know that it is
why these dumps are generated.

gazelle@shell.xmission.com (Kenny McCormack) writes:

>
>(*) No, I'm not really asking for you to tell me. I assume I could figure
>it out with enough Googling. And I also assume it varies from system to
>system and from shell to shell.

1) Make sure that any ABRT package (or distro equivalent) is
removed from your OS installation and use sysctl to set
the corefile naming pattern.
2) Add 'ulimit -c unlimited' to your .login/.profile/.bashrc/.cshrc/.kshrc
or update the PAM limits configuration.

In article <d47SJ.40379$8V_7.37421@fx04.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>>
>>(*) No, I'm not really asking for you to tell me. I assume I could figure
>>it out with enough Googling. And I also assume it varies from system to
>>system and from shell to shell.
>
> 1) Make sure that any ABRT package (or distro equivalent) is
> removed from your OS installation and use sysctl to set
> the corefile naming pattern.
> 2) Add 'ulimit -c unlimited' to your .login/.profile/.bashrc/.cshrc/.kshrc
> or update the PAM limits configuration.

What part of "I'm not really asking for you to tell me." is confusing you?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Infallibility

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <d47SJ.40379$8V_7.37421@fx04.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>>
>>>(*) No, I'm not really asking for you to tell me. I assume I could figure
>>>it out with enough Googling. And I also assume it varies from system to
>>>system and from shell to shell.
>>
>> 1) Make sure that any ABRT package (or distro equivalent) is
>> removed from your OS installation and use sysctl to set
>> the corefile naming pattern.
>> 2) Add 'ulimit -c unlimited' to your .login/.profile/.bashrc/.cshrc/.kshrc
>> or update the PAM limits configuration.
>
>What part of "I'm not really asking for you to tell me." is confusing you?

So you're under the assumption that nobody else who reads this usenet
newsgroup that would find the information useful now or in the future?

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <d47SJ.40379$8V_7.37421@fx04.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>>
>>>(*) No, I'm not really asking for you to tell me. I assume I could figure
>>>it out with enough Googling. And I also assume it varies from system to
>>>system and from shell to shell.
>>
>> 1) Make sure that any ABRT package (or distro equivalent) is
>> removed from your OS installation and use sysctl to set
>> the corefile naming pattern.
>> 2) Add 'ulimit -c unlimited' to your .login/.profile/.bashrc/.cshrc/.kshrc
>> or update the PAM limits configuration.
>
>What part of "I'm not really asking for you to tell me." is confusing you?

Nothing. Just because you're not asking him to tell you the answer
doesn't mean that he shouldn't provide it - if not for your benefit,
then for the benefit of others.
Your message could be misinterpreted, by those who don't know any
better, as implying that it's difficult to do, or at least difficult to
find out how to do it. His answer makes it clear that it's not
difficult. As for being difficult to find out, all you have to do is
type "man core" at the command line.

In article <svdnbf$6n0$1@dont-email.me>,
James Kuyper <slp53@pacbell.net> wrote:
....
>Nothing. Just because you're not asking him to tell you the answer
>doesn't mean that he shouldn't provide it - if not for your benefit,
>then for the benefit of others.
>blah, blah, blah

It shows an inability to follow directions.

It is widely understood that inability to follow directions is a strong
predictor of failure in life.

Don't worry about any of this. I don't expect you to be able to
understand it.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/EternalFlame

On Saturday, 26 February 2022 at 17:49:14 UTC, Kenny McCormack wrote:
> In article <svdnbf$6n0$1...@dont-email.me>,
> James Kuyper <sl...@pacbell.net> wrote:
> ...
> >Nothing. Just because you're not asking him to tell you the answer
> >doesn't mean that he shouldn't provide it - if not for your benefit,
> >then for the benefit of others.
> >blah, blah, blah
>
> It shows an inability to follow directions.
>
> It is widely understood that inability to follow directions is a strong
> predictor of failure in life.
>
> Don't worry about any of this. I don't expect you to be able to
> understand it.
>
Everybody starts out in life as child. The vast majority of people start out
on adult life as junior subordinates. How you do in the rest of your life
depends very strongly on how you do in these first phases.

However there is huge social stigma attached to the word "obedience".
Employers dare not use it. They use euphemisms like "teamworking skills"
instead.

In article <d90e8caf-0154-41df-9a77-4e9de403abe6n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>However there is huge social stigma attached to the word "obedience".
>Employers dare not use it. They use euphemisms like "teamworking skills"
>instead.

Excellent. Well said.

And they took it out of the marriage vows, too.

But is it really "obedience" to just follow the directions on the side of
the cake mix box, instead of brancing out on your own?

--
He must be a Muslim. He's got three wives and he doesn't drink.

On Saturday, February 26, 2022 at 12:49:14 PM UTC-5, Kenny McCormack wrote:
> In article <svdnbf$6n0$1...@dont-email.me>,
> James Kuyper <sl...@pacbell.net> wrote:
> ...
> >Nothing. Just because you're not asking him to tell you the answer
> >doesn't mean that he shouldn't provide it - if not for your benefit,
> >then for the benefit of others.
> >blah, blah, blah
>
> It shows an inability to follow directions.

Firstly, you did not issue any directions, you just provided information: "I'm not
really asking for you to tell me.". Secondly, you have no authority to issue
directions that Scott (or anyone else here) has any obligation to follow.

> It is widely understood that inability to follow directions is a strong
> predictor of failure in life.

An unwillingness to follow directions from people who lack the authority to
issue them and who fail to provide what you consider sufficient justification
is called "independence". I hereby direct you to stop posting to this
newsgroup and any other newsgroup I monitor regularly. When you fail to
follow that direction, will that make you an independent person, or just a
failure in life?

gazelle@shell.xmission.com (Kenny McCormack) wrote:

> But is it really "obedience" to just follow the directions on the side of
> the cake mix box, instead of brancing out on your own?

Maybe this kind of thinking is not popular these days, but I see things
like cake mix as materials to be used as you see fit ONCE YOU UNDERSTAND
THEIR PROPERTIES. Without that crucial step in learning, you are just
randomly messing around and the results may also be random.

PS. Ready cake mix recipes get a lot better with replacing oil with
melted butter and using additional egg. I've also seen recommended
replacing water with coffee for chocolate cake mixes, haven't tried it.

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

In article <87lexsehzm.fsf@tigger.extechop.net>,
Otto J. Makela <om@iki.fi> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) wrote:
>
>> But is it really "obedience" to just follow the directions on the side of
>> the cake mix box, instead of branching out on your own?
>
>Maybe this kind of thinking is not popular these days, but I see things
>like cake mix as materials to be used as you see fit ONCE YOU UNDERSTAND
>THEIR PROPERTIES. Without that crucial step in learning, you are just
>randomly messing around and the results may also be random.
>
>PS. Ready cake mix recipes get a lot better with replacing oil with
>melted butter and using additional egg. I've also seen recommended
>replacing water with coffee for chocolate cake mixes, haven't tried it.

Very interesting post. Thanks for writing it.

But the point is that the way you get to that point - of being able to
"understand their properties" is by first following the directions as
written - getting to know the area, before branching out on your own.

Similarly, the people who don't follow directions on this newsgroup (you
know who you are) should start out by first learning how to do that, before
branching out on their own.

And of course, in both cases (and many others), many/most never get beyond
the "following the directions" stage. And there's really nothing wrong
with that.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/ForFoxViewers

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-02-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> I wanted to add __FUNCTION__ to above code too. Unfortunately this is
>>>>> not part of c11 standard.
>>>>
>>>> (Noted: the macro __func__ is standard.)
>>>
>>> Quibble: __func__ is a predefined identifier, not a macro (N1570 6.4.2.2).
>>
>> Quite right. And it cannot be a macro, since function names
>> are not known during the preprocessor phases.
>
> Well, of course it could be macro, [...]

I believe there is nothing to stop an implementation from
defining

#define __func__ __func__

The point, obviously, is that __func__ cannot be a macro that
is useful in the same way that the predefined identifier is.

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

> 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.

Just a few comments on this.

One, the filename and line number can be combined to produce a
single string literal at compile time, using the preprocessor and
"gluing together" of string literals (and which can then be
combined with the format in the same way as above).

Two, usually it's a bad idea in cases like this to expand the
macro into a single function call, because variadic functions
cannot be inlined.

Three, another problem along those lines is that the function
arguments are evaluated even if the tested condition succeeds.
Combining points two and three, we might revise the macro
definition to something like (disclaimer: not tested)

#define MY_ASSERT( test, ... ) ( \
! (test) \
? my_assert_failed( FILE_LINE_STRING() __VA_ARGS__ ) \
: 0 \
)

(Note that the format string, if any, is part of __VA_ARGS__
and will be combined with the FILE_LINE_STRING() string per the
rules of combining adjacent string literals.)