Quiting a program using pure C

[Chris Torek]

Re: Quiting a program using pure C

[Specific to C99]
[color=blue]
>In <cmqjqc12r60@ne ws2.newsguy.com > Chris Torek <nospam@torek.n et> writes:[color=green]
>>... sort of a bug in C89, and is fixed in C99, where the argument
>>to assert() has type "bool" (from <stdbool.h>; really _Bool).[/color][/color]

In article <cmraof$57c$9@s unnews.cern.ch> Dan Pop <Dan.Pop@cern.c h> wrote:[color=blue]
>Nope, in C99 the argument to assert has scalar type.[/color]

Since I still have not actually bought the final PDF, I will believe
you; but:
[color=blue][color=green]
>>In C99, assert(NULL) is a valid invocation that -- if NDEBUG is not
>>defined -- emits a message and calls abort().[/color][/color]
[color=blue]
>You're contradicting yourself: if assert expected a bool argument, passing
>it (void *)0 would be far from correct: undefined behaviour.[/color]

I remember discussion (from before the C99 standard was final, I think)
about this. The claim was that:

a) assigning a bool variable from a pointer was allowed;

b) the result of such an assignment was "true" if the pointer
compares unequal to NULL and false if it compares equal -- e.g.:

char *p;
...
bool x = p; /* danger, maybe not actually legal C99 */

would always "mean the same thing" as:

bool x = (p != 0);

and therefore

c) by making assert "look like" a function taking a single "bool",
the rules for ordinary function parameter assignment would make:

p = malloc(N);
assert(p);

valid code (however ill-advised one might be to use assert() here).

If either (or both) of (a) or (b) is false in C99, the reasoning
would fall apart. (The pre-C99 draft I use as a quick searchable
text does not support either of the two claims, but I know that
this draft does not match the final standard, and that some of the
changes include details about "bool"s.)

In any case, I maintain that if you want to assert that some pointer
variable compares unequal to NULL, it is best -- for both correctness
*and* "human factor" reasons, as fuzzy and arguable as the latter
may be -- to write:

assert(ptr != NULL);

and not simply:

assert(ptr);

Of course, I also prefer:

if (ptr != NULL)

so "personal preference bias" might affect my "human factor reasons"
claim. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Daniel Vallstrom]

Re: Quiting a program using pure C

Chris Torek <nospam@torek.n et> wrote in message news:<cngma0026 90@news4.newsgu y.com>...[color=blue]
> [Specific to C99]
>[color=green]
> >In <cmqjqc12r60@ne ws2.newsguy.com > Chris Torek <nospam@torek.n et> writes:[color=darkred]
> >>... sort of a bug in C89, and is fixed in C99, where the argument
> >>to assert() has type "bool" (from <stdbool.h>; really _Bool).[/color][/color]
>
> In article <cmraof$57c$9@s unnews.cern.ch> Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
> >Nope, in C99 the argument to assert has scalar type.[/color]
>
> Since I still have not actually bought the final PDF, I will believe
> you; but:
>[color=green][color=darkred]
> >>In C99, assert(NULL) is a valid invocation that -- if NDEBUG is not
> >>defined -- emits a message and calls abort().[/color][/color]
>[color=green]
> >You're contradicting yourself: if assert expected a bool argument, passing
> >it (void *)0 would be far from correct: undefined behaviour.[/color]
>
> I remember discussion (from before the C99 standard was final, I think)
> about this. The claim was that:
>
> a) assigning a bool variable from a pointer was allowed;
>
> b) the result of such an assignment was "true" if the pointer
> compares unequal to NULL and false if it compares equal -- e.g.:
>
> char *p;
> ...
> bool x = p; /* danger, maybe not actually legal C99 */
>
> would always "mean the same thing" as:
>
> bool x = (p != 0);
>
> and therefore
>
> c) by making assert "look like" a function taking a single "bool",
> the rules for ordinary function parameter assignment would make:
>
> p = malloc(N);
> assert(p);
>
> valid code (however ill-advised one might be to use assert() here).
>
> If either (or both) of (a) or (b) is false in C99, the reasoning
> would fall apart. (The pre-C99 draft I use as a quick searchable
> text does not support either of the two claims, but I know that
> this draft does not match the final standard, and that some of the
> changes include details about "bool"s.)[/color]

C99 guarantees all of (a)-(c):

"6.3.1.2 Boolean type
When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1."

(Which is germane to the bool concept and you would expect or hope
it to hold also in C99.)

Still, assert takes a scalar argument also in C99 even though AFAICS it
could just as well have been redefined from C89 to take a bool.


Daniel Vallstrom

[Dan Pop]

Re: Quiting a program using pure C

