assert must take int?

[Tomás Ó hÉilidhe]

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);
--
Tomás Ó hÉilidhe

[Ben Bacarisse]

"Tomás Ó hÉilidhe" <to*@lavabit.comwrites:

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

--
Ben.

[Richard Heathfield]

Tomás Ó hÉilidhe said:

>
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);

4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is undefined.

(As you seem to have guessed, in C99 this has changed, and the expression
only has to be scalar - the restriction to int has been lifted.)

>
, but I'm wondering if I should change that to:

assert(0 != p);

Yes, you should (or use an equivalent such as assert(p != 0) or assert(p !=
NULL) etc).

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

[Tomás Ó hÉilidhe]

Richard Heathfield <rj*@see.sig.invalidwrote in
news:c9******************************@bt.com:

>, but I'm wondering if I should change that to:

assert(0 != p);

Yes, you should (or use an equivalent such as assert(p != 0) or
assert(p != NULL) etc).

Thanks for the info. I only came across the problem when I changed
compilers recently, I got a boat-load of warnings about conversions from
pointers to integer type :-O

Looks like I'll be doing a "Find in files" for "assert" :-P

(I shudder to think what my previous compiler was actually doing... was it
taking the pointer as a scalar or was it doing something... dirty... )
--
Tomás Ó hÉilidhe

[Richard Tobin]

In article <Xn***************************@194.125.133.14>,
Tomás Ó hÉilidhe <to*@lavabit.comwrote:

>(I shudder to think what my previous compiler was actually doing... was it
taking the pointer as a scalar or was it doing something... dirty... )

Your previous compiler was doing what most compilers have always done:
define assert as a macro something like

#define assert(e) \
((void) ((e) ? 0 : __assert (#e, __FILE__, __LINE__)))

(that's the definition in MacOS X). The asserted expression is used
as a conditional, so it works perfectly well with a pointer. That
this is the Right Thing is confirmed by the change in C99.

The restriction in C90 was clearly a mistake; I'm not sure where it
came from.

-- Richard
--
:wq

[Martin Ambuhl]

"Tomï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï ¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ " wrote:

In C89, do we have to pass an int as an argument to assert?

No, you need to pass an expression that yields a value of any integer
type (and some implementations accept any scalar type, although that is
not guaranteed).

I've got code
at the moment that does an assertion on pointer, e.g.:

assert(p);

Since pointers are not of an integer type, this is not a good idea.

>
, but I'm wondering if I should change that to:

assert(0 != p);

That is probably a good idea.
It is also a good idea to remember that the result of a failed assert
can often be extreme consternation, puzzlement, and anger on the part of
a user. Remember to define NDEBUG for any code outside of the testing
stage, even if you consider using the assert macro a good debugging
technique.

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:

Tomás Ó hÉilidhe said:

>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);

4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is undefined.

The "prototype" would allow for an implicit conversion to int, if there
isn't any statement suggesting otherwise, so it would mean that C90
requires assert(0.5) to fail. It would also mean that assert(p); is a
constraint violation, rather than undefined behaviour. Does C90 have
relevant text on either of these points in what follows?

[Golden California Girls]

Martin Ambuhl wrote:

"Tomï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï ¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ " wrote:

>In C89, do we have to pass an int as an argument to assert?

No, you need to pass an expression that yields a value of any integer
type (and some implementations accept any scalar type, although that is
not guaranteed).

>I've got code at the moment that does an assertion on pointer, e.g.:

assert(p);

Since pointers are not of an integer type, this is not a good idea.

>>
, but I'm wondering if I should change that to:

assert(0 != p);

That is probably a good idea.
It is also a good idea to remember that the result of a failed assert
can often be extreme consternation, puzzlement, and anger on the part of
a user. Remember to define NDEBUG for any code outside of the testing
stage, even if you consider using the assert macro a good debugging
technique.

Or perhaps rewriting it so it says something more like "Call 1-800-HELP-DESK and
read us the rest of this message."

[CJ]

On 8 Dec 2007 at 12:31, Richard Heathfield wrote:

Tomás Ó hÉilidhe said:

>>
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);

4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is undefined.

(As you seem to have guessed, in C99 this has changed, and the expression
only has to be scalar - the restriction to int has been lifted.)

>>
, but I'm wondering if I should change that to:

assert(0 != p);

Yes, you should (or use an equivalent such as assert(p != 0) or assert(p !=
NULL) etc).

But can't we get from the Standard the following two facts:
1) any pointer can be converted (possibly with loss of information) to
an int
2) the value of such a converted pointer is 0 if and only if the pointer
was NULL

