c99 and the lack of warnings when int operations are applied to abool

[James Kuyper]

On 3/27/2012 12:53 PM, mathog wrote: ....

bool expensive(), complicated(), long_winded();
switch (4*expensive() + 2*complicated() + long_winded()) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
case 4: ...
case 5: ...
case 6: ...
case 7: ...
}

I'll grant that this sort of situation doesn't arise all that often,
and I'll grant that there are other ways to write the logic (there's
usually more than one way to do something in C), but I think you're
going overboard in trying to legislate the pattern out of existence.

If bool were a strictly logical type, on which no arithmetic could be
performed, that pattern would still be allowed, the syntax would just be
slightly more complicated:

(expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)

 

[Eric Sosman]

If bool were a strictly logical type, on which no arithmetic could be
performed, that pattern would still be allowed, the syntax would just be
slightly more complicated:

(expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)

"I'll grant that there are other ways to write the logic," as
a person I deeply respect once wrote.

Here's another example where arithmetic on bool is handy:

const int days_in_month[2][12] = {
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
bool is_leap_year = ...;
int month = ...;
int days = days_in_month[is_leap_year][month - 1];

"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

 

[James Kuyper]

On 04/26/2012 09:29 PM, Eric Sosman wrote:
....

"I'll grant that there are other ways to write the logic," as
a person I deeply respect once wrote.

Here's another example where arithmetic on bool is handy:

const int days_in_month[2][12] = {
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
bool is_leap_year = ...;
int month = ...;
int days = days_in_month[is_leap_year][month - 1];

"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

In a hypothetical C-like language where bools were truly a separate
type, a cast to int would not be allowed. Instead, use
(isleap_year ? 1 : 0).

 

[Eric Sosman]

On 04/26/2012 09:29 PM, Eric Sosman wrote:
...

"I'll grant that there are other ways to write the logic," as
a person I deeply respect once wrote.

Here's another example where arithmetic on bool is handy:

const int days_in_month[2][12] = {
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
bool is_leap_year = ...;
int month = ...;
int days = days_in_month[is_leap_year][month - 1];

"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

In a hypothetical C-like language where bools were truly a separate
type, a cast to int would not be allowed. Instead, use
(isleap_year ? 1 : 0).

"I'll grant ..." (Is there an echo in here?)

The question that burns in my feeble brain is: "Why?" What is
the benefit that a "No arithmetic on booleans" rule would bring?
In what way would the hypothetical C-like language be superior to
C-where-ints-work-just-fine-thanks? I'm not inclined to accept
unsupported assertions like "Cleanliness is next to Godliness,"
but would attend to concrete, measurable, or estimatable advantages,
or to credible first-person anecdotes.

So far, the only thing I've heard is the O.P.'s complaint
that the compiler allowed him to get himself in trouble by making
code changes without first understanding the code he was changing.

Well, golly.

If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

 

[James Kuyper]

On 4/26/2012 9:58 PM, James Kuyper wrote: ....

"I'll grant ..." (Is there an echo in here?)

The question that burns in my feeble brain is: "Why?" What is
the benefit that a "No arithmetic on booleans" rule would bring?

It makes syntax errors out of constructs that are conceptually
meaningless, forcing the use of alternative constructs that say more
precisely what is actually going on. As such, it makes it easier to
detect erroneous constructs.

....

If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

 

[ImpalerCore]

On 04/26/2012 09:29 PM, Eric Sosman wrote:
...

      "I'll grant that there are other ways to write the logic,"as
a person I deeply respect once wrote.
      Here's another example where arithmetic on bool is handy:
       const int days_in_month[2][12] = {
           { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
           { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
       };
       bool is_leap_year = ...;
       int month = ...;
       int days = days_in_month[is_leap_year][month - 1];
"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

In a hypothetical C-like language where bools were truly a separate
type, a cast to int would not be allowed. Instead, use
   (isleap_year ? 1 : 0).

     "I'll grant ..."  (Is there an echo in here?)

     The question that burns in my feeble brain is: "Why?"  What is
the benefit that a "No arithmetic on booleans" rule would bring?

The benefit is that one avoids mixing semantics with types that other
people may use differently. If you commonly use bool as an index to
an array, someone else may look at that and wonder, "What on earth is
that? Why aren't you using an int or size_t because those are my
conceptual types to use as an index." Either will get the job done,
but a careful choice of type can reduce the amount of confusion other
readers have to deal with, and provide more context to detect defects
in the presence of bugs.

Best regards,
John D.

 

[Lanarcam]

Le 27/04/2012 12:31, James Kuyper a écrit :

It makes syntax errors out of constructs that are conceptually
meaningless, forcing the use of alternative constructs that say more
precisely what is actually going on. As such, it makes it easier to
detect erroneous constructs.

...

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

I think you mean ADA.

 

[Willem]

James Kuyper wrote:
) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)> The question that burns in my feeble brain is: "Why?" What is
)> the benefit that a "No arithmetic on booleans" rule would bring?
)
) It makes syntax errors out of constructs that are conceptually
) meaningless, forcing the use of alternative constructs that say more
) precisely what is actually going on. As such, it makes it easier to
) detect erroneous constructs.

