Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #41686

Re: c prog -plz explain

Show all headers | View raw

On 2014-03-12, James Kuyper <jameskuyper@verizon.net> wrote:
> On 03/12/2014 03:03 PM, glen herrmannsfeldt wrote:
> ...
>> There are enough uses for non-pointer casts that I wouldn't rule
>> them out for beginners, but no good reasons that I can think of
>> for pointer casts.
>
> So, would you write code like the following, to avoid casts?
>
> double x;
> void *temp = &x;
> printf("%p\n", temp);

I would and I do. In the TXR language project, I banned void *.  Generic
pointers to anything are mem_t *, and those require casts in either direction.
The chk_malloc function that is used everywhre returns mem_t *, and various
other situations.

Other than that, there is no value in being able to express a potentially
unsafe pointer conversion without using the cast syntax, and it is wrongheaded
to look for the ability to do such a thing for the sake of saving keystrokes.

This is basically the same attitude which also does not want to write comments,
or documentation.

A cast is a remark that you put in the code that something very noteworthy is
going on that, if bungled, could wreck the correctness of the the program, in
exchange for the compiler making it happen without a diagnostic.  That remark
has a particular syntax, and that syntax can be found by automatic means. 

A tool that parses C can be developed which makes a report of all file names
and line numbers where pointer casts occur.  Regular expression grepping can
almost do it, except if it is concealed by macrology.

In other words, you're not getting rid of the diagnostic: you're just removing
the diagnostic from the compiler output, and placing an altered representation
of it into the code in the form of a type in parentheses. The cast is a
diagnostic label embedded in the code. It ensures that something is written
somewhere, addressing itself to the questionable situation.

> Imagine that a third party library declares
>
> int third_party_func(char*);
>
> even though third_party_func() doesn't write through the char* pointer,
> it only reads from it. You don't have the influence needed to convince
> them to use "const char*" instead. Your own code has:
>
> const char *message = "This memory cannot be safely modified";
>
> How do you pass message to third_party_func()?

If you write in Clean C (code that compiles as either C or C++)
you can do this:

  #ifdef __cplusplus
  #define REMOVE_QUAL(TYPE, PTR) (const_cast<TYPE>(PTR))
  #else
  #define REMOVE_QUAL(TYPE, PTR) ((TYPE) (PTR))
  #endif

  third_party_func(REMOVE_QUAL(char *, my_const_string));

Suppose my_const_string is wchar_t *.  It will still compile as C,
but you will catch it when you compile as C++.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 14:50 -0700
  Re: c prog -plz explain Keith Thompson <kst-u@mib.org> - 2014-03-10 15:41 -0700
    Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-10 23:21 +0000
      Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-10 23:24 +0000
      Re: c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 20:28 -0700
        Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-11 00:15 -0400
        Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 07:12 +0000
          Re: c prog -plz explain Noob <root@127.0.0.1> - 2014-03-12 10:43 +0100
            Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 14:38 +0000
              Re: c prog -plz explain Noob <root@127.0.0.1> - 2014-03-12 15:56 +0100
                Re: c prog -plz explain Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-12 11:16 -0400
                Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 11:36 -0400
                Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 15:38 +0000
              Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-12 19:13 +0000
                Re: c prog -plz explain Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-12 16:05 -0400
                Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 16:32 -0400
                Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-13 09:38 +1300
                Re: c prog -plz explain Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 08:32 -0700
            Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-12 19:03 +0000
              Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 15:33 -0400
                Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 20:56 +0000
                Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-13 10:07 +1300
        Re: c prog -plz explain "BartC" <bc@freeuk.com> - 2014-03-11 10:33 +0000
  Re: c prog -plz explain Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-03-10 18:48 -0400
    Re: c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 20:26 -0700
      Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-11 16:34 +1300
        typecasting (was Re: c prog -plz explain) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-03-12 07:03 +0000
          Re: typecasting (was Re: c prog -plz explain) Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 07:40 +0000
            Re: typecasting (was Re: c prog -plz explain) Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-12 10:47 -0400
            Re: typecasting (was Re: c prog -plz explain) Ken Brody <kenbrody@spamcop.net> - 2014-03-12 13:01 -0400
          Re: typecasting (was Re: c prog -plz explain) Richard <rgrdev_@gmail.com> - 2014-03-12 12:47 +0100
            Re: typecasting (was Re: c prog -plz explain) gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-12 12:39 +0000
              Re: typecasting (was Re: c prog -plz explain) Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 15:06 +0000
      Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 07:26 +0000
        Re: c prog -plz explain Richard <rgrdev_@gmail.com> - 2014-03-11 08:39 +0100
          Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 08:08 +0000
      Re: c prog -plz explain Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-03-11 09:14 -0400
      Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-11 15:38 +0000
  Re: c prog -plz explain Ken Brody <kenbrody@spamcop.net> - 2014-03-11 12:53 -0400
    Re: c prog -plz explain Keith Thompson <kst-u@mib.org> - 2014-03-11 11:47 -0700
      Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-11 21:41 +0000
        Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 22:01 +0000

csiph-web