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

Groups > comp.lang.c > #8703 > unrolled thread

is there anything unstandard in the c part here

Back to article view | Back to comp.lang.c

Contents

  is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-25 17:45 -0600
    Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-25 23:53 +0000
      Re: is there anything unstandard in the c part here gwowen <gwowen@gmail.com> - 2011-07-26 01:50 -0700
        Re: is there anything unstandard in the c part here tom st denis <tom@iahu.ca> - 2011-07-26 06:17 -0700
          Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 11:08 -0400
            Re: is there anything unstandard in the c part here tom st denis <tom@iahu.ca> - 2011-07-26 10:51 -0700
              Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:08 -0700
                Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:41 -0400
                  Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 10:58 +0000
                    Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 13:58 +0100
              Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:24 -0400
                Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 11:07 +0000
                  Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:02 -0400
                  Re: is there anything unstandard in the c part here Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 17:16 -0400
        Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-26 09:39 -0400
          Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-07-27 07:24 +0100
            Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 07:11 -0400
            Re: is there anything unstandard in the c part here Noob <root@127.0.0.1> - 2011-07-27 15:20 +0200
            Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-27 14:25 +0000
              Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 08:10 -0700
                Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-27 17:42 +0000
                  Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 12:02 -0700
                    Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:04 -0700
                  Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 22:35 -0400
            Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:34 -0400
              Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 02:13 +0100
                Re: is there anything unstandard in the c part here Ike Naar <ike@sverige.freeshell.org> - 2011-07-28 07:33 +0000
                  Re: is there anything unstandard in the c part here Willem <willem@toad.stack.nl> - 2011-07-28 07:58 +0000
                    Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 04:25 -0400
                  Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 12:26 +0100
              Re: is there anything unstandard in the c part here gwowen <gwowen@gmail.com> - 2011-07-28 04:24 -0700
                Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 11:36 +0000
                  Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 15:11 +0100
                    Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 14:50 +0000
                      Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 17:28 +0100
                      Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-28 10:38 -0600
                        Re: is there anything unstandard in the c part here Michael Press <rubrum@pacbell.net> - 2011-08-02 17:20 -0700
                          Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-08-02 23:26 -0600
                            Re: is there anything unstandard in the c part here Michael Press <rubrum@pacbell.net> - 2011-08-03 16:09 -0700
                    Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:22 -0400
                    Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 22:22 -0400
                      Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 04:17 +0100
                        Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 23:40 -0400
                          Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 13:52 +0100
                  Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-07-31 09:19 +0100
                    Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-31 09:49 -0400
                      Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-02 06:56 +0100
                        Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-02 06:53 -0400
                Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 07:36 -0400
                Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:16 -0400
        Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-26 14:58 +0000
          Re: is there anything unstandard in the c part here Paul N <gw7rib@aol.com> - 2011-07-26 14:56 -0700
            Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:13 -0700
            Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 07:28 -0400
              Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 04:44 -0700
              Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 08:24 -0700
                Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 22:41 -0400
                  Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:19 -0700
                Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:06 -0700
                Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 01:54 -0600
        Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 11:01 -0400
          Re: is there anything unstandard in the c part here Chad <cdalten@gmail.com> - 2011-07-26 09:49 -0700
            Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 13:18 -0400
            Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-26 17:44 +0000
            Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 17:45 +0000
            Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
              Re: is there anything unstandard in the c part here Bill Waddington <william.waddington@beezmo.com> - 2011-07-26 11:55 -0700
                Re: is there anything unstandard in the c part here lawrence.jones@siemens.com - 2011-07-26 18:11 -0400
                  Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-27 20:58 -0600
              Re: is there anything unstandard in the c part here arnuld <sunrise@invalid.address> - 2011-08-02 05:24 +0000
                Re: is there anything unstandard in the c part here Ian Collins <ian-news@hotmail.com> - 2011-08-02 18:10 +1200
                Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-02 00:03 -0700
                Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-02 06:59 -0400
                Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-08-02 16:06 +0000
        Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
        Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:06 -0700
          Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-02 06:58 +0100
            Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-02 00:01 -0700
              Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-05 06:22 +0100
                Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-04 23:54 -0700
                Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-05 07:37 -0400
                  Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:05 +0100
                    Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-13 08:26 -0400
                    Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 14:09 +0100
            Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-08-02 12:58 -0400
              Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-10 01:31 -0700
                Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-10 08:28 -0400
                  Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:14 +0100
                    Re: is there anything unstandard in the c part here "io_x" <a@b.c.invalid> - 2011-08-13 10:08 +0200
                    Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-13 08:35 -0400
                    Re: is there anything unstandard in the c part here "J. J. Farrell" <jjf@bcs.org.uk> - 2011-08-14 04:00 +0100
                    Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-08-15 14:43 -0400
            Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-10 01:34 -0700
              Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:16 +0100
    Re: is there anything unstandard in the c part here Barry Schwarz <schwarzb@dqel.com> - 2011-07-25 17:52 -0700
      Re: is there anything unstandard in the c part here "J. J. Farrell" <jjf@bcs.org.uk> - 2011-07-26 02:10 +0100
      Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 06:17 +0000
        Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:03 -0700
          Re: is there anything unstandard in the c part here "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-26 00:08 -0700
          Re: is there anything unstandard in the c part here Ian Collins <ian-news@hotmail.com> - 2011-07-26 19:43 +1200
          Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 07:56 +0000
            Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 04:50 -0700
              Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 12:03 +0000
              Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
              Re: is there anything unstandard in the c part here Nobody <nobody@nowhere.com> - 2011-07-27 19:10 +0100
          Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 11:53 +0000
    Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:07 -0700
      Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-26 06:29 -0400
        Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-27 21:32 -0600
          Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 12:19 +0100
            Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 20:25 -0400
              Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-28 18:38 -0600
                Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 21:05 -0400
            Re: is there anything unstandard in the c part here "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-07-29 14:16 -0400
              Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 20:27 +0100
              Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 01:10 -0600
            Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 00:56 -0600
              Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-30 12:23 +0100
                Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 00:01 -0600
                  Re: is there anything unstandard in the c part here Ike Naar <ike@sverige.freeshell.org> - 2011-08-01 07:50 +0000
                    Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 07:43 -0600
                      Re: is there anything unstandard in the c part here Ike Naar <ike@sdf.lonestar.org> - 2011-08-01 15:20 +0000
                  Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-01 14:27 +0100
                    Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 08:02 -0600
                      Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-01 15:42 +0100

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#8787