In <629d1766.04111 80210.3e73cc02@ posting.google. com> daniel.vallstro m@gmail.com (Daniel Vallstrom) writes:
[color=blue]
>Chris Torek <nospam@torek.n et> wrote in message news:<cngma0026 90@news4.newsgu y.com>...[color=green]
>> [Specific to C99]
>>[color=darkred]
>> >In <cmqjqc12r60@ne ws2.newsguy.com > Chris Torek <nospam@torek.n et> writes:
>> >>... sort of a bug in C89, and is fixed in C99, where the argument
>> >>to assert() has type "bool" (from <stdbool.h>; really _Bool).[/color]
>>
>> In article <cmraof$57c$9@s unnews.cern.ch> Dan Pop <Dan.Pop@cern.c h> wrote:[color=darkred]
>> >Nope, in C99 the argument to assert has scalar type.[/color]
>>
>> Since I still have not actually bought the final PDF, I will believe
>> you; but:
>>[color=darkred]
>> >>In C99, assert(NULL) is a valid invocation that -- if NDEBUG is not
>> >>defined -- emits a message and calls abort().[/color]
>>[color=darkred]
>> >You're contradicting yourself: if assert expected a bool argument, passing
>> >it (void *)0 would be far from correct: undefined behaviour.[/color]
>>
>> I remember discussion (from before the C99 standard was final, I think)
>> about this. The claim was that:
>>
>> a) assigning a bool variable from a pointer was allowed;
>>
>> b) the result of such an assignment was "true" if the pointer
>> compares unequal to NULL and false if it compares equal -- e.g.:
>>
>> char *p;
>> ...
>> bool x = p; /* danger, maybe not actually legal C99 */
>>
>> would always "mean the same thing" as:
>>
>> bool x = (p != 0);
>>
>> and therefore
>>
>> c) by making assert "look like" a function taking a single "bool",
>> the rules for ordinary function parameter assignment would make:
>>
>> p = malloc(N);
>> assert(p);
>>
>> valid code (however ill-advised one might be to use assert() here).
>>
>> If either (or both) of (a) or (b) is false in C99, the reasoning
>> would fall apart. (The pre-C99 draft I use as a quick searchable
>> text does not support either of the two claims, but I know that
>> this draft does not match the final standard, and that some of the
>> changes include details about "bool"s.)[/color]
>
>C99 guarantees all of (a)-(c):
>
> "6.3.1.2 Boolean type
> When any scalar value is converted to _Bool, the result is 0 if the
> value compares equal to 0; otherwise, the result is 1."
>
>(Which is germane to the bool concept and you would expect or hope
>it to hold also in C99.)[/color]

It doesn't make any difference, because assert is a *macro*, not a
function, so the fact that pointers are assignment compatible with bools
is irrelevant to an assert defined as taking a bool parameter.
[color=blue]
>Still, assert takes a scalar argument also in C99 even though AFAICS it
>could just as well have been redefined from C89 to take a bool.[/color]

It *was* redefined from C89, where it takes an int expression as its
argument. If you define it as taking a bool, then you *must* pass it a
bool argument and not anything that is assignment compatible with a bool.

The rules that apply to function calls don't apply to library macro
invocations, unless the macro is replacing something that is specified as
a function. But this is not the case of assert, which is explicitly
specified as a macro:

7.2.1.1 The assert macro

Synopsis

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

Description

2 The assert macro puts diagnostic tests into programs;

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Daniel Vallstrom]

Re: Quiting a program using pure C

Dan.Pop@cern.ch (Dan Pop) wrote in message news:<cnij99$nd a$7@sunnews.cer n.ch>...[color=blue]
> In <629d1766.04111 80210.3e73cc02@ posting.google. com> daniel.vallstro m@gmail.com (Daniel Vallstrom) writes:[/color]

[snip discussion about assert() having a bool argument]
[color=blue]
> It doesn't make any difference, because assert is a *macro*, not a
> function, so the fact that pointers are assignment compatible with bools
> is irrelevant to an assert defined as taking a bool parameter.[/color]

Fair enough. However, *if* the type of the argument to assert() was
to be changed to bool/_Bool, one could also imagine the addition to
the standard of a new overreaching clause saying that the argument
to macros is to be casted, where applicable, to the macro argument
type when used. AFAICS that would work? (I'm not suggesting it ought
to be done.) Anyway, it is not bool's fault that it isn't the type
of assert().

[color=blue][color=green]
> >Still, assert takes a scalar argument also in C99 even though AFAICS it
> >could just as well have been redefined from C89 to take a bool.[/color]
>
> It *was* redefined from C89, where it takes an int expression as its
> argument. If you define it as taking a bool, then you *must* pass it a
> bool argument and not anything that is assignment compatible with a bool.[/color]

Ah! I obviously wasn't aware that C89 assert() only took int.
Good to know. (Ack, the number of boolean concepts in C...)


Daniel Vallstrom

[Dan Pop]

Re: Quiting a program using pure C

