Half hearted _Bool

S

sandeep

In C99 the new _Bool boolean data type was introduced. However this seems
to be a token gesture! There was no attempt to integrate it into the
standard library. For example, functions like isdigit still return int
instead of the new _Bool (which has implicit casts to and from int, so
there would be no incompatability with existing code)

Compare this to the new restrict keyboard which is introduced into the
declarations of many standard library functions, potentially causing
subtle compatability bugs if programs compiled for C99 are linked against
C90 libraries.

Does anyone have any insight here?
 
E

Eric Sosman

In C99 the new _Bool boolean data type was introduced. However this seems
to be a token gesture! There was no attempt to integrate it into the
standard library. For example, functions like isdigit still return int
instead of the new _Bool (which has implicit casts to and from int, so
there would be no incompatability with existing code)

Where's the benefit in returning _Bool instead of zero/nonzero?
I suppose you could then write

if (isdigit(ch) ^ islower(ch))

.... but when was the last time you wanted to do such a thing? (Note
that `if (!isdigit(ch) ^ !islower(ch))' gives you the same effect
today, should you desire it.)

Meanwhile, the change would invalidate existing code that uses
function pointers to point at the isxxx() functions:

void doSomething(const char *string, int (*is_xxx)(int)) {
...
}

doSomething("The Answer is 42!", isdigit);

If isdigit() suddenly changed to a _Bool-valued function, compilers
would start complaining about this sort of thing in perfectly good
code. Code breakage has certainly been committed, but only in pursuit
of some real or imagined benefit. What benefit flows from this change,
a benefit valuable enough to excuse the breakage?
 
R

robertwessel2

In C99 the new _Bool boolean data type was introduced. However this seems
to be a token gesture! There was no attempt to integrate it into the
standard library. For example, functions like isdigit still return int
instead of the new _Bool (which has implicit casts to and from int, so
there would be no incompatability with existing code)


It would break anything expecting a function pointer to a routine
returning an int, to which you passed a pointer to isdigit().

Compare this to the new restrict keyboard which is introduced into the
declarations of many standard library functions, potentially causing
subtle compatability bugs if programs compiled for C99 are linked against
C90 libraries.


Why do you think it would be valid to link a C99 program against a C89/
C90 standard library?
 
S

sandeep

Eric said:
Meanwhile, the change would invalidate existing code that uses
function pointers to point at the isxxx() functions:

void doSomething(const char *string, int (*is_xxx)(int)) {
...
}

doSomething("The Answer is 42!", isdigit);

This is also true of introducing restrict into the declaration of strcpy
etc.
If isdigit() suddenly changed to a _Bool-valued function, compilers
would start complaining about this sort of thing in perfectly good code.
Code breakage has certainly been committed, but only in pursuit of some
real or imagined benefit. What benefit flows from this change, a
benefit valuable enough to excuse the breakage?

What was the point of introducing a _Bool type at all then? User code
could already make its own bool or boolean or __bool definitions if
necessary - why bother with a new type that doesn't appear anywhere in
the Standard Library API?
 
E

Eric Sosman

This is also true of introducing restrict into the declaration of strcpy
etc.

My understanding of `restrict' is not especially firm, but I
believe you're wrong about this. 6.7.3p7 says "[...] deleting all
instances of [restrict] from all preprocessing translation units
composing a conforming program does not change its meaning [...]"
So in particular, the presence or absence of `restrict' in the
declaration of a function pointer's prototype doesn't make any
difference.

FWIW, gcc agrees with me: The trivial translation unit

#include <string.h>
char * (*func)(char * R, const char * R) = strcpy;

.... compiles without complaint and produces the same object code
whether R is defined as `restrict' or defined as empty.
What was the point of introducing a _Bool type at all then? User code
could already make its own bool or boolean or __bool definitions if
necessary - why bother with a new type that doesn't appear anywhere in
the Standard Library API?

I don't think `long long' or `signed char' are used as function
values or arguments, either. As for the usefulness of _Bool -- well,
I think it's of marginal utility. C certainly managed without it
for a considerable span of time. C also managed without complex
numbers for a considerable span. Some people (myself included) see
no pressing need for either, but others quite clearly did so -- and
more to the point, they made a sufficiently strong case to convince
the C99 Committee. I wasn't there, didn't hear the arguments for and
against, and am not in a position to assess them.
 
T

Tim Rentsch

sandeep said:
This is also true of introducing restrict into the declaration of strcpy
etc.

Not so, because of 6.7.5.3p15, whose last sentence reads (parentheses
present in original):

(In the determination of type compatibility and of a composite
type, each parameter declared with function or array type is
taken as having the adjusted type and each parameter declared
with qualified type is taken as having the unqualified version
of its declared type.)

This means the 'restrict's in the definitions of strcpy() etc don't
affect the type compatibilities of those functions, any more than
if the parameters in the definition were 'const' or 'volatile'.

What was the point of introducing a _Bool type at all then? User code
could already make its own bool or boolean or __bool definitions if
necessary - why bother with a new type that doesn't appear anywhere in
the Standard Library API?

The semantics of _Bool differ in some significant ways from
the sementics of other integer types. User code can make
a "bool" or "boolean" type, but it isn't possible to make
a type that has the same semantics as _Bool without having _Bool.
 
T

Tim Rentsch

Richard Heathfield said:
Others have dealt with that point already, so I'm just here to pick a nit.


Here's the nit: there is no such thing as an implicit cast. A cast is
an *explicit* conversion, by definition. If you have a copy of the C99
Standard (or at least a draft), see 6.3 Conversions.

This complaint is silly. "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here. If the writing were meant as technically
precise, then okay, the objection might be reasonable; but the
writing is meant as English, and it is perfectly good English.
 
K

Kenny McCormack

Tim Rentsch said:
This complaint is silly. "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here. If the writing were meant as technically
precise, then okay, the objection might be reasonable; but the
writing is meant as English, and it is perfectly good English.

You are right, of course. But...

Alas, in CLC, "explicit cast" is right up with there with "void main" in
terms of "phrases that push the regs' buttons" - and wind them up
like a top.

You'll get used to it.
 
J

jacob navia

Richard Heathfield a écrit :
Tim Rentsch wrote:



It connotes "implicit explicit conversion". Gosh, how meaningful.
No, it denotes implicit conversion as anyone with good faith can understand.

An explicit conversion is

int m (int)4.67;

An implicit conversion is

int m = 5.876;

If you substitute conversion for "cast" (as anyone with good faith can
do) you understand what is going on. You want to put your own meaning
into the language used by people that do not know you nor have any
interest in using the words with the meaning you want to put into them.

Please understand that english is not your personal property and that
other people will use it in slightly different ways as you do. Since
they have the same rights as you, they can decide:

a) Use english in the way Mr R. Heathfield wants
b) Use english as THEY want, Mr Heathfield notwithsatnding.
 
V

Vincenzo Mercuri

Richard Heathfield a écrit :
No, it denotes implicit conversion as anyone with good faith can
understand.

An explicit conversion is

int m (int)4.67;

An implicit conversion is

int m = 5.876;

If you substitute conversion for "cast" (as anyone with good faith can
do) you understand what is going on. You want to put your own meaning
into the language used by people that do not know you nor have any
interest in using the words with the meaning you want to put into them.

Please understand that english is not your personal property and that
other people will use it in slightly different ways as you do. Since
they have the same rights as you, they can decide:

a) Use english in the way Mr R. Heathfield wants
b) Use english as THEY want, Mr Heathfield notwithsatnding.

ISO/IEC 9899:TC3 draft, 6.3p1, reads:

"Several operators convert operand values from one type to another
automatically. This subclause specifies the result required from
such an implicit conversion, as well as those that result from a
cast operation (an explicit conversion)."

There exist conversions. Only explicit ones can be called cast.

Since "cast" = "explicit conversion", then:
"implicit cast" = "implicit explicit conversion"

i.e. somewhat misleading as "absolute relative motion" could be
in physics: i mean "absolute motion" or "relative motion"?

So: i mean "explicit conversion" or "implicit conversion"?

I know that experts well understand what they are talking
about, but you always have to keep in mind that readers
are not all experts and maybe don't know how to check
the ISO Standard.

Since conversions are some of the 'hottest spots'
in the C language, it would be in general a good habit to get
a little 'picky' when dealing with them.

Regards
 
K

Keith Thompson

Tim Rentsch said:
This complaint is silly. "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here. If the writing were meant as technically
precise, then okay, the objection might be reasonable; but the
writing is meant as English, and it is perfectly good English.

I disagree.

Yes, we all know that "implicit cast" really means "implicit
conversion"; understanding what was meant is not the point.

The point is that the word "cast" has a very specific meaning,
and that meaning is specific to C, so questions of common English
are not quite as relevant as they might otherwise be.

If we loosely use the word "cast" to mean any conversion, implicit
or explicit, then what do we call the operator consisting of a
parenthesized type name?

We have two perfectly good words, "conversion" and "cast", with
related by quite distinct meanings. I don't want to lose that
useful distinction. I don't want to have to qualify every use of
either word with "explicit" or "implicit".

This isn't to imply that anyone who uses the phrase "implicit
cast" is stupid or evil. It's a common mistake, and a perfectly
understandable one. But it is, in my opinion, a mistake, and one
worth correcting.
 
P

Paul N

This complaint is silly.  "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here.  If the writing were meant as technically
precise, then okay, the objection might be reasonable;  but the
writing is meant as English, and it is perfectly good English.

Erm, I beg to differ. I don't see how the sentence can make sense
under any reasonable definition of "implicit". You have to adjust the
meaning of "cast" to include "conversion", which is a bit of a stretch
for a technical term.

And as Richard said, it is only a nit. But clearly, as Kenny says, one
which fires up the pedants.
 
K

Keith Thompson

sandeep said:
What was the point of introducing a _Bool type at all then? User code
could already make its own bool or boolean or __bool definitions if
necessary - why bother with a new type that doesn't appear anywhere in
the Standard Library API?

I think that was part of the point. One programmer defines his own
"bool" type, another defines "boolean", another defines "__bool",
another defines "TBool", and so on and so on. Adding a boolean type
to the language encourages consistency, at least in future code.

And, as others have mentioned, _Bool has properties that no user-defined
C90 type can have, such as conversion yielding either 0 or 1.

Personally, I would have preferred it if C had has "bool" from the
beginning, and had used it consistently in the library.

_Bool is a compromise. It gives is a standard Boolean type, but we're
still stuck with a great deal of existing code.
 
E

Eric Sosman

[...]
If we loosely use the word "cast" to mean any conversion, implicit
or explicit, then what do we call the operator consisting of a
parenthesized type name?

A "mistake," more often than not.
 
T

Tim Rentsch

Richard Heathfield said:
Tim Rentsch wrote:

This complaint is silly. "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here.

It connotes "implicit explicit conversion". [snip]

Perhaps you mean it *denotes* "implicit explicit conversion".
"Connotes" means something different. Clearly the use quoted
(and which was snipped in your response) *connotes* something
besides "implicit explicit conversion".
 
T

Tim Rentsch

Keith Thompson said:
I disagree.

Yes, we all know that "implicit cast" really means "implicit
conversion"; understanding what was meant is not the point.

The point is that the word "cast" has a very specific meaning,
and that meaning is specific to C, so questions of common English
are not quite as relevant as they might otherwise be.

If we loosely use the word "cast" to mean any conversion, implicit
or explicit, then what do we call the operator consisting of a
parenthesized type name?

We have two perfectly good words, "conversion" and "cast", with
related by quite distinct meanings. I don't want to lose that
useful distinction. I don't want to have to qualify every use of
either word with "explicit" or "implicit".

Even allowing use of the phrase "implicit cast", I don't think you
have to. Let me explain why.

The word "cast" in "implicit cast" doesn't just mean 'conversion'.
In fact C does implicit conversions in lots of different places,
in the sense that if a cast is an explicit conversion than a
conversion without using a cast is an implicit conversion. But
only some implicit conversions are meant by the phrase "implicit
cast". For example, if we have 'a + b', with variables 'a' and
'b' both shorts, the values are converted to type int before the
addition is done. This situation does do implicit conversion, but
does not fall under what was meant by "implicit cast" in the
original posting. In particular, an "implicit cast" is meant to
cover those cases where an inter-type (or inter-type-category?)
conversion is allowed in assignment-like contexts. This subset
is an important subset to identify, because it corresponds to
situations where "something surprising" happens. (Obviously
how "surprising" it is depends on the person, but I think you
can see what I mean.)

Other languages sometimes use the word "coercion" in connection
with this sort of implicitly-supplied conversion. Unfortunately
other languages use "coercion" to mean something very different,
so it isn't a good term to use in general. The problem is, C
has no term (in the sense that the Standard doesn't employ any
sort of term) to describe this situation, viz., where one type
is assignable to another but not (always) interoperable otherwise.
If we have 'void *pv;' and 'char *pc;', then 'pc = pv;' is allowed,
but 'pc - pv' is not allowed, as one example. Because there is
no Standard-sanctioned term for this kind of important case,
people pick a phrasing that they think expresses their meaning.
Under the circumstances, using the phrase "implicit cast" is
natural, and IMO better than many of the alternatives.

This isn't to imply that anyone who uses the phrase "implicit
cast" is stupid or evil. It's a common mistake, and a perfectly
understandable one. But it is, in my opinion, a mistake, and one
worth correcting.

I wouldn't call using "implicit cast" as an English phrase a
mistake, because I don't think it's 'wrong'. Of course it's
not technically accurate use of jargon. It isn't meant to
be. If there is confusion on that point, that confusion
might be worth pointing out, ie, if someone thinks 'implicit
cast' has a well-defined meaning under C Standard terminology,
that misunderstanding may deserve some comment. But if used
as a phrase in ordinary English, I don't think it should be
called "wrong", even if does make some of the more literal-minded
readers grit their teeth.

So here is my challenge to c.l.c readers (or at least those
following this thread): Don't like the phrase "implicit cast"?
Suggest a better one. Remember, we're looking for a term that
applies not to all cases where a conversion is implied by the
semantics, but only to cases such as assignment-like contexts
(and if you want you can say exactly which contexts fall into that
category). I'm happy to recommend another term be used, if
someone can come up with something that's clearly better.
 
T

Tim Rentsch

Paul N said:
Erm, I beg to differ. I don't see how the sentence can make sense
under any reasonable definition of "implicit". You have to adjust the
meaning of "cast" to include "conversion", which is a bit of a stretch
for a technical term.

Sorry, I don't understand the last point. Certainly a 'cast'
operation includes a conversion (assuming it's to a different
type than the to-be-casted expression). What are you saying here?
In any event I have explained the phrase "implicit cast" at
some length in another response.
And as Richard said, it is only a nit. [snip]

I understand it bothers some people. I just don't think
it's wrong to use as a phrase in ordinary English. The
word "nit" implies some sort of technical quibble, but
I think it also implies some degree of objective fact.
In the case here I believe that objective fact is lacking;
what's being offered is just personal opinion, but
dressed up as some sort of technically verifiable objection.
It's my opinion that there are no grounds here for such
an objection, because the phrase wasn't presented as
technically literal writing.
 
T

Tim Rentsch

Richard Heathfield said:
Tim said:
Richard Heathfield said:
Tim Rentsch wrote:

<snip>

This complaint is silly. "Implicit" is a perfectly good English
word, and anyone who is familiar enough with English to know what
"implicit" means understands what the phrase "implicit cast" is
meant to connote here.
It connotes "implicit explicit conversion". [snip]

Perhaps you mean it *denotes* "implicit explicit conversion".
"Connotes" means something different. Clearly the use quoted
(and which was snipped in your response) *connotes* something
besides "implicit explicit conversion".

I accept the correction on "connote", but I'd love to hear what you
think "implicit cast" "connotes".

I wrote on this in my response to Keith Thompson's posting.
 
T

Tim Rentsch

pete said:
Er..., um, No.

Everybody who knows English, knows what "implicit" means.

The word "cast" as used in C,
doesn't have any other meaning except a technical one.

Is it so hard to imagine that an English phrase could use one
word in its ordinary English sense and use another word in its
technical sense? I thought it was understood that 'cast' is
used here in the sense of 'explicit conversion' (said explicit
conversions being supplied by a 'cast operator'). I think we
can accept 'cast' as being used in its technical sense but
still make sense of "implicit cast" as a phrase in English.
Do you see what I mean?
 
K

Keith Thompson

Tim Rentsch said:
So here is my challenge to c.l.c readers (or at least those
following this thread): Don't like the phrase "implicit cast"?
Suggest a better one.
"Conversion".

Remember, we're looking for a term that
applies not to all cases where a conversion is implied by the
semantics, but only to cases such as assignment-like contexts
(and if you want you can say exactly which contexts fall into that
category). I'm happy to recommend another term be used, if
someone can come up with something that's clearly better.

How is that distinction useful, and how do you know that the previous
poster intended to make that distinction?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top