In <lnk4b3hi8i.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:

> > I don't see how this would cause a compiler error.

> ``(char*) malloc(50)'' is of type char*.  pa is of type int*.
> char* and int* are not assignment-compatible.

You learn something new every day!  I thought the presence of a cast would
suppress all assignment compatability messages, but not so.  The compiler
still checks that the receiving type is compatible with the casted type
and emits a warning (but not an error) if it is not.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#8789

John Gordon <gordon@panix.com> writes:
> In <lnk4b3hi8i.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
>> > I don't see how this would cause a compiler error.
>
>> ``(char*) malloc(50)'' is of type char*.  pa is of type int*.
>> char* and int* are not assignment-compatible.
>
> You learn something new every day!  I thought the presence of a cast would
> suppress all assignment compatability messages, but not so.  The compiler
> still checks that the receiving type is compatible with the casted type
> and emits a warning (but not an error) if it is not.

Casts typically suppress warnings only for the conversion actually
specified by the cast.

For example:

    type1 *p1 = NULL;
    type2 *p2 = NULL;
    type3 *p3 = NULL;

    p1 = (type2*)p3;

Assume that type1, type2, and type 3 are not compatible types.

The cast specifies an explicit conversion from type3* to type2*.
No diagnostic is required, and most compilers will assume that you
know what you're doing and not issue a warnings.

But the type of ``(type2*)p3'' is type2*, and we're trying to
assign the result to an object of type type1*.  The fact that the
RHS happens to be a cast expression is irrelevant; all that matters
for the "=" operator is its type.  Since type2* cannot be implicitly
converted to type1*, a diagnostic is required.