In this case all will be well - if there's a prototype in scope then the
compiler will automatically convert the pointer to an int, and 2)
guarantees that the assert behaves as intended.

[Keith Thompson]

"Tomás Ó hÉilidhe" <to*@lavabit.comwrites:

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);

Apart from the question of legality, remember that the text of the
expression is printed as part of the error message. A message
containing "p ~= NULL" is going to be much clearer than one containing
just "p" (even if you use a clear name than "p").

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
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"

[pete]

CJ wrote:

But can't we get from the Standard the following two facts:
1) any pointer can be converted (possibly with loss of information) to
an int

There's something like that in the standard.
Either that, or the attempt can be undefined.

N869
6.3.2.3 Pointers
[#6] Any pointer type may be converted to an integer type.
Except as previously specified, the result is
implementation-defined. If the result cannot be represented
in the integer type, the behavior is undefined. The result
need not be in the range of values of any integer type.

2) the value of such a converted pointer
is 0 if and only if the pointer was NULL

No.
There's nothing like that in the standard.

N869
6.3.2.3 Pointers
[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant. If a null pointer constant is
converted to a pointer type, the resulting pointer, called a
null pointer, is guaranteed to compare unequal to a pointer
to any object or function.
--
pete

[Richard Tobin]

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>Apart from the question of legality, remember that the text of the
expression is printed as part of the error message. A message
containing "p ~= NULL" is going to be much clearer than one containing
just "p" (even if you use a clear name than "p").

While this is true, I don't think the message is of much importance.
Interpreting the output of an assertion failure is the programmer's
job, and the first thing most programmers will do is look at the
source code. Really the file and line number would be just as useful
(who has multiple assert()s on a single line?).

-- Richard
--
:wq

[Martin Ambuhl]

CJ wrote:

In this case all will be well - if there's a prototype in scope then the
compiler will automatically convert the pointer to an int, and 2)
guarantees that the assert behaves as intended.

assert is defined by the standard to be a macro. There cannot be a
prototype in scope.

[Richard Heathfield]

Harald van D?k said:

On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:

>>
4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is undefined.

The "prototype" would allow for an implicit conversion to int,

Sure, but it isn't a prototype, is it? Yes, it don't 'arf look like one,
but it's really a macro in disguise. Writing it in prototype form was,
IMO, a mistake. So no, there is no implicit conversion to int.

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

[Christopher Benson-Manica]

[comp.lang.c] Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

(WRT assert()):

While this is true, I don't think the message is of much importance.
Interpreting the output of an assertion failure is the programmer's
job, and the first thing most programmers will do is look at the
source code. Really the file and line number would be just as useful
(who has multiple assert()s on a single line?).

I initially intended to disagree with you, but given how assert is and
more or less should be used, I can't make a strong argument for
descriptive assert() messages other than mere aesthetics.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[Christopher Benson-Manica]

[comp.lang.c] Keith Thompson <ks***@mib.orgwrote:

"Tom?s ? h?ilidhe" <to*@lavabit.comwrites:

> assert(0 != p);

I would personally prefer

assert( NULL != p );

, since the error message will be somewhat more descriptive,
clarifying that p is a pointer that is NULL and not an integer that
happened to be 0.