In <629d1766.04120 51742.5e1a07f6@ posting.google. com> daniel.vallstro m@gmail.com (Daniel Vallstrom) writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) wrote in message news:<cnij99$nd a$7@sunnews.cer n.ch>...[color=green]
>> In <629d1766.04111 80210.3e73cc02@ posting.google. com> daniel.vallstro m@gmail.com (Daniel Vallstrom) writes:[/color]
>
> [snip discussion about assert() having a bool argument]
>[color=green]
>> It doesn't make any difference, because assert is a *macro*, not a
>> function, so the fact that pointers are assignment compatible with bools
>> is irrelevant to an assert defined as taking a bool parameter.[/color]
>
>Fair enough. However, *if* the type of the argument to assert() was
>to be changed to bool/_Bool, one could also imagine the addition to
>the standard of a new overreaching clause saying that the argument
>to macros is to be casted, where applicable, to the macro argument
>type when used.[/color]

Macro arguments have no types, in general, which is a damn good thing.
[color=blue]
>AFAICS that would work?[/color]

No extra text is or would be needed. Whenever the specification of a
standard library macro requires an expression of a certain type as the
argument, it doesn't matter how this type is achieved, but no other type
can be used instead.
[color=blue]
>(I'm not suggesting it ought
>to be done.) Anyway, it is not bool's fault that it isn't the type
>of assert().[/color]

Fortunately, because the vast majority of assert() arguments don't have
bool type even when they are conceptually booleans. Would you like
writing assert((bool)(a == b)) instead of assert(a == b) ?
[color=blue][color=green][color=darkred]
>> >Still, assert takes a scalar argument also in C99 even though AFAICS it
>> >could just as well have been redefined from C89 to take a bool.[/color]
>>
>> It *was* redefined from C89, where it takes an int expression as its
>> argument. If you define it as taking a bool, then you *must* pass it a
>> bool argument and not anything that is assignment compatible with a bool.[/color]
>
>Ah! I obviously wasn't aware that C89 assert() only took int.[/color]

The good question is if there was/is any known C89 implementation where
assert(pointer) doesn't work as intuitively expected by its (mis)user.
To me, it looks like a bug in the C89 specification.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Daniel Vallstrom]

Re: Quiting a program using pure C

Dan Pop wrote:[color=blue]
> In <629d1766.04120 51742.5e1a07f6@ posting.google. com>[/color]
daniel.vallstro m@gmail.com (Daniel Vallstrom) writes:[color=blue]
>[color=green]
> >Dan.Pop@cern.c h (Dan Pop) wrote in message[/color][/color]
news:<cnij99$nd a$7@sunnews.cer n.ch>...

[snip discussion about having assert() take a bool argument]
[color=blue][color=green]
> >(I'm not suggesting it ought
> >to be done.) Anyway, it is not bool's fault that it isn't the type
> >of assert().[/color]
>
> Fortunately, because the vast majority of assert() arguments don't[/color]
have[color=blue]
> bool type even when they are conceptually booleans. Would you like
> writing assert((bool)(a == b)) instead of assert(a == b) ?[/color]

I just meant that if "assert(e)" was, in one way or another, stipulated

to mean "assert((bool)e )", then everything would still work. That is,
in C99, "assert(e)" is equivalent to "assert((bool)e )".

[color=blue][color=green][color=darkred]
> >> It *was* redefined from C89, where it takes an int expression as[/color][/color][/color]
its[color=blue][color=green][color=darkred]
> >> argument.[/color]
> >Ah! I obviously wasn't aware that C89 assert() only took int.[/color]
>
> The good question is if there was/is any known C89 implementation[/color]
where[color=blue]
> assert(pointer) doesn't work as intuitively expected by its[/color]
(mis)user.[color=blue]
> To me, it looks like a bug in the C89 specification.[/color]
Agreed.


Daniel Vallstrom

[Dan Pop]

Re: Quiting a program using pure C

In <1102866656.310 899.143880@z14g 2000cwz.googleg roups.com> "Daniel Vallstrom" <daniel.vallstr om@gmail.com> writes:
[color=blue]
>Dan Pop wrote:[color=green]
>> In <629d1766.04120 51742.5e1a07f6@ posting.google. com>[/color]
>daniel.vallstr om@gmail.com (Daniel Vallstrom) writes:[color=green]
>>[color=darkred]
>> >Dan.Pop@cern.c h (Dan Pop) wrote in message[/color][/color]
>news:<cnij99$n da$7@sunnews.ce rn.ch>...
>
>[snip discussion about having assert() take a bool argument]
>[color=green][color=darkred]
>> >(I'm not suggesting it ought
>> >to be done.) Anyway, it is not bool's fault that it isn't the type
>> >of assert().[/color]
>>
>> Fortunately, because the vast majority of assert() arguments don't[/color]
>have[color=green]
>> bool type even when they are conceptually booleans. Would you like
>> writing assert((bool)(a == b)) instead of assert(a == b) ?[/color]
>
>I just meant that if "assert(e)" was, in one way or another, stipulated
>
>to mean "assert((bool)e )", then everything would still work. That is,
>in C99, "assert(e)" is equivalent to "assert((bool)e )".[/color]

So, why bother with such a stipulation? At the end of the day, you still
have to compare the result against zero...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union