(Note that the standard doesn't distinguish between warnings and
fatal errors.  gcc issues non-fatal warnings for some constraint
violations.  I personally would prefer these to be errors, but gcc's
behavior satisfies the standard's requirements.  Yes, I know you
tell gcc to treat warnings as errors, but that also applies to
optional warnings that don't refer to constraint violations.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8844

Keith Thompson <kst-u@mib.org> writes:

> [snip]

> (Note that the standard doesn't distinguish between warnings and
> fatal errors.  gcc issues non-fatal warnings for some constraint
> violations.  I personally would prefer these to be errors, but gcc's
> behavior satisfies the standard's requirements.  Yes, I know you
> tell gcc to treat warnings as errors, but that also applies to
> optional warnings that don't refer to constraint violations.)

Have you tried the  -pedantic-errors  option?

[toc] | [prev] | [next] | [standalone]

#8792

On 07/27/2011 01:42 PM, John Gordon wrote:
> In <lnk4b3hi8i.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
> 
>>> I don't see how this would cause a compiler error.
> 
>> ``(char*) malloc(50)'' is of type char*.  pa is of type int*.
>> char* and int* are not assignment-compatible.
> 
> You learn something new every day!  I thought the presence of a cast would
> suppress all assignment compatability messages, but not so.

The presence of a cast to a type compatible with the destination type
has precisely that effect. Such casts are quite common, which is
probably what led you to that conclusion.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8785

On 7/27/2011 2:24 AM, Gareth Owen wrote:
> James Kuyper<jameskuyper@verizon.net>  writes:
>
>> What are the drawbacks? I'm not familiar with any.
>
> Lets look at the code (roughly) as given
>
> char *pa;
> /* yadda yadda yadda */
> ..
> ..
> ..
> pa = (char*) malloc(50);
> ..
> ..
> ..
> /* code that presumably assumes 50 elements in pa[] */
>
>
> Now the advice given was "if you change the type of *pa, the cast is
> wrong".  So lets do that...
>
> With the cast
> -----------------------------------------------------------------------------
> int *pa;
> /* yadda yadda yadda */
> ..
> ..
> ..
> pa = (char*) malloc(50);
> ..
> ..
> ..
> /* code that presumably assumes 50 elements in pa[] */
> result: compiler error.

Well, my compiler only gives a warning.

> Take the cast away
> -----------------------------------------------------------------------------
> int *pa;
> /* yadda yadda yadda */
> ..
> ..
> ..
> pa = malloc(50);
> ..
> ..
> ..
> /* code that presumably assumes 50 elements in pa[] */
> result: undefined behaviour unless sizeof(int) == 1
>
> The *failure* to cast malloc() has hidden a bug in *exactly* the case for
> which casting malloc() was held up as being wrong.
> -----------------------------------------------------------------------------
>
> Personally, when I accidentally write buggy code, I want a compiler
> error rather undefined behaviour. YMMV.

So, what if you wrote it the "right way" using a cast:

     int *pa;
     ...
     pa = (int *)malloc(50);

Still has UB if you assume that pa contains 50 ints.  Your "buggy code" 
still invokes UB.  What happened to your "advantage" with the cast?


> Yes, I know all about the pa = malloc(50 * sizeof(*pa)) idiom, thanks,
> and I know that there *are* drawbacks to casting malloc. But my
> underlying point is correct - casting malloc() is a *style* issue, and
> only idiots argue that their style is correct and anything else is
> wrong.


-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8791

Kenneth Brody <kenbrody@spamcop.net> writes:

> On 7/27/2011 2:24 AM, Gareth Owen wrote:
>> James Kuyper<jameskuyper@verizon.net>  writes:
>>
>>> What are the drawbacks? I'm not familiar with any.
>>
>> Lets look at the code (roughly) as given
>>
>> char *pa;
>> /* yadda yadda yadda */
>> ..
>> ..
>> ..
>> pa = (char*) malloc(50);
>> ..
>> ..
>> ..
>> /* code that presumably assumes 50 elements in pa[] */
>>
>>
>> Now the advice given was "if you change the type of *pa, the cast is
>> wrong".  So lets do that...
>>
>> With the cast
>> -----------------------------------------------------------------------------
>> int *pa;
>> /* yadda yadda yadda */
>> ..
>> ..
>> ..
>> pa = (char*) malloc(50);
>> ..
>> ..
>> ..
>> /* code that presumably assumes 50 elements in pa[] */
>> result: compiler error.
>
> Well, my compiler only gives a warning.
>
>> Take the cast away
>> -----------------------------------------------------------------------------
>> int *pa;
>> /* yadda yadda yadda */
>> ..
>> ..
>> ..
>> pa = malloc(50);
>> ..
>> ..
>> ..
>> /* code that presumably assumes 50 elements in pa[] */
>> result: undefined behaviour unless sizeof(int) == 1
>>
>> The *failure* to cast malloc() has hidden a bug in *exactly* the case for
>> which casting malloc() was held up as being wrong.
>> -----------------------------------------------------------------------------
>>
>> Personally, when I accidentally write buggy code, I want a compiler
>> error rather undefined behaviour. YMMV.
>
> So, what if you wrote it the "right way" using a cast:
>
>     int *pa;
>     ...
>     pa = (int *)malloc(50);
>
> Still has UB if you assume that pa contains 50 ints.  Your "buggy
> code" still invokes UB.  What happened to your "advantage" with the
> cast?

The argument (such as it is) is not that changing the cast fixes
anything but that having it there in the first place (in this case as a
(char *) cast) alerts the programmer to a line the needs fixing.  This
will be either because the type of the pointer has changed or because
there is a typo and the assignment is being made to the wrong pointer
(or the typo is in the declaration of the pointer).

The first of these is covered by the p = malloc(n * sizeof *p) idiom and
the second is probably quite rare.  What's more, it is protection by
duplication, and duplication is anathema to programmers -- hence the
preferred typeless idiom.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8797

On 2011-07-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> The first of these is covered by the p = malloc(n * sizeof *p) idiom and
> the second is probably quite rare.  What's more, it is protection by
> duplication, and duplication is anathema to programmers -- hence the
> preferred typeless idiom.

To be fair, the preferred idiom also relies on duplication: in

    p = malloc(n * sizeof *p);

the duplication is benign, but if the pointer expression
becomes more complicated, as in

    *(*co_matrix)[pivot] = malloc(n * sizeof **(*co_matrix)[pivot]);

the duplication becomes a bit of a nuisance.
Because of the duplicated complexity, a silly mistake like

    *(*co_matrix)[pivot] = malloc(n * sizeof *(*co_matrix)[pivot]);

may creep in, which is not caught by the compiler, and is easily
overlooked during code inspection.

Also, if the pointer expression has side effects:

    a[j++] = malloc(n * sizeof *a[j++]);

although the preferred idiom works okay here (thanks to the fact that
sizeof does not evaluate its operand), this may confuse the reader.

[toc] | [prev] | [next] | [standalone]

#8798

Ike Naar wrote:
) To be fair, the preferred idiom also relies on duplication: in
)
)     p = malloc(n * sizeof *p);
)
) the duplication is benign, but if the pointer expression
) becomes more complicated, as in
)
)     *(*co_matrix)[pivot] = malloc(n * sizeof **(*co_matrix)[pivot]);
)
) the duplication becomes a bit of a nuisance.
) Because of the duplicated complexity, a silly mistake like
)
)     *(*co_matrix)[pivot] = malloc(n * sizeof *(*co_matrix)[pivot]);
)
) may creep in, which is not caught by the compiler, and is easily
) overlooked during code inspection.
)
) Also, if the pointer expression has side effects:
)
)     a[j++] = malloc(n * sizeof *a[j++]);
)
) although the preferred idiom works okay here (thanks to the fact that
) sizeof does not evaluate its operand), this may confuse the reader.

