Is C type checking?

Discussion in 'C Programming' started by Xiaoshen Li, Nov 7, 2005.

  1. Xiaoshen Li

    Xiaoshen Li Guest

    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.
     
    Xiaoshen Li, Nov 7, 2005
    #1
    1. Advertising

  2. Xiaoshen Li

    pemo Guest

    "Xiaoshen Li" <> wrote in message
    news:dknnqc$835m$...
    > 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.
     
    pemo, Nov 7, 2005
    #2
    1. Advertising

  3. Xiaoshen Li <> 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.
     
    Christopher Benson-Manica, Nov 7, 2005
    #3
  4. In article <dknnqc$835m$>, Xiaoshen Li <> 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
     
    Richard Tobin, Nov 7, 2005
    #4
  5. Xiaoshen Li

    Ben Pfaff Guest

    (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[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
    \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\
    );}return 0;}
     
    Ben Pfaff, Nov 7, 2005
    #5
  6. In article <>,
    Ben Pfaff <> 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
     
    Richard Tobin, Nov 7, 2005
    #6
  7. In article <dko17f$2oq9$>,
    Richard Tobin <> wrote:
    >In article <>,
    >Ben Pfaff <> 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
    > 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
     
    Dave Vandervies, Nov 7, 2005
    #7
  8. In article <dko2pk$els$>,
    Dave Vandervies <> 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
     
    Richard Tobin, Nov 7, 2005
    #8
  9. Xiaoshen Li

    Xiaoshen Li Guest

    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.
    >
     
    Xiaoshen Li, Nov 7, 2005
    #9
  10. (Richard Tobin) writes:
    > In article <dko2pk$els$>,
    > Dave Vandervies <> 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) <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.
     
    Keith Thompson, Nov 7, 2005
    #10
  11. Xiaoshen Li

    Michael Mair Guest

    Richard Tobin wrote:
    > In article <dko2pk$els$>,
    > Dave Vandervies <> 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, Nov 7, 2005
    #11
  12. Xiaoshen Li

    Michael Mair Guest

    Michael Mair wrote:
    > Richard Tobin wrote:
    >
    >> In article <dko2pk$els$>,
    >> Dave Vandervies <> 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.
     
    Michael Mair, Nov 7, 2005
    #12
  13. In article <>,
    Keith Thompson <> 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
     
    Richard Tobin, Nov 7, 2005
    #13
  14. Xiaoshen Li

    pete Guest

    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
     
    pete, Nov 8, 2005
    #14
  15. Xiaoshen Li

    Skarmander Guest

    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.
     
    Skarmander, Nov 8, 2005
    #15
  16. (Richard Tobin) writes:
    > In article <>,
    > Keith Thompson <> 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) <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.
     
    Keith Thompson, Nov 8, 2005
    #16
  17. Xiaoshen Li

    pete Guest

    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
     
    pete, Nov 8, 2005
    #17
  18. In article <>,
    Keith Thompson <> 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
     
    Richard Tobin, Nov 8, 2005
    #18
  19. Xiaoshen Li

    pete Guest

    Richard Tobin wrote:
    >
    > In article <>,
    > Keith Thompson <> 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
     
    pete, Nov 8, 2005
    #19
  20. Xiaoshen Li

    Neil Kurzman Guest

    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.
     
    Neil Kurzman, Nov 15, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. heyo
    Replies:
    3
    Views:
    916
    Dan Pop
    Apr 1, 2004
  2. Tom Bradford
    Replies:
    4
    Views:
    629
    Florian Diesch
    Mar 10, 2006
  3. Delaney, Timothy (Tim)

    RE: Type Hinting vs Type Checking and Preconditions

    Delaney, Timothy (Tim), Mar 7, 2006, in forum: Python
    Replies:
    7
    Views:
    477
    Paul Boddie
    Mar 8, 2006
  4. Tom Bradford
    Replies:
    3
    Views:
    396
    Alex Martelli
    Mar 9, 2006
  5. Randell D.
    Replies:
    12
    Views:
    257
    Randell D.
    Jul 6, 2005
Loading...

Share This Page