Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > assert must take int?

Reply
Thread Tools

assert must take int?

 
 
Richard Heathfield
Guest
Posts: n/a
 
      12-09-2007
Golden California Girls said:

> Richard Heathfield wrote:


<snip>

>> A failing assertion indicates a broken program.

>
> You are assuming the thing being tested is the program logic.


Correct.

> Not always the case.


Also correct, because some people misuse assertions.

> Consider assert(rate_of_pay > 0) in a section of a system of
> programs where checks are being cut and the programmer knows that the
> section (possibly in another program) where the input of rate_of_pay
> happens it is tested to be positive.


This may or may not be a program logic error, and it's impossible to tell
without seeing more of the program. If, at this point in the program, it
is "impossible" for that object to have a non-positive value, then the
assertion is appropriate. If this is mere data validation, the assertion
is inappropriate; rather, the normal runtime error processing subsystem
for the program should be invoked.

> The user (operator) isn't going to solve this one no matter
> what message gets printed


Right. Nevertheless, if this is data validation, the error should be
reported as suggested above. If this is a program logic error, then it
should be revealed during testing. Yes, I know that testing cannot
guarantee the absence of bugs. But a white-box tester should view an
assertion as a challenge ("betcha you can't make this happen"), and should
strive to be equal to that challenge.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      12-09-2007
Richard Heathfield wrote:
>
> Golden California Girls said:
>

.... snip ...
>
>> Consider assert(rate_of_pay > 0) in a section of a system of
>> programs where checks are being cut and the programmer knows
>> that the section (possibly in another program) where the input
>> of rate_of_pay happens it is tested to be positive.

>
> This may or may not be a program logic error, and it's impossible
> to tell without seeing more of the program. If, at this point in
> the program, it is "impossible" for that object to have a non-
> positive value, then the assertion is appropriate. If this is
> mere data validation, the assertion is inappropriate; rather, the
> normal runtime error processing subsystem for the program should
> be invoked.


Normally I would consider that a programming error. However, it is
possibly that the firm is selling play time in its operations.
This may lead to confusion with tax rates, etc.

I suspect various firms with which I deal of this. Explains much.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      12-10-2007
Ben Bacarisse <(E-Mail Removed)> wrote:
> "Tomás Ó hÉilidhe" <(E-Mail Removed)> writes:
> > In C89, do we have to pass an int as an argument to
> > assert? I've got code at the moment that does an
> > assertion on pointer, e.g.:
> >
> > assert(p);
> >
> > , but I'm wondering if I should change that to:
> >
> > assert(0 != p);

>
> Yes, in C89 the prototype is for an int. In C99 this
> has been changed to any scalar expression (of course
> you can't write that as a prototype but that is the
> implementation's problem, not yours).


Since it's a macro, not a function, it's not much of
a problem for most implementations; just replace
expansion instances of the parameter p (say) with
((p) != 0).

--
Peter
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-10-2007
Harald van Dijk <(E-Mail Removed)> writes:
> On Sun, 09 Dec 2007 13:07:30 +0000, Richard Heathfield wrote:

[...]
>> First of all, let's establish that it is *not* a prototype. A prototype
>> is a function declaration that lists the types of its parameters. Since
>> assert is required to be a macro, it cannot be a function. Therefore, it
>> does not have a prototype. The best that can be said for the above is
>> that it is an illustration of what the prototype /would/ be if assert
>> /were/ a function.

>
> Agreed, but...
>
>> All it really tells us is that assert is a macro that
>> yields no value but which does require an expression, and it handily
>> tells us the type of the required expression, which is int.

>
> ...is there anything in C90 that supports this idea? You're saying that
> void assert(int expression);
> has a meaning that differs in important areas from the exact same syntax
> used to declare a function named assert, that since it isn't a prototype,
> it shouldn't be read as one. Yet at the same time you're saying this
> prototype-lookalike *should* be read as a prototype when determining the
> accepted type of the macro argument. I would expect the conclusion to be
> that the prototype-lookalike should be ignored entirely. Why is that not
> so?


The description of assert() in C90 was flawed. That standard used
something that looks like a prototype to illustrate how the assert
macro is to be used, but since it's required to be a macro, there's no
reasonable definition of assert() that would maintain the full
semantics required if it were a prototyped function (particularly the
implicit declaration to int for an argument of any arithmetic type).
Because of this, it's very difficult to argue that the behavior of
assert() with, say, a floating-point argument was well defined.

C99 improved the definition by providing a pseudo-prototype:

void assert(scalar expression);

Because it can't be a real prototype, we're left with the idea that it
can accept any arbitrary scalar expression; the description is also
clearer.

It's quite possible that all existing C90 implementations of assert()
work as expected for non-int scalar arguments (the most
straightforward implementation would work that way; you'd have to
expend extra effort to make non-int expressions fail). But since the
C90 standard didn't guarantee this, it was safest not to depend on it.

Replacing ``assert(expr)'' with ``assert(expr != 0)'' would suffice to
force the argument to be of type int, making the invocation safe.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      12-10-2007
"Richard Heathfield" <(E-Mail Removed)> wrote in message
> Golden California Girls said:
>
>> Richard Heathfield wrote:

>
>>> A failing assertion indicates a broken program.

>>
>> You are assuming the thing being tested is the program logic.

>
> Correct.
>
>> Not always the case.

>
> Also correct, because some people misuse assertions.
>

I sometimes assert() mallocs().
It is lazy habit.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
jaysome
Guest
Posts: n/a
 
      12-13-2007
On Sun, 09 Dec 2007 18:22:43 -0800, Keith Thompson <(E-Mail Removed)>
wrote:


[snip]

>It's quite possible that all existing C90 implementations of assert()
>work as expected for non-int scalar arguments (the most
>straightforward implementation would work that way; you'd have to
>expend extra effort to make non-int expressions fail). But since the
>C90 standard didn't guarantee this, it was safest not to depend on it.


The same could be said about all existing C90 implementations working
with "void main". Like it or not, that's how it is, or seems to be.
Nevertheless, "int main" is preferred.

Can anyone cite a C90 implementation that accepts "void main" (i.e.,
compiles and links, with or without warnings) and results in undefined
behavior? And as far as undefined behavior is concerned, I'm talking
about the nasty kind that makes your computer smoke or formats your
hard drive or even starts WWIII.

--
jay
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      12-13-2007
jaysome <(E-Mail Removed)> wrote:

> Can anyone cite a C90 implementation that accepts "void main" (i.e.,
> compiles and links, with or without warnings) and results in undefined
> behavior? And as far as undefined behavior is concerned, I'm talking
> about the nasty kind that makes your computer smoke or formats your
> hard drive or even starts WWIII.


That's a rather restrictive kind of "undefined behaviour" you're
demanding, then. Unpredictably breaking compile processes because make
receives random values isn't good enough for you any more? Programs
simply crashing won't pull it these days?

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To assert or not to assert... ImpalerCore C Programming 79 05-17-2010 12:47 PM
Why must and must not be "final" ? NeoGeoSNK Java 25 11-24-2006 02:02 AM
assert 0, "foo" vs. assert(0, "foo") Thomas Guettler Python 3 02-23-2005 07:53 PM
assert(x) and '#define ASSERT(x) assert(x)' Alex Vinokur C Programming 5 11-25-2004 08:48 PM
RE: remove assert statement (Was: Re: PEP new assert idiom) Robert Brewer Python 1 11-07-2004 06:53 PM



Advertisments