Is C type checking?

[Xiaoshen Li]

Hi,

I am reading the book "Concepts of programming languages" by R. W.
Sebesta. He said:

"One of the most important reasons why C is both liked and disliked is
its lack of complete type checking. For example, functions can be
written for which parameters are not type checked. Those who like C
appreciate the flexibility; those who do not like it find it too insecure."

Could you explain this to me with more detail? The book doesn't give any
more explanation. Thank you very much. I greatly apprecite it.

 

[pemo]

Hi,

I am reading the book "Concepts of programming languages" by R. W.
Sebesta. He said:

"One of the most important reasons why C is both liked and disliked is its
lack of complete type checking. For example, functions can be written for
which parameters are not type checked. Those who like C appreciate the
flexibility; those who do not like it find it too insecure."

Could you explain this to me with more detail? The book doesn't give any
more explanation. Thank you very much. I greatly apprecite it.

He might be referring to variadic functions like printf?

e.g. int printf(const char *, ...);

the ... means anything might be passed, and it's up the you not to lie to
printf.

 

[Christopher Benson-Manica]

"One of the most important reasons why C is both liked and disliked is
its lack of complete type checking. For example, functions can be
written for which parameters are not type checked. Those who like C
appreciate the flexibility; those who do not like it find it too insecure."

The author is presumably speaking about variadic functions such as
printf(), which are passed arguments whose types cannot be enforced at
compile time. The first argument to printf, for example, is a string
that tells the function the number and types to expect of the
remaining arguments at run time.

char foo[]="foo=%s";
printf( foo, 42 ); /* Causes UB at run time, but the compiler cannot
know this in general. */

 

[Richard Tobin]

"One of the most important reasons why C is both liked and disliked is
its lack of complete type checking. For example, functions can be
written for which parameters are not type checked.

Traditional (pre-ANSI) C did not provide any way to specify the types
of function parameters. ANSI C in 1989 added "prototypes", which
specify the parameter types. If you use these - and some compilers
have a flag that insists on them - then you get type checking for
parameters (though not for the variable parameters of functions like
printf).

If you want to deliberately defeat type-checking, you can use explicit
casts. And pointers can be converted to and from void * without a
cast (so you can pass a pointer of any type to a function expecting a
void *, thus providing a certain amount of genericity). This is a
reasonable compromise.

Those who like C appreciate the flexibility; those who do not like it
find it too insecure."

I don't think it's common to write functions without prototypes in
order to avoid type checking. It makes much more sense to uses
prototypes and explicit casts where necessary (which is hardly ever).

-- Richard

 

[Ben Pfaff]

If you want to deliberately defeat type-checking, you can use explicit
casts. And pointers can be converted to and from void * without a
cast (so you can pass a pointer of any type to a function expecting a
void *, thus providing a certain amount of genericity). This is a
reasonable compromise.