It also makes syntax errors out of constructs that are perfectly
meaningful, forcing the use of needless extra boilerplate code
that only serves to muddle what is actually going on.

The boundary between the two is purely a matter of taste.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

Le 27/04/2012 12:31, James Kuyper a écrit :

On 04/26/2012 10:32 PM, Eric Sosman wrote: [...]

If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

I think you mean ADA.

I think *you* mean Ada (the name is not an acronym).

But one could have a C-like language with fewer implicit conversions
without going as far as Ada, which doesn't even have implicit
conversions between otherwise identical integer types.

I can imagine a C-like language with, say, the following features:

- C-like implicit conversions among all numeric types, signed, unsigned,
and floating-point -- or maybe only allow implicit conversions within
each of the three kinds of numeric types (yes, I'm ignoring _Complex
for now)

- bool is treated as a scalar but non-numeric type

- Each enumerated type is treated as a scalar but non-numeric type
(bool could be a special-case enumerated type, with false and true as
enumerated constants)

- No implicit conversions between numeric and non-numeric types (but
casts work as in C)

- 0 is not a null pointer constant; instead, there's a keyword (say,
"nil") that is the language's *only* null pointer constant

- Relational and equality operators yield bool results

- Contexts that require conditions (if, for, while, do-while, !, &&, ||,
?:, and whatever else I've forgotten) require a bool expression

Some implications:

- The NULL macro is unnecessary, and is replaced by the nil keyword.

- You'd have to write "if (num != 0)" rather than "if (num)".

- You'd have to write "if (ptr != nil)" rather than "if (ptr)".

- There are undoubtedly more implications that would have to be worked
out.

This hypothetical language would be closer to Ada than C is, but
it's still much closer to C than it is to Ada. Think of a scale
with C at 0, Ada at 1, and this language at perhaps 0.05 or 0.1.

I do not suggest for a moment that C itself should be changed like this.
It would break almost all existing C code, and that's clearly unacceptable.

But personally, I think I'd like it a little better than I like C. (And
if I ever actually invented such a thing, I'd probably also clean up the
treatment of arrays and pointers.)

 

[Lanarcam]

Le 27/04/2012 20:28, Keith Thompson a écrit :

Le 27/04/2012 12:31, James Kuyper a écrit :

On 04/26/2012 10:32 PM, Eric Sosman wrote: [...]
If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

I think you mean ADA.

I think *you* mean Ada (the name is not an acronym).

But one could have a C-like language with fewer implicit conversions
without going as far as Ada, which doesn't even have implicit
conversions between otherwise identical integer types.

I can imagine a C-like language with, say, the following features:

- C-like implicit conversions among all numeric types, signed, unsigned,
and floating-point -- or maybe only allow implicit conversions within
each of the three kinds of numeric types (yes, I'm ignoring _Complex
for now)

- bool is treated as a scalar but non-numeric type

- Each enumerated type is treated as a scalar but non-numeric type
(bool could be a special-case enumerated type, with false and true as
enumerated constants)

- No implicit conversions between numeric and non-numeric types (but
casts work as in C)

- 0 is not a null pointer constant; instead, there's a keyword (say,
"nil") that is the language's *only* null pointer constant

- Relational and equality operators yield bool results

- Contexts that require conditions (if, for, while, do-while, !,&&, ||,
?:, and whatever else I've forgotten) require a bool expression

Some implications:

- The NULL macro is unnecessary, and is replaced by the nil keyword.

- You'd have to write "if (num != 0)" rather than "if (num)".

- You'd have to write "if (ptr != nil)" rather than "if (ptr)".

- There are undoubtedly more implications that would have to be worked
out.

This hypothetical language would be closer to Ada than C is, but
it's still much closer to C than it is to Ada. Think of a scale
with C at 0, Ada at 1, and this language at perhaps 0.05 or 0.1.

I do not suggest for a moment that C itself should be changed like this.
It would break almost all existing C code, and that's clearly unacceptable.

But personally, I think I'd like it a little better than I like C. (And
if I ever actually invented such a thing, I'd probably also clean up the
treatment of arrays and pointers.)

