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]

"Xiaoshen Li" <xl**@gmu.edu> wrote in message
news:dk***********@osf1.gmu.edu...

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]

Xiaoshen Li <xl**@gmu.edu> wrote:

"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. */

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Richard Tobin]

In article <dk***********@osf1.gmu.edu>, Xiaoshen Li <xl**@gmu.edu> wrote:

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

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Richard Tobin]

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

[*] "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]

In article <dk***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

[*] "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 dj******@csclub.uwaterloo.ca 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 article <dk**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote:

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

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <dk**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote:

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?

C99 6.5.4.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Mair]

Richard Tobin wrote:

In article <dk**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote:

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?

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Michael Mair wrote:

Richard Tobin wrote:

In article <dk**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote:

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?

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.
Cheers
Michael

--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

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?

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

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

Xiaoshen Li wrote:

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.

[pete]

Xiaoshen Li wrote:

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

Xiaoshen Li wrote:

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.

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

--
pete

[Skarmander]

pete wrote:
<snip>

Xiaoshen Li wrote:

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.

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]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

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?

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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Skarmander wrote:

pete wrote:
<snip>

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? :-)

No, I just read it wrong.

--
pete

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

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]

Richard Tobin wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

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.

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

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

Teh enb.

--
pete

[Neil Kurzman]

Xiaoshen Li wrote:

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.

[pete]

Neil Kurzman wrote:

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.

That depends on how you look at it.
The usual arithmetic conversions make arithmetic operands
of the addition operator, the same type,
and at least as high ranking as int.

--
pete