help for writing my own assert()

[priyanka]

Hi there,

Can anyone show me how the assert() function works ? I need to develop
my own assert() function instead of using the one defined in the
assert.h file. It would be great if anyone could show me the actual
source code of assert() function in assert.h header file.

I need to write the assert function that prints out error message when
the expression is wrong. For eg.,

int a = 2;
int b=3;
ASSERT (a == b);

Thank you,
Priyanka

[John F]

priyanka wrote:

Hi there,

Can anyone show me how the assert() function works ? I need to
develop
my own assert() function instead of using the one defined in the
assert.h file. It would be great if anyone could show me the actual
source code of assert() function in assert.h header file.

I need to write the assert function that prints out error message
when
the expression is wrong. For eg.,

int a = 2;
int b=3;
ASSERT (a == b);

Thank you,
Priyanka

#define ASSERT(xy,MSG) do \
{ \
if(!(xy))) \
{ \
fprintf(stderr,"Errormessage: %s",
MSG);\
} \
}while(0)

Use: ASSERT(a==b,"My Message to you")

you might insert a call to assert after the fprintf. or simply
exit(EXIT_FAILURE)...

--
Johannes
You can have it:
Quick, Accurate, Inexpensive.
Pick two.

[Michael Mair]

priyanka schrieb:

Can anyone show me how the assert() function works ? I need to develop

assert is a macro.

my own assert() function instead of using the one defined in the
assert.h file. It would be great if anyone could show me the actual
source code of assert() function in assert.h header file.

I need to write the assert function that prints out error message when
the expression is wrong. For eg.,

int a = 2;
int b=3;
ASSERT (a == b);

This version of ASSERT can be switched off just like the
original assert macro via defining NDEBUG; the trick used in
the "Call" of ASSERT to make the assertion print out a
customized error message works for many implementations'
assert as well.

,----
#include <stdio.h>

#define stringize(s) #s
#define XSTR(s) stringize(s)
#if !defined NDEBUG
void abort (void);
# if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
# define ASSERT(a) \
do { \
if (0 == (a)) { \
fprintf(stderr, \
"Assertion failed: %s, " \
"%s(), %d at \'%s\'\n", \
__FILE__, \
__func__, \
__LINE__, \
XSTR(a)); \
abort(); \
} \
} while (0)
# else
# define ASSERT(a) \
do { \
if (0 == (a)) { \
fprintf(stderr, \
"Assertion failed: %s, " \
"%d at \'%s\'\n", \
__FILE__, \
__LINE__, \
XSTR(a)); \
abort(); \
} \
} while (0)
# endif
#else
# define ASSERT(a) (void)0
#endif