I agree, one could think also of C + MISRA, the coding standard for
safety devices in automotive with many restrictions that try to avoid
the unsafety of C.

 

[ImpalerCore]

James Kuyper wrote:

) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)>      The question that burns in my feeble brain is: "Why?"  What is
)> the benefit that a "No arithmetic on booleans" rule would bring?
)
) It makes syntax errors out of constructs that are conceptually
) meaningless, forcing the use of alternative constructs that say more
) precisely what is actually going on. As such, it makes it easier to
) detect erroneous constructs.

It also makes syntax errors out of constructs that are perfectly
meaningful, forcing the use of needless extra boilerplate code
that only serves to muddle what is actually going on.

The boundary between the two is purely a matter of taste.

Alright, let's put a sample out there. Do you believe that it would
be beneficial to go to the trouble of defining 'streq' just to
parameterize string equality in terms of a bool?

bool streq( const char* s1, const char* s2 )
{ return strcmp( s1, s2 ) == 0; }

Would you consider it a candidate for discussion of including it in
some future C standard, or consider it a waste of committee members
time? The example is completely trivial to implement, but I think it
illustrates one's perception of their value of abstraction vs
convenience.

For my purposes, the main benefit is that this extra conceptual
stratification allows one to separate comparison (-,0,+) functions
from search (true,false) functions for distinguishing operations in a
container interface.

struct c_list* c_list_search( struct c_list* list,
const void* property,
bool (*pred_fn)( const void*, const
void* ) );

I can accomplish the same thing with the canonical 'int (*cmp_fn)
( const void*, const void* )'. I just see more conceptual value in
defining search to use the 'pred_fn' version over the 'cmp_fn' version
(hence the motivation for defining my own 'c_streq' in the first
place).

Best regards,
John D.

 

[ImpalerCore]

Le 27/04/2012 12:31, James Kuyper a écrit :

On 04/26/2012 10:32 PM, Eric Sosman wrote: [...]
      If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.
A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

I think you mean ADA.

I think *you* mean Ada (the name is not an acronym).

But one could have a C-like language with fewer implicit conversions
without going as far as Ada, which doesn't even have implicit
conversions between otherwise identical integer types.

I can imagine a C-like language with, say, the following features:

- C-like implicit conversions among all numeric types, signed, unsigned,
  and floating-point -- or maybe only allow implicit conversions within
  each of the three kinds of numeric types (yes, I'm ignoring _Complex
  for now)

- bool is treated as a scalar but non-numeric type

- Each enumerated type is treated as a scalar but non-numeric type
  (bool could be a special-case enumerated type, with false and true as
  enumerated constants)

- No implicit conversions between numeric and non-numeric types (but
  casts work as in C)

- 0 is not a null pointer constant; instead, there's a keyword (say,
  "nil") that is the language's *only* null pointer constant

- Relational and equality operators yield bool results

- Contexts that require conditions (if, for, while, do-while, !, &&, ||,
  ?:, and whatever else I've forgotten) require a bool expression

Some implications:

- The NULL macro is unnecessary, and is replaced by the nil keyword.

- You'd have to write "if (num != 0)" rather than "if (num)".

- You'd have to write "if (ptr != nil)" rather than "if (ptr)".

- There are undoubtedly more implications that would have to be worked
  out.

This hypothetical language would be closer to Ada than C is, but
it's still much closer to C than it is to Ada.  Think of a scale
with C at 0, Ada at 1, and this language at perhaps 0.05 or 0.1.

I do not suggest for a moment that C itself should be changed like this.
It would break almost all existing C code, and that's clearly unacceptable.

True, but I'd be in favor of a -pedantic-thompson flag that warns
about many of these rules.

But personally, I think I'd like it a little better than I like C.  (And
if I ever actually invented such a thing, I'd probably also clean up the
treatment of arrays and pointers.)

Best regards,
John D.

 

[James Kuyper]

James Kuyper wrote:
) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)> The question that burns in my feeble brain is: "Why?" What is
)> the benefit that a "No arithmetic on booleans" rule would bring?
)
) It makes syntax errors out of constructs that are conceptually
) meaningless, forcing the use of alternative constructs that say more
) precisely what is actually going on. As such, it makes it easier to
) detect erroneous constructs.