Apart from the question of legality, remember that the text of the
expression is printed as part of the error message. A message
containing "p ~= NULL" is going to be much clearer than one containing
just "p" (even if you use a clear name than "p").

Hm, p ~= NULL sounds like a bad plan, but p != NULL might be ok :-)

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sun, 09 Dec 2007 07:29:08 +0000, Richard Heathfield wrote:

Harald van D?k said:

>On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:

>>>
4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is
undefined.

The "prototype" would allow for an implicit conversion to int,

Sure, but it isn't a prototype, is it?

If it's not a prototype, how does it require the expression to be an int?

[RoS]

In data Sun, 9 Dec 2007 07:17:35 +0000 (UTC), Christopher
Benson-Manica scrisse:

>[comp.lang.c] Keith Thompson <ks***@mib.orgwrote:

>"Tom?s ? h?ilidhe" <to*@lavabit.comwrites:

>> assert(0 != p);

I would personally prefer

assert( NULL != p );

, since the error message will be somewhat more descriptive,
clarifying that p is a pointer that is NULL and not an integer that
happened to be 0.

i disagree
i cancelled all NULLs because the C[++?] compiler not compiled
some one of these (don't know why)

than i thought that with only one "0" the language were more easy;
for me exist only "0"; no NULL no '\0' no NUL

>Apart from the question of legality, remember that the text of the
expression is printed as part of the error message. A message
containing "p ~= NULL" is going to be much clearer than one containing
just "p" (even if you use a clear name than "p").

Hm, p ~= NULL sounds like a bad plan, but p != NULL might be ok :-)

[Richard Tobin]

In article <KZ******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>A failing assertion indicates a broken program. The proper solution is for
your testers to have a complete list of assertions, and to arrange
white-box tests that fire those assertions if it is at all possible. If
they *can* fire the assertions, they reject the code.

But surely the main use of assertions is for situations where you
believe there *isn't* any way for them to fail, but (not being
perfect) recognise that you might be mistaken. They help you find and
solve bugs you didn't know how to test for.

-- Richard
--
:wq

[Richard Heathfield]

Harald van D?k said:

On Sun, 09 Dec 2007 07:29:08 +0000, Richard Heathfield wrote:

>Harald van D?k said:

>>On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:

4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is
undefined.

The "prototype" would allow for an implicit conversion to int,

Sure, but it isn't a prototype, is it?

If it's not a prototype, how does it require the expression to be an int?

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. 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. Since the Standard doesn't
define what happens if you give it some other expression type, the
behaviour is undefined if you do that.

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

[Richard Heathfield]

Richard Tobin said:

In article <KZ******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>A failing assertion indicates a broken program. The proper solution is
for your testers to have a complete list of assertions, and to arrange
white-box tests that fire those assertions if it is at all possible. If
they *can* fire the assertions, they reject the code.

But surely the main use of assertions is for situations where you
believe there *isn't* any way for them to fail, but (not being
perfect) recognise that you might be mistaken.

Yes, of course. So the testers will have to be creative, right?

They help you find and
solve bugs you didn't know how to test for.

Right. But your testers will find a way, if they're any good.

(Incidentally, I'm sure you know this, but I suspect many people /don't/
realise that there really are people who do testing as a full-time job;
not all organisations have dedicated testers, but many do - and it is just
as skilled a job as programming, if not more so, when done properly.)

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

[Flash Gordon]

Richard Heathfield wrote, On 09/12/07 07:29:

Harald van D?k said:

>On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:

>>4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is undefined.

The "prototype" would allow for an implicit conversion to int,

Sure,

Surely wrong you mean. There is no implicit conversion from pointer to
int, so if there was a prototype and you passed a pointer the compiler
would be required to reject the program.

but it isn't a prototype, is it? Yes, it don't 'arf look like one,
but it's really a macro in disguise. Writing it in prototype form was,
IMO, a mistake.

Possibly, but it was certainly an easy way to express it.

So no, there is no implicit conversion to int.

There never is anyway.