Which is why god invented macros.

#define NEW(x,n) ((x)=malloc((n) * sizeof(x)))

(If I remember correctly)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#8799

Willem wrote:
> 
> Ike Naar wrote:
> ) To be fair, the preferred idiom also relies on duplication: in
> )
> )     p = malloc(n * sizeof *p);
> )
> ) the duplication is benign, but if the pointer expression
> ) becomes more complicated, as in
> )
> )     *(*co_matrix)[pivot] = malloc(n * sizeof **(*co_matrix)[pivot]);
> )
> ) the duplication becomes a bit of a nuisance.
> ) Because of the duplicated complexity, a silly mistake like
> )
> )     *(*co_matrix)[pivot] = malloc(n * sizeof *(*co_matrix)[pivot]);
> )
> ) may creep in, which is not caught by the compiler, and is easily
> ) overlooked during code inspection.
> )
> ) Also, if the pointer expression has side effects:
> )
> )     a[j++] = malloc(n * sizeof *a[j++]);
> )
> ) although the preferred idiom works okay here (thanks to the fact that
> ) sizeof does not evaluate its operand), this may confuse the reader.
> 
> Which is why god invented macros.
> 
> #define NEW(x,n) ((x)=malloc((n) * sizeof(x)))
> 
> (If I remember correctly)