int main (void)
{
ASSERT(1 == 0
&& "I am the pope");
return 0;
}
`----

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

"priyanka" <pr**********@gmail.comwrites:

Can anyone show me how the assert() function works ? I need to develop
my own assert() function instead of using the one defined in the
assert.h file.

Why? Is there something wrong with the predefined assert macro?

It would be great if anyone could show me the actual
source code of assert() function in assert.h header file.

If you have a C implementation, you almost certainly have an assert.h
file that you can look at yourself.

I need to write the assert function that prints out error message when
the expression is wrong. For eg.,

int a = 2;
int b=3;
ASSERT (a == b);

That's what the predefined assert does. Why are you reinventing the
wheel?

(The only reason I can think of to do this is as a homework
assignment. If that's what this is, do it yourself.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Thad Smith]

Keith Thompson wrote:

(The only reason I can think of to do this [TS: implement a custom assert
macro/fuction] is as a homework assignment.

I have implemented custom asserts more than once, not for homework, but
because:
1) I wanted to capture more information about the environment in which
the failure occurred
2) I was running on an embedded system without stderr/stdout.

--
Thad

[Andrew Poelstra]

On 2006-08-17, Thad Smith <Th*******@acm.orgwrote:

Keith Thompson wrote:

>(The only reason I can think of to do this [TS: implement a custom assert
macro/fuction] is as a homework assignment.

I have implemented custom asserts more than once, not for homework, but
because:
1) I wanted to capture more information about the environment in which
the failure occurred
2) I was running on an embedded system without stderr/stdout.

Both of those require extra code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.

[Christopher Benson-Manica]

Andrew Poelstra <ap*******@false.sitewrote:

Both of those require extra code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

Seems a moderately pointless one, since the definition is visible in
assert.h.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Andrew Poelstra]

On 2006-08-17, Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:

Andrew Poelstra <ap*******@false.sitewrote:

>Both of those require extra code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

Seems a moderately pointless one, since the definition is visible in
assert.h.

Assuming that
1) assert.h is a file
2) That file can be opened
3) That opened file can be read
4) That opened file, when read, contains a readable definition of assert()

Those three are true on most systems, but it's far from guaranteed.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.

[pete]

Andrew Poelstra wrote:

>
On 2006-08-17, Christopher Benson-Manica
<at***@otaku.freeshell.orgwrote:

Andrew Poelstra <ap*******@false.sitewrote:

Both of those require extra
code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

Seems a moderately pointless one, since the definition is visible in
assert.h.

Assuming that
1) assert.h is a file

Assumption not necessary:

/* BEGIN new.c */

#include <stdio.h>
#include <assert.h>

#define str(s) # s
#define xstr(s) str(s)

int main(void)
{
puts(xstr(assert(XXXXX)));
return 0;
}

/* END new.c */
--
pete

[Andrew Poelstra]

Andrew Poelstra <ap*******@false.sitewrites:

On 2006-08-17, Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:

>Andrew Poelstra <ap*******@false.sitewrote:

>>Both of those require extra code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

Seems a moderately pointless one, since the definition is visible in
assert.h.

Assuming that
1) assert.h is a file
2) That file can be opened
3) That opened file can be read
4) That opened file, when read, contains a readable definition of assert()

Those three are true on most systems, but it's far from guaranteed.

I meant four, of course. I added the fourth point as an afterthought, and
didn't edit my last line.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.

[Christopher Benson-Manica]

Andrew Poelstra <ap*******@false.sitewrote:

Assuming that
1) assert.h is a file

That's true, although I'm curious to know what else the Standard
allows a "header" to be.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Chris Dollin]

Christopher Benson-Manica wrote:

Andrew Poelstra <ap*******@false.sitewrote:

>Assuming that
1) assert.h is a file

That's true, although I'm curious to know what else the Standard
allows a "header" to be.

It doesn't require it to be a file, so its contents (or the meaning
of its contents) could be wired into the compiler.

I /think/ the Norcroft C compiler, at least on RISC OS, did/does this,
with options to allow it to use files instead.

[If the headers are in the compiler, then you don't need header files
somewhere to run the compiler, which is useful if you're juggling
floppy discs or want to be robust against someone reorganising their
hard disc.]

--
Chris "nostalgia" Dollin
"Life is full of mysteries. Consider this one of them." Sinclair, /Babylon 5/

[Eric Sosman]

Christopher Benson-Manica wrote On 08/18/06 09:52,:

Andrew Poelstra <ap*******@false.sitewrote:

>>Assuming that
1) assert.h is a file

That's true, although I'm curious to know what else the Standard
allows a "header" to be.

Anything that produces the effects the Standard calls
for. Case in point: The system headers for the old OpenVMS
VAXC compiler were not files, but "members" of a "library."
(The library was a file, but the individual headers were
not files.)

A visible consequence was in the expansion of the __FILE__
macro. For a header fetched from a library, __FILE__ expanded
to the library's file name with the member name appended,
something like "VAXC$LIBRARY.TLB(STDIO)" (I can't vouch for
the exact syntax any more; it was a long time ago). This
concatenation was not a valid file name; feed the string to
fopen() or something and you'd get nowhere.

VAXC was pre-Standard, but as far as I can see its
behavior in this regard would have been perfectly agreeable
to the Standard when it came along.

--
Er*********@sun.com

[Malcolm]

"Andrew Poelstra" <ap*******@false.sitewrote in message
news:sl**********************@wpsoftware.net...

On 2006-08-17, Christopher Benson-Manica <at***@otaku.freeshell.org>
wrote:

>Andrew Poelstra <ap*******@false.sitewrote:

>>Both of those require extra code that the OP did not specify that he
wants help with. This looks to be some sort of homework problem.

Seems a moderately pointless one, since the definition is visible in
assert.h.

Assuming that
1) assert.h is a file
2) That file can be opened
3) That opened file can be read
4) That opened file, when read, contains a readable definition of
assert()

Those three are true on most systems, but it's far from guaranteed.

And assuming that the students are sufficiently novices for writing assert()
to be a reasonable exercise, but sufficiently advanced for examining the
system header to be cheating rather than something the instructor is happy
to encourage.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.