Of course, you can always write your own macro...
#defined my_assert(x) assert((x)!=0)
Then you can provide my_assert anything that can legally be compared
against 0, including pointer and floating point expressions.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 09/12/07 07:29:

>Harald van D?k said:

>>On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is
undefined.
The "prototype" would allow for an implicit conversion to int,

Sure,

Surely wrong you mean. There is no implicit conversion from pointer to
int,

No, but there are implicit conversions from other expression types, e.g.
char, short, and so on, which is probably what I was thinking of when I
said "sure". Clearly you're right about pointers, though. (I must confess
that I do not always re-read an entire thread when posting a reply to a
particular point. My reply addressed the exact sentence quoted above, and
wasn't overly concerned with the upthread pointery thingy.)

so if there was a prototype and you passed a pointer the compiler
would be required to reject the program.

Yes.

>

>but it isn't a prototype, is it? Yes, it don't 'arf look like one,
but it's really a macro in disguise. Writing it in prototype form was,
IMO, a mistake.

Possibly, but it was certainly an easy way to express it.

Well, quite so - which is obviously why they did it.

>

>So no, there is no implicit conversion to int.

There never is anyway.

Except sometimes! :-)

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

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sun, 09 Dec 2007 13:07:30 +0000, Richard Heathfield wrote:

Harald van D?k said:

>On Sun, 09 Dec 2007 07:29:08 +0000, Richard Heathfield wrote:

>>Harald van D?k said:
On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
>
4.2.1.1 The assert macro
>
Synopsis
>
#include <assert.h>
void assert(int expression);
>
So you have to provide an int. If you don't, the behaviour is
undefined.

The "prototype" would allow for an implicit conversion to int,

Sure, but it isn't a prototype, is it?

If it's not a prototype, how does it require the expression to be an
int?

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?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sun, 09 Dec 2007 13:29:14 +0000, Flash Gordon wrote:

Richard Heathfield wrote, On 09/12/07 07:29:

>Harald van D?k said:

>>On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
4.2.1.1 The assert macro

Synopsis

#include <assert.h>
void assert(int expression);

So you have to provide an int. If you don't, the behaviour is
undefined.
The "prototype" would allow for an implicit conversion to int,

Sure,

Surely wrong you mean. There is no implicit conversion from pointer to
int, so if there was a prototype and you passed a pointer the compiler
would be required to reject the program.

I used assert(0.5) as my example, and there is an implicit conversion
from double to int.

[Malcolm McLean]

"RoS" <Ro*@not.existwrote in message

i disagree
i cancelled all NULLs because the C[++?] compiler not compiled
some one of these (don't know why)

You've got to include at least one header from the standard library to get
NULL defined.
Personally I prefer raw zeroes as well. The caps give NULL a visial emphasis
it ususally doesn't deserve.

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

[Richard Tobin]

In article <ic******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>(Incidentally, I'm sure you know this, but I suspect many people /don't/
realise that there really are people who do testing as a full-time job;
not all organisations have dedicated testers, but many do

And even if all organisations did, not all software is written by
organisations. Much is written by individuals with little if any
support, even if they are working for some organisation at the time.

Most of the programs I write, some of which are used by thousands of
people, are regarded as mere side-effects of fulfilling the research
contracts that fund us. At best they are regarded as a slightly
dubious kind of publication. I release them to other people because
they're useful and it helps make us well-known among people in our
research area, but the idea that the someone might pay us to test our
software is laughable. In effect, the users are the testers.

-- Richard
--
:wq

[Peter Nilsson]

Ben Bacarisse <[e-mail]:

"Tomás Ó hÉilidhe" <[e-mail]:

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

[Keith Thompson]

Harald van Dijk <tr*****@gmail.comwrites:

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) <ks***@mib.org>
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"

[jaysome]

On Sun, 09 Dec 2007 18:22:43 -0800, Keith Thompson <ks***@mib.org>
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

[Richard Bos]

jaysome <ja*****@hotmail.comwrote:

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