ITYM 
#define NEW(x, n) ((x) = malloc((n) * sizeof *(x)))

-- 
pete

[toc] | [prev] | [next] | [standalone]

#8804

Ike Naar <ike@sverige.freeshell.org> writes:

> On 2011-07-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> The first of these is covered by the p = malloc(n * sizeof *p) idiom and
>> the second is probably quite rare.  What's more, it is protection by
>> duplication, and duplication is anathema to programmers -- hence the
>> preferred typeless idiom.
>
> To be fair, the preferred idiom also relies on duplication: in
>
>     p = malloc(n * sizeof *p);
>
> the duplication is benign, but if the pointer expression
> becomes more complicated, as in
>
>     *(*co_matrix)[pivot] = malloc(n * sizeof **(*co_matrix)[pivot]);
>
> the duplication becomes a bit of a nuisance.

That's a very good point.  The duplication here is benign because of the
distance between the two instances.  It's diffuse duplication that is
such a problem.

> Because of the duplicated complexity, a silly mistake like
>
>     *(*co_matrix)[pivot] = malloc(n * sizeof *(*co_matrix)[pivot]);
>
> may creep in, which is not caught by the compiler, and is easily
> overlooked during code inspection.

As has been pointed out, because the duplication is in one expression
and macro would make sense here.  The more complex the expression the
more tempted I'd be to use a macro though for simplex expressions I
think a macro just hides what's going on without much benefit.

> Also, if the pointer expression has side effects:
>
>     a[j++] = malloc(n * sizeof *a[j++]);
>
> although the preferred idiom works okay here (thanks to the fact that
> sizeof does not evaluate its operand), this may confuse the reader.

I'm wary of limiting the use of good ideas because a reader may not know
the language.  C is not a big language after all and a comment is all
that's needed to make 100% sure.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8803

On Jul 27, 6:34 pm, Kenneth Brody <kenbr...@spamcop.net> wrote:

> So, what if you wrote it the "right way" using a cast:
>
>      int *pa;
>      ...
>      pa = (int *)malloc(50);

The point was how about the cast prevents me easily *changing* types.
Which it does, but changing types is bug prone.  Your "objection" is
completely orthogonal to that point.


int *pa;
pa = (int *)malloc(50); // wrong, if try and fit 50 ints into pa[]
int *pa;
pa = malloc(50);        // also wrong.

So lets look at it right.
----------------------------------------------------
int *pa;
.
.
.
pa = (int *)malloc(50*sizeof(int)); // right!
pa = malloc(50*sizeof(int));        // also right!
.
.
.
pa[49] = 0;  // OK
----------------------------------------------------


But at some point down the line, we realise we actually need the range
of a 'long' (assuming long > int), so go and change the type of pa.

long int *pa;
.
.
.
pa = (int *)malloc(50*sizeof(int)); // wrong, compile time error
pa = malloc(50*sizeof(int));        // wrong, UB at some unknown point
in the future
.
.
.
pa[49] = 0;    // UB for you, can't happen for me.