(I'm sure you realize this, but the OP might not.) Casts[*] can
be used to defeat type checking, but many don't do anything of
the sort. For example, a cast to `unsigned char' is often used
to bring a character into the proper range for passing to
isupper() or another <ctype.h> function.

[*] "Explicit casts" is redundant. All casts are explicit.

 

[Richard Tobin]

[*] "Explicit casts" is redundant. All casts are explicit.

All casts in C are explicit.

But I was describing what you can do in C, in the context of
programming languages in general. If I said "C uses null-terminated
strings", would you say that was redundant because all C strings are
null-terminated?

-- Richard

 

[Dave Vandervies]

[*] "Explicit casts" is redundant. All casts are explicit.

All casts in C are explicit.

But I was describing what you can do in C, in the context of
programming languages in general.

In that case, the term you'd want is "explicit conversions". A cast is
a source code construct that forces a conversion and is, by definition,
explicit.


dave

--
Dave Vandervies (e-mail address removed)

What should such a standard mandate for systems which don't use
directories, such as OS390? --Richard Heathfield and

A well-engineered fake. Chris Dollin in comp.lang.c

 

[Richard Tobin]

In that case, the term you'd want is "explicit conversions". A cast is
a source code construct that forces a conversion and is, by definition,
explicit.

Where do you get this definition from?

-- Richard

 

[Xiaoshen Li]

According the responses I got from you guys, Sebesta is exaggerating too
much here, based on his strong expression in the textbook. His bookd is
great. I feel hard to believe that he is wrong.

(Actually this book is edited by him. Each chapter is writen by
different authors.)

 

[Keith Thompson]

Where do you get this definition from?

C99 6.5.4.

That section does use the phrase "explicit cast", but there's no
implication that a cast can be implicit.

 

[Michael Mair]

Where do you get this definition from?

The standard:
C89, 3.2; even though 3.3.4 talks of _explicit_ casts
C99, 6.3; 6.5.4 does no more mention explicit casts

Cheers
Michael

 

[Michael Mair]

The standard:
C89, 3.2; even though 3.3.4 talks of _explicit_ casts
C99, 6.3; 6.5.4 does no more mention explicit casts

^^^^^^^ wrong. Just did not see it on the
screen.

 

[Richard Tobin]

Where do you get this definition from?

[/QUOTE]

C99 6.5.4.

We're going round in circles here. I know that *in C*, casts are
always explicit. But I was explaining something to someone who was
evidently not familiar with the details of C, so it would be unhelpful
to rely on that fact. As a term in computer science, casts may be
implicit, so referring to "explicit casts" when describing the
features available in C is not redundant.

-- Richard

 

[pete]

According the responses I got from you guys,
Sebesta is exaggerating too much here,
based on his strong expression in the textbook. His bookd is
great. I feel hard to believe that he is wrong.

(Actually this book is edited by him. Each chapter is writen by
different authors.)

Wouldn't a *complete* lack of type checking
mean that you *couldn't* write functions for
which parameters *are* checked?

 

[Skarmander]

pete wrote:

Wouldn't a *complete* lack of type checking
mean that you *couldn't* write functions for
which parameters *are* checked?

Hmm, yeah. That's why it doesn't say that.

Or are you trying to make a subtler point here?

S.

 

[Keith Thompson]

C99 6.5.4.

We're going round in circles here. I know that *in C*, casts are
always explicit. But I was explaining something to someone who was
evidently not familiar with the details of C, so it would be unhelpful
to rely on that fact. As a term in computer science, casts may be
implicit, so referring to "explicit casts" when describing the
features available in C is not redundant.[/QUOTE]

I don't recall seeing the term "cast" used other than in reference to
the explicit conversion construct in C (and in closely related
languages like C++). If I weren't talking about C, I would always use
the term "conversion" rather than "cast".

Then again, C must have gotten the term from somewhere.

 

[pete]

pete wrote:
<snip>
Hmm, yeah. That's why it doesn't say that.

Or are you trying to make a subtler point here?

No, I just read it wrong.

 

[Richard Tobin]

I don't recall seeing the term "cast" used other than in reference to
the explicit conversion construct in C (and in closely related
languages like C++).

I think it may first have been used in Algol68, where it refers to an
explicit conversion. On the other hand, SQL seems to use the term
"implicit cast" frequently.

And of course (as Google will demonstrate) the term "implicit cast" is
frequently used in the context of C, regardless of the standard. So I
think even in that context, "explicit cast" is redundant only when
talking to very specialised audiences.

-- Richard

 

[pete]

I think it may first have been used in Algol68, where it refers to an
explicit conversion. On the other hand, SQL seems to use the term
"implicit cast" frequently.

And of course (as Google will demonstrate) the term "implicit cast" is
frequently used in the context of C, regardless of the standard.

.... and "teh" is an alternate spelling for "the"

Results 1 - 10 of about 8,210,000 for teh. (0.06 seconds)

Teh enb.

 

[Neil Kurzman]

Hi,

I am reading the book "Concepts of programming languages" by R. W.
Sebesta. He said:

"One of the most important reasons why C is both liked and disliked is
its lack of complete type checking. For example, functions can be
written for which parameters are not type checked. Those who like C
appreciate the flexibility; those who do not like it find it too insecure."

Could you explain this to me with more detail? The book doesn't give any
more explanation. Thank you very much. I greatly apprecite it.

Didn't any one take Pascal?

C allow do operations on mixed types PASCAL does not it is strongly typed.

in C you can add an int to a char. In PASCAL the types must match.
in C you can cast to set the wrong type of variable to a function. In PASCAL
not gonna work.