It also makes syntax errors out of constructs that are perfectly
meaningful, forcing the use of needless extra boilerplate code
that only serves to muddle what is actually going on.

I deny the fundamental meaningfullness of any code that treats a logical
value as if it were numeric. What does true*3+false mean? It has a
specific numeric meaning, one that almost any C programmer would know -
but only because C arbitrarily gave it that meaning, not because it has
any inherent meaning. It's intrinsically meaningless to multiply a truth
value by 3.

 

[Willem]

James Kuyper wrote:
) On 04/27/2012 02:11 PM, Willem wrote:
)> James Kuyper wrote:
)> ) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)> )> The question that burns in my feeble brain is: "Why?" What is
)> )> the benefit that a "No arithmetic on booleans" rule would bring?
)> )
)> ) It makes syntax errors out of constructs that are conceptually
)> ) meaningless, forcing the use of alternative constructs that say more
)> ) precisely what is actually going on. As such, it makes it easier to
)> ) detect erroneous constructs.
)>
)> It also makes syntax errors out of constructs that are perfectly
)> meaningful, forcing the use of needless extra boilerplate code
)> that only serves to muddle what is actually going on.
)
) I deny the fundamental meaningfullness of any code that treats a logical
) value as if it were numeric. What does true*3+false mean? It has a
) specific numeric meaning, one that almost any C programmer would know -
) but only because C arbitrarily gave it that meaning, not because it has
) any inherent meaning. It's intrinsically meaningless to multiply a truth
) value by 3.

My apologies, I had misunderstood the statement as: "No using arbitratry
expressions as booleans", but for the other way round, calculating with
booleans, I almost(*) completely agree with you.

*) Bit-shifting is an exception, IMO.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Rui Maciel]

I deny the fundamental meaningfullness of any code that treats a logical
value as if it were numeric. What does true*3+false mean?

It means what you intend it to mean. For example, consider the following:

value = true*4 + true*2 + false;

This could very well be a way to define bitmask values.

It has a
specific numeric meaning, one that almost any C programmer would know -
but only because C arbitrarily gave it that meaning, not because it has
any inherent meaning.

While risking going off on a tangent, I have to point out the fact that
that's exactly how every single thing gets their meaning.

It's intrinsically meaningless to multiply a truth
value by 3.

<example>
const int option_1 = 1;
const int option_2 = 2;
const int option_1_and_2 = 3;

bool toggle_option_1_and_2 = get_input_from_the_user();

int program_options = toggle_option_1_and_2*option_1_and_2;
</example>


Rui Maciel

 

[Rui Maciel]

It makes syntax errors out of constructs that are conceptually
meaningless, forcing the use of alternative constructs that say more
precisely what is actually going on. As such, it makes it easier to
detect erroneous constructs.

...

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.

I don't believe those barriers are needed for one reason alone: if you do
want barriers, you are free to put them up yourself. Just wrap any
primitive data type with a struct and write your code around them as you see
fit.

<example>
rui@Kubuntu:tmp$ cat example.c
typedef struct Boolean
{
int value;
} boolean_t;


int main(void)
{
boolean_t b;
int number = b*3;

return 0;
}
rui@Kubuntu:tmp$ gcc example.c
example.c: In function ‘main’:
example.c:10:16: error: invalid operands to binary * (have ‘boolean_t’ and
‘int’)
</example>


Rui Maciel

 

[James Kuyper]

James Kuyper wrote:
) On 04/27/2012 02:11 PM, Willem wrote:
)> James Kuyper wrote:
)> ) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)> )> The question that burns in my feeble brain is: "Why?" What is
)> )> the benefit that a "No arithmetic on booleans" rule would bring?
)> )
)> ) It makes syntax errors out of constructs that are conceptually
)> ) meaningless, forcing the use of alternative constructs that say more
)> ) precisely what is actually going on. As such, it makes it easier to
)> ) detect erroneous constructs.
)>
)> It also makes syntax errors out of constructs that are perfectly
)> meaningful, forcing the use of needless extra boilerplate code
)> that only serves to muddle what is actually going on.
)
) I deny the fundamental meaningfullness of any code that treats a logical
) value as if it were numeric. What does true*3+false mean? It has a
) specific numeric meaning, one that almost any C programmer would know -
) but only because C arbitrarily gave it that meaning, not because it has
) any inherent meaning. It's intrinsically meaningless to multiply a truth
) value by 3.