The cast is saying "I've coded this line under the assumption that the
LHS is of type int*.  If this assumption ever changes, can you let me
know? KTHXBYE".  Compile-time type checking is good.

[toc] | [prev] | [next] | [standalone]

#8805

On 2011-07-28, gwowen <gwowen@gmail.com> wrote:
> pa = (int *)malloc(50*sizeof(int)); // wrong, compile time error
> pa = malloc(50*sizeof(int));        // wrong, UB at some unknown point
> in the future
> .
> .
> .
> pa[49] = 0;    // UB for you, can't happen for me.
>
> The cast is saying "I've coded this line under the assumption that the
> LHS is of type int*.  If this assumption ever changes, can you let me
> know? KTHXBYE".  Compile-time type checking is good.

Of course, had you written

pa = malloc(50 * sizeof *pa);

you would have avoided the issue altogether, as this is always right no
matter what the type of pa might be.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#8809

Angel <angel+news@spamcop.net> writes:

> On 2011-07-28, gwowen <gwowen@gmail.com> wrote:
>> pa = (int *)malloc(50*sizeof(int)); // wrong, compile time error
>> pa = malloc(50*sizeof(int));        // wrong, UB at some unknown point
>> in the future
>> .
>> .
>> .
>> pa[49] = 0;    // UB for you, can't happen for me.
>>
>> The cast is saying "I've coded this line under the assumption that the
>> LHS is of type int*.  If this assumption ever changes, can you let me
>> know? KTHXBYE".  Compile-time type checking is good.
>
> Of course, had you written
>
> pa = malloc(50 * sizeof *pa);
>
> you would have avoided the issue altogether, as this is always right no
> matter what the type of pa might be.

Not if the error that gets introduced is in the type of pa.  I'm not
advocating for casting the return of malloc, but a meaningful discussion
requires understanding of the opposite view!  I think that the cast
malloc people like the feeling that the type is being checked rather
than just allocating storage for whatever type the pointer has.

I am having difficulty imagining a real-world situation where such a
problem won't be detected in other places (which is why I think it's a
weak argument) but there are programs which use the preferred idiom that
can be made silently incorrect by a typo which would provoke a
diagnostic using the cast malloc idiom.

It's interesting that no one from the cast malloc team has presented
such a program, so maybe I am making a case that they have not
considered.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8810

On 2011-07-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Angel <angel+news@spamcop.net> writes:
>
>> On 2011-07-28, gwowen <gwowen@gmail.com> wrote:
>>> pa = (int *)malloc(50*sizeof(int)); // wrong, compile time error
>>> pa = malloc(50*sizeof(int));        // wrong, UB at some unknown point
>>> in the future
>>> .
>>> .
>>> .
>>> pa[49] = 0;    // UB for you, can't happen for me.
>>>
>>> The cast is saying "I've coded this line under the assumption that the
>>> LHS is of type int*.  If this assumption ever changes, can you let me
>>> know? KTHXBYE".  Compile-time type checking is good.
>>
>> Of course, had you written
>>
>> pa = malloc(50 * sizeof *pa);
>>
>> you would have avoided the issue altogether, as this is always right no
>> matter what the type of pa might be.
>
> Not if the error that gets introduced is in the type of pa.  I'm not
> advocating for casting the return of malloc, but a meaningful discussion
> requires understanding of the opposite view!  I think that the cast
> malloc people like the feeling that the type is being checked rather
> than just allocating storage for whatever type the pointer has.

The type of pa being wrong for whatever purpose is a whole different
issue that is outside of scope of what is being discussed, and does not
invalidate the statement in any way. By that logic, you'd need casts
for every assigment you do, not just memory allocations.

Besides, if you don't know the type and purpose of your own variables,
you have a problem anyway, no matter how many casts you put in.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#8813

Angel <angel+news@spamcop.net> writes:

> On 2011-07-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Angel <angel+news@spamcop.net> writes:
>>
>>> On 2011-07-28, gwowen <gwowen@gmail.com> wrote:
>>>> pa = (int *)malloc(50*sizeof(int)); // wrong, compile time error
>>>> pa = malloc(50*sizeof(int));        // wrong, UB at some unknown point
>>>> in the future
>>>> .
>>>> .
>>>> .
>>>> pa[49] = 0;    // UB for you, can't happen for me.
>>>>
>>>> The cast is saying "I've coded this line under the assumption that the
>>>> LHS is of type int*.  If this assumption ever changes, can you let me
>>>> know? KTHXBYE".  Compile-time type checking is good.
>>>
>>> Of course, had you written
>>>
>>> pa = malloc(50 * sizeof *pa);
>>>
>>> you would have avoided the issue altogether, as this is always right no
>>> matter what the type of pa might be.
>>
>> Not if the error that gets introduced is in the type of pa.  I'm not
>> advocating for casting the return of malloc, but a meaningful discussion
>> requires understanding of the opposite view!  I think that the cast
>> malloc people like the feeling that the type is being checked rather
>> than just allocating storage for whatever type the pointer has.
>
> The type of pa being wrong for whatever purpose is a whole different
> issue that is outside of scope of what is being discussed, and does not
> invalidate the statement in any way. By that logic, you'd need casts
> for every assigment you do, not just memory allocations.

Obviously I did not think it was beyond of scope of the discussion but I
am very happy just to disagree about that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8814

Angel <angel+news@spamcop.net> writes:
>
> The type of pa being wrong for whatever purpose is a whole different
> issue that is outside of scope of what is being discussed, and does not
> invalidate the statement in any way. By that logic, you'd need casts
> for every assigment you do, not just memory allocations.

No, you assume the compiler will tell you about type conflicts when it
can.  This is just an argument for casting void*'s -- something I've
never done in the past, but this discussion has just about convinced me
to start doing it.

> Besides, if you don't know the type and purpose of your own variables,
> you have a problem anyway, no matter how many casts you put in.

I think it's a pretty safe statement about bugs in general that somehow,
somewhere, someway, you don't know what your code is doing.  A very
common part of discussions with students asking me for help with their
code went:

me:       "so let's put a printf here...."
student:  "but that's just $assumption there"
me:       "if we knew what your code was doing, you wouldn't be in my
          office"

[toc] | [prev] | [next] | [standalone]

#8989

In article <1br55aqs19.fsf@snowball.wb.pfeifferfamily.net>,
 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

> Angel <angel+news@spamcop.net> writes:
> >
> > The type of pa being wrong for whatever purpose is a whole different
> > issue that is outside of scope of what is being discussed, and does not
> > invalidate the statement in any way. By that logic, you'd need casts
> > for every assigment you do, not just memory allocations.
> 
> No, you assume the compiler will tell you about type conflicts when it
> can.  This is just an argument for casting void*'s -- something I've
> never done in the past, but this discussion has just about convinced me
> to start doing it.
> 
> > Besides, if you don't know the type and purpose of your own variables,
> > you have a problem anyway, no matter how many casts you put in.
> 
> I think it's a pretty safe statement about bugs in general that somehow,
> somewhere, someway, you don't know what your code is doing.  A very
> common part of discussions with students asking me for help with their
> code went:
> 
> me:       "so let's put a printf here...."
> student:  "but that's just $assumption there"
> me:       "if we knew what your code was doing, you wouldn't be in my
>           office"


--My program was working perfectly yesterday, and now it crashes.
--What did you change? 
--Nothing!

Took a while to find the answer to this.

--Then why did you rerun it?

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#8993

Michael Press <rubrum@pacbell.net> writes:

> In article <1br55aqs19.fsf@snowball.wb.pfeifferfamily.net>,
>  Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>
>> Angel <angel+news@spamcop.net> writes:
>> >
>> > The type of pa being wrong for whatever purpose is a whole different
>> > issue that is outside of scope of what is being discussed, and does not
>> > invalidate the statement in any way. By that logic, you'd need casts
>> > for every assigment you do, not just memory allocations.
>> 
>> No, you assume the compiler will tell you about type conflicts when it
>> can.  This is just an argument for casting void*'s -- something I've
>> never done in the past, but this discussion has just about convinced me
>> to start doing it.
>> 
>> > Besides, if you don't know the type and purpose of your own variables,
>> > you have a problem anyway, no matter how many casts you put in.
>> 
>> I think it's a pretty safe statement about bugs in general that somehow,
>> somewhere, someway, you don't know what your code is doing.  A very
>> common part of discussions with students asking me for help with their
>> code went:
>> 
>> me:       "so let's put a printf here...."
>> student:  "but that's just $assumption there"
>> me:       "if we knew what your code was doing, you wouldn't be in my
>>           office"
>
>
> --My program was working perfectly yesterday, and now it crashes.
> --What did you change? 
> --Nothing!
>
> Took a while to find the answer to this.
>
> --Then why did you rerun it?

For me, the answer was always "sigh", followed by something along the
lines of "but ls -l shows a time of 10:15 this morning."  "oh, well,
yeah, but that change didn't make any difference".

[toc] | [prev] | [next] | [standalone]

#9011

In article <1bzkjr12x0.fsf@snowball.wb.pfeifferfamily.net>,
 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article <1br55aqs19.fsf@snowball.wb.pfeifferfamily.net>,
> >  Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> >
> >> Angel <angel+news@spamcop.net> writes:
> >> >
> >> > The type of pa being wrong for whatever purpose is a whole different
> >> > issue that is outside of scope of what is being discussed, and does not
> >> > invalidate the statement in any way. By that logic, you'd need casts
> >> > for every assigment you do, not just memory allocations.
> >> 
> >> No, you assume the compiler will tell you about type conflicts when it
> >> can.  This is just an argument for casting void*'s -- something I've
> >> never done in the past, but this discussion has just about convinced me
> >> to start doing it.
> >> 
> >> > Besides, if you don't know the type and purpose of your own variables,
> >> > you have a problem anyway, no matter how many casts you put in.
> >> 
> >> I think it's a pretty safe statement about bugs in general that somehow,
> >> somewhere, someway, you don't know what your code is doing.  A very
> >> common part of discussions with students asking me for help with their
> >> code went:
> >> 
> >> me:       "so let's put a printf here...."
> >> student:  "but that's just $assumption there"
> >> me:       "if we knew what your code was doing, you wouldn't be in my
> >>           office"
> >
> >
> > --My program was working perfectly yesterday, and now it crashes.
> > --What did you change? 
> > --Nothing!
> >
> > Took a while to find the answer to this.
> >
> > --Then why did you rerun it?
> 
> For me, the answer was always "sigh", followed by something along the
> lines of "but ls -l shows a time of 10:15 this morning."  "oh, well,
> yeah, but that change didn't make any difference".

"Why did you rerun it?" is more likely to make them
think about what they are doing; whereas citing the
modification date only gets excuses.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#8817

On 7/28/2011 10:11 AM, Ben Bacarisse wrote:
> Angel<angel+news@spamcop.net>  writes:
[...]
>> Of course, had you written
>>
>> pa = malloc(50 * sizeof *pa);
>>
>> you would have avoided the issue altogether, as this is always right no
>> matter what the type of pa might be.
>
> Not if the error that gets introduced is in the type of pa.  I'm not
> advocating for casting the return of malloc, but a meaningful discussion
> requires understanding of the opposite view!  I think that the cast
> malloc people like the feeling that the type is being checked rather
> than just allocating storage for whatever type the pointer has.

Well, you can then use the belt-and-suspenders approach:

     pa = (some_type *)malloc(50*sizeof(*pa));

Even if pa is changed to "some_other_type *", the buffer will still be able 
to hold 50 of them, and you still get the warm-fuzzies with the compiler 
warning.

> I am having difficulty imagining a real-world situation where such a
> problem won't be detected in other places (which is why I think it's a
> weak argument) but there are programs which use the preferred idiom that
> can be made silently incorrect by a typo which would provoke a
> diagnostic using the cast malloc idiom.
>
> It's interesting that no one from the cast malloc team has presented
> such a program, so maybe I am making a case that they have not
> considered.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web