My apologies, I had misunderstood the statement as: "No using arbitratry
expressions as booleans", but for the other way round, calculating with
booleans, I almost(*) completely agree with you.

Well, I meant it both ways, even if I only addressed one direction, so
you can retain your disagreement. I also believe that treating a
numeric, pointer or character value as if they had a boolean meaning is
equally meaningless. They work only because they have been arbitrarily
given a meaning by the C language.

void terminate(
char *p,
unsigned int n
){
if(p && (n || p[n]))
p[n] = '\0';
}

I've been programming in C since 1979, so it can be very difficult for
me to notice such things, but the meaning of that if() condition is a
result of the way C was designed, it's not something that the condition
actually clearly expresses.

 

[Keith Thompson]

I don't believe those barriers are needed for one reason alone: if you do
want barriers, you are free to put them up yourself. Just wrap any
primitive data type with a struct and write your code around them as you see
fit.

<example>
rui@Kubuntu:tmp$ cat example.c
typedef struct Boolean
{
int value;
} boolean_t;


int main(void)
{
boolean_t b;
int number = b*3;

return 0;
}
rui@Kubuntu:tmp$ gcc example.c
example.c: In function ‘main’:
example.c:10:16: error: invalid operands to binary * (have ‘boolean_t’ and
‘int’)
</example>

The cost of those barriers is massive inconvenience, and the compiler
can enforce restrictions for you only in some cases.

boolean_t b;
int number;
if (b) { ... } /* error */
if (b.value) { ... } /* ok */
if (num) { ... } /* error not caught by compiler */

boolean_t x = ...;
boolean_t y = ...;
boolean_t x_or_y = (boolean_t){ x.value || y.value };

The C language just doesn't have the ability to define a distinct
boolean type that works the way some of us might like.

(If you don't think having such a type is worthwhile in the first place,
then the disadvantages are irrelevant.)

 

[Eric Sosman]

[...] It's intrinsically meaningless to multiply a truth
value by 3.

(I'd decided to abandon this thread on the grounds that it had
turned into a purely religious dispute, but some straight lines are
just too deliciously tempting.)

(Ahem.) The Bellman begs to differ.

http://www.literature.org/authors/carroll-lewis/the-hunting-of-the-snark/chapter-01.html

 

[Jens Gustedt]

Am 04/27/2012 08:28 PM, schrieb Keith Thompson:

- bool is treated as a scalar but non-numeric type
- Each enumerated type is treated as a scalar but non-numeric type
(bool could be a special-case enumerated type, with false and true as
enumerated constants)

- No implicit conversions between numeric and non-numeric types (but
casts work as in C)

I don't see any good reason to forbid conversions *to* bool.

While I can image the confusion that was at the origin of this thread
of using bool in arithmetic, the converse rules how to interpret
numeric and pointer types in a boolean context are nice and clean.

Also I don't think that the current conversion rules for integer types
are ideal, since they are inconsistent between the preprocessor phase
and the rest of the compilation. Why not just have all integer
arithmetic happen in intmax_t or uintmax_t (and let the optimizer do a
bit of work if it can be proven that smaller types can be proven to be
sufficient) ?

- 0 is not a null pointer constant; instead, there's a keyword (say,
"nil") that is the language's *only* null pointer constant

I don't see the value of this either. The problem in C is not with 0
(and other values) as a null pointer constant but with the
underspecification of NULL.

Having a catch-all initializer for all data types is quite convenient,
I would miss that.

- Relational and equality operators yield bool results

- Contexts that require conditions (if, for, while, do-while, !, &&, ||,
?:, and whatever else I've forgotten) require a bool expression

Some implications:

- The NULL macro is unnecessary, and is replaced by the nil keyword.

this would be a good one, why not call it nullptr to keep it in sync
with C++ ? And in current C an identifier that is forced to the value
(void*)0 would perfectly play that role.

- You'd have to write "if (num != 0)" rather than "if (num)".

- You'd have to write "if (ptr != nil)" rather than "if (ptr)".

I personally wouldn't like that one

- There are undoubtedly more implications that would have to be worked
out.

I'd add another thing to that list: unprototyped functions. They are
particularly bad because of the lack of pointer conversion for their
arguments.

One could enforce an implicit conversion rule to void* for them, with
the consequence that passing an `int const*` to an unspecific
parameter wouldn't compile at all, or just forbid unprototyped
functions completely. I would prefer the later, I think, with the
consequence of also banning va_arg functions.

Jens