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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#8854

On 07/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. 

Could you give us an example of such an error? That code fragment seems.
to me, to necessarily and inherently correctly allocate exactly room for
50 elements of whatever type pa points at (assuming that later code
deals properly with the possibility that pa==NULL). The only error it
could contain is the 50, and inserting the cast won't do anything to
deal with the possibility of that kind of error.

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

All they're checking is whether they can remember what type pa has; why
check that? The idiom shown completely removes the need to remember what
the type is; with that removal comes the freedom to change the type
without any need to re-write this part of the code.

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

Please demonstrate how this can happen.
-- 
James Kuyper

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

#8855

James Kuyper <jameskuyper@verizon.net> writes:

> On 07/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. 
>
> Could you give us an example of such an error? That code fragment seems.
> to me, to necessarily and inherently correctly allocate exactly room for
> 50 elements of whatever type pa points at (assuming that later code
> deals properly with the possibility that pa==NULL). The only error it
> could contain is the 50, and inserting the cast won't do anything to
> deal with the possibility of that kind of error.

Example below.  Yes, it's contrived.  I think all examples will be
contrived because I think the case is very weak (I'm not making the
case, just illustrating it).

>> ... 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.
>
> All they're checking is whether they can remember what type pa has; why
> check that? The idiom shown completely removes the need to remember what
> the type is; with that removal comes the freedom to change the type
> without any need to re-write this part of the code.

Agreed.  It's how I'd do it, but that's not my point.  I don't want to
simply add another voice to the side of the debate I support.  I want to
try to understand the other side so as to evaluate it's evidence.

>> 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.
>
> Please demonstrate how this can happen.

  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
   
  struct p2d { double coords[2]; };
  struct p3d { double coords[3]; };
   
  void unit(double *d, size_t n)
  {
       d[0] = 1;
       for (size_t i = 1; i < n; i++) d[i] = 0;
  }
   
  int main(void)
  {
       struct p2d *point = malloc(sizeof *point);
       unit(point->coords, 3);
       /* ... */
       free(point);
       return 0;
  }

The bug here is the typo on the declaration of point.

-- 
Ben.

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

#8856

On 07/28/2011 11:17 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> On 07/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. 
>>
>> Could you give us an example of such an error? That code fragment seems.
>> to me, to necessarily and inherently correctly allocate exactly room for
>> 50 elements of whatever type pa points at (assuming that later code
>> deals properly with the possibility that pa==NULL). The only error it
>> could contain is the 50, and inserting the cast won't do anything to
>> deal with the possibility of that kind of error.
> 
> Example below.  Yes, it's contrived.  I think all examples will be
> contrived because I think the case is very weak (I'm not making the
> case, just illustrating it).
> 
...
>>> 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.
>>
>> Please demonstrate how this can happen.
> 
>   #include <stdio.h>
>   #include <stdlib.h>
>   #include <string.h>
>    
>   struct p2d { double coords[2]; };
>   struct p3d { double coords[3]; };
>    
>   void unit(double *d, size_t n)
>   {
>        d[0] = 1;
>        for (size_t i = 1; i < n; i++) d[i] = 0;
>   }
>    
>   int main(void)
>   {
>        struct p2d *point = malloc(sizeof *point);
>        unit(point->coords, 3);
>        /* ... */
>        free(point);
>        return 0;
>   }
> 
> The bug here is the typo on the declaration of point.

Yes, and explicitly converting the value returned by malloc would
probably not trigger a diagnostic, because the cast is fairly likely to
contain the same typo:

	struct p2d *point = (struct p2d*)malloc(sizeof *point);

If it didn't have such a typo in the first place, I would expect the
resulting diagnostic to cause it to be "corrected" to match the declaration.
-- 
James Kuyper

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

#8865

James Kuyper <jameskuyper@verizon.net> writes:

> On 07/28/2011 11:17 PM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> 
>>> On 07/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. 
>>>
>>> Could you give us an example of such an error? That code fragment seems.
>>> to me, to necessarily and inherently correctly allocate exactly room for
>>> 50 elements of whatever type pa points at (assuming that later code
>>> deals properly with the possibility that pa==NULL). The only error it
>>> could contain is the 50, and inserting the cast won't do anything to
>>> deal with the possibility of that kind of error.
>> 
>> Example below.  Yes, it's contrived.  I think all examples will be
>> contrived because I think the case is very weak (I'm not making the
>> case, just illustrating it).
>> 
> ...
>>>> 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.
>>>
>>> Please demonstrate how this can happen.
>> 
>>   #include <stdio.h>
>>   #include <stdlib.h>
>>   #include <string.h>
>>    
>>   struct p2d { double coords[2]; };
>>   struct p3d { double coords[3]; };
>>    
>>   void unit(double *d, size_t n)
>>   {
>>        d[0] = 1;
>>        for (size_t i = 1; i < n; i++) d[i] = 0;
>>   }
>>    
>>   int main(void)
>>   {
>>        struct p2d *point = malloc(sizeof *point);
>>        unit(point->coords, 3);
>>        /* ... */
>>        free(point);
>>        return 0;
>>   }
>> 
>> The bug here is the typo on the declaration of point.
>
> Yes, and explicitly converting the value returned by malloc would
> probably not trigger a diagnostic, because the cast is fairly likely to
> contain the same typo:
>
> 	struct p2d *point = (struct p2d*)malloc(sizeof *point);

The context was where the declaration and the allocation are split.
That's not uncommon but I could not reasonably reproduce that in a small
example.

> If it didn't have such a typo in the first place, I would expect the
> resulting diagnostic to cause it to be "corrected" to match the
> declaration.

All I am doing is providing the example you asked for.

-- 
Ben.

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

#8906

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

> Of course, had you written
>
> pa = malloc(50 * sizeof *pa);

Gosh, if only I'd known that, I could have explicitly mentioned it in my
original post, and you wouldn't have felt it necessary to "correct" me.

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

#8911

On 07/31/2011 04:19 AM, Gareth Owen wrote:
> Angel <angel+news@spamcop.net> writes:
> 
>> Of course, had you written
>>
>> pa = malloc(50 * sizeof *pa);
> 
> Gosh, if only I'd known that, I could have explicitly mentioned it in my
> original post, and you wouldn't have felt it necessary to "correct" me.

My news server lists 3 prior messages of yours on this thread. Neither
the first one, nor the one Angel was responding to, mention that idiom.
The only one that does mentions it, does so only briefly and
dismissively. I think Angel can be forgiven for not having noticed that
you were aware of that idiom, particularly since your arguments seem to
be those of someone who doesn't fully understand the advantages of that
idiom.
-- 
James Kuyper

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

#8941

James Kuyper <jameskuyper@verizon.net> writes:

> I think Angel can be forgiven for not having noticed that you were
> aware of that idiom, particularly since your arguments seem to be
> those of someone who doesn't fully understand the advantages of that
> idiom.

I understand it fully, thanks.  But thanks for patronising me anyway.  
One can never get enough of *that* on comp.lang.c

"If you don't agree with me, you don't understand" is not a syllogism.

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

#8947

On 08/02/2011 01:56 AM, Gareth Owen wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> I think Angel can be forgiven for not having noticed that you were
>> aware of that idiom, particularly since your arguments seem to be
>> those of someone who doesn't fully understand the advantages of that
>> idiom.
...
> "If you don't agree with me, you don't understand" is not a syllogism.

True. But I wasn't attempting syllogism, nor was I using that argument.
The reasoning I was using could be more accurately summarized as "You
say things which seem to me to be inconsistent with having correctly
understood this" => "You probably don't understand this". The words
"seem" and "probably" indicate the inherent uncertainty that is present
in all discussions in the real world. Syllogism requires at least a
pretense of certainty which can never be justifiable when discussing
real world issues.

Of course, my judgment of what is "correct" is based upon my own
understanding of the topic; but I have no choice about that - I'm stuck
in my own head, I can't use anyone else's understanding for evaluating
the correctness of your statements, I can only use my own. If I'd
thought, as you apparently do, that this is just a subjective issue of
style, rather than an objective issue of functionality, I would not have
even bothered mentioning it. If I had had any serious doubts about the
accuracy of my understanding of this issue, I'd be correspondingly less
judgmental of your misunderstanding. I appreciate that you think I
should have such doubts, but you've presented no arguments sufficiently
convincing to give me any.
-- 
James Kuyper

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

#8806

On 07/28/2011 07:24 AM, gwowen wrote:
...
> 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!
...
> 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
...
> 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.

Writing your code to remove the unnecessary assumption is better:

	pa = malloc(50*sizeof *pa);

Once you've done it right, the cast only gets in the way.
-- 
James Kuyper

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

#8816

On 7/28/2011 7:24 AM, gwowen wrote:
> 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.

Only if you pass the wrong value to malloc().  Pass the correct value, and 
the entire malloc() statement can be left untouched.

> Which it does, but changing types is bug prone.  Your "objection" is
> completely orthogonal to that point.

Not really.  You said the cast is there specifically to give you a compiler 
error.  (I get a warning.  So be it.)  So, "fix" the error by "fixing" the cast.

It's still broken, because the cast is a distraction from the really 
problem, which is the incorrect parameter to malloc.

> 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!

"Right", as long as pa points to an int.

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

Why not code it without the assumption that it's an "int*"?

pa = malloc(50*sizeof(*pa));  /* Right, regardless of what pa points to. */

-- 
Kenneth Brody

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

#8738

In <6e8108d6-cf53-4d7c-940d-8a0dcad1315b@y24g2000yqb.googlegroups.com> gwowen <gwowen@gmail.com> writes:

> > Don't cast the return value of malloc.  There's no need, and it can
> > hide errors later on if you change the type of pa but forget to change
> > the cast.

> Please don't give (distinctly debatable) style tips as if they were
> hard and fast rules.  Not casting malloc has both benefits and
> drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> demonstrate incomplete understanding.

I am unaware that casting malloc has any benefits at all.  Please
elaborate.

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

#8762

On Jul 26, 3:58 pm, John Gordon <gor...@panix.com> wrote:

> I am unaware that casting malloc has any benefits at all.  Please
> elaborate.

(and James Kuyper and Kenneth Brody asked similar things)

1) As Kenneth Brody has pointed out, it means your code will work with
an ancient compiler in which malloc returns a char *.

2) It means that the code doesn't need to be re-written should you
wish to treat it as C++ code.

3) Some programmers just feel it is "wrong" to assign a value of one
type to a variable of another, and this will make them feel happier
about the code. I presume there are no program checking tools which
feel likewise, though this would help if there were.

So that's three arguable benefits, though there is obviously a strong
argument that they are outweighed by the benefits of not casting.

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

#8766

On Jul 26, 10:56 pm, Paul N <gw7...@aol.com> wrote:
> On Jul 26, 3:58 pm, John Gordon <gor...@panix.com> wrote:


> > I am unaware that casting malloc has any benefits at all.  Please
> > elaborate.
>
> (and James Kuyper and Kenneth Brody asked similar things)
>
> 1) As Kenneth Brody has pointed out, it means your code will work with
> an ancient compiler in which malloc returns a char *.
>
> 2) It means that the code doesn't need to be re-written should you
> wish to treat it as C++ code.

if you're in one of those environemtns then so be it.

> 3) Some programmers just feel it is "wrong" to assign a value of one
> type to a variable of another, and this will make them feel happier
> about the code.

I'd say the programmer needed debugging...


> I presume there are no program checking tools which
> feel likewise,

if there are they should be cast into the Outer Darkness. Sounds like
a very broken lint.


> though this would help if there were.

how does a tool that generates spurious "errors" help anyone?


> So that's three arguable benefits,

two weird environments and a programwer that needs re-education

> though there is obviously a strong
> argument that they are outweighed by the benefits of not casting.

yay!

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

#8773

On 07/26/2011 05:56 PM, Paul N wrote:
> On Jul 26, 3:58�pm, John Gordon <gor...@panix.com> wrote:
> 
>> I am unaware that casting malloc has any benefits at all. �Please
>> elaborate.
> 
> (and James Kuyper and Kenneth Brody asked similar things)
> 
> 1) As Kenneth Brody has pointed out, it means your code will work with
> an ancient compiler in which malloc returns a char *.

Yes, those compilers are ancient. The standard which changed that was
approved before the latest crop of computer programmers was even born. I
stopped worrying about compatibility with pre-standard compilers nearly
two decades ago.

> 2) It means that the code doesn't need to be re-written should you
> wish to treat it as C++ code.

True, but that's not a C issue.

> 3) Some programmers just feel it is "wrong" to assign a value of one
> type to a variable of another, and this will make them feel happier
> about the code. I presume there are no program checking tools which
> feel likewise, though this would help if there were.

If they're right, arguments supporting the idea that they're right would
be relevant; the fact that they feel that way is irrelevant. If they're
wrong, as I believe them to be, the right solution is the re-education
of or the choice of an alternative career by those programmers, not
unnecessary casts.

The whole point of using void* rather than char* (when it's appropriate
to do so) is the implicit conversions to and from other pointer types.
Making those conversions implicit simplifies code like this by not
mandating casts that don't buy any real advantage. Anyone who thinks
that's a bad idea should probably consider writing a bunch of wrapper
functions for those standard library functions which use void*. Then any
use of my_malloc() without a cast, for any purpose other than filling in
a char*, would guarantee the pointless diagnostic they crave.
-- 
James Kuyper

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

#8774

On Jul 27, 12:28 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 07/26/2011 05:56 PM, Paul N wrote:
>
> > On Jul 26, 3:58 pm, John Gordon <gor...@panix.com> wrote:
>
> >> I am unaware that casting malloc has any benefits at all. Please
> >> elaborate.
>
> > (and James Kuyper and Kenneth Brody asked similar things)
>
> > 1) As Kenneth Brody has pointed out, it means your code will work with
> > an ancient compiler in which malloc returns a char *.
>
> Yes, those compilers are ancient. The standard which changed that was
> approved before the latest crop of computer programmers was even born. I
> stopped worrying about compatibility with pre-standard compilers nearly
> two decades ago.

I made a change to a K&R program about 12 months ago. My first time!

<snip>

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

#8781

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The whole point of using void* rather than char* (when it's appropriate
> to do so) is the implicit conversions to and from other pointer types.
[...]

It's not the *whole* point.  Another point (I'd argue a more
important one) is that any pointer value (other than a function
pointer) can be converted to void* and back again without loss
of information.  That would be quite useful even if conversions to
and from void* had to be explicit.

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

#8793

On 07/27/2011 11:24 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> The whole point of using void* rather than char* (when it's appropriate
>> to do so) is the implicit conversions to and from other pointer types.
> [...]
> 
> It's not the *whole* point.  Another point (I'd argue a more
> important one) is that any pointer value (other than a function
> pointer) can be converted to void* and back again without loss
> of information.  That would be quite useful even if conversions to
> and from void* had to be explicit.

The property you describe is also mandated for char*, as a side-effect
of char* being required to have the same representation as void*.
Therefore, that property is not a reason for using void* rather than
char*. If void* had never been invented, the standard could have
assigned that property to char* directly. I'm sure that char* already
had that property on most, if not all, pre-standard C compilers.

-- 
James Kuyper

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

#8847

James Kuyper <jameskuyper@verizon.net> writes:

> On 07/27/2011 11:24 AM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> The whole point of using void* rather than char* (when it's appropriate
>>> to do so) is the implicit conversions to and from other pointer types.
>> [...]
>> 
>> It's not the *whole* point.  Another point (I'd argue a more
>> important one) is that any pointer value (other than a function
>> pointer) can be converted to void* and back again without loss
>> of information.  That would be quite useful even if conversions to
>> and from void* had to be explicit.
>
> The property you describe is also mandated for char*, as a side-effect
> of char* being required to have the same representation as void*.
> [snip]

The conclusion is right, but the reasoning is wrong.  For
example, all pointers to struct types have the same
representation and alignment requirements, but converting an
address to 'struct foo *' can fail even if converting the
same address to a 'struct bas *' is guaranteed to succeed.

Now I'm sure someone will be happy to explain which parts of
the Standard /do/ guarantee that an (non-function) pointer
value can be converted to char* and back.  (Put this down
to me being too la^H^H^H busy to look up the particular
passages.)

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

#8845

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

> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> The whole point of using void* rather than char* (when it's appropriate
>> to do so) is the implicit conversions to and from other pointer types.
> [...]
>
> It's not the *whole* point.  Another point (I'd argue a more
> important one) is that any pointer value (other than a function
> pointer) can be converted to void* and back again without loss
> of information.  [snip]

The same is true of char*.

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

#8896

On 07/27/2011 09:24 AM, Keith Thompson wrote:
> James Kuyper<jameskuyper@verizon.net>  writes:
> [...]
>> The whole point of using void* rather than char* (when it's appropriate
>> to do so) is the implicit conversions to and from other pointer types.
> [...]
>
> It's not the *whole* point.  Another point (I'd argue a more
> important one) is that any pointer value (other than a function
> pointer) can be converted to void* and back again without loss
> of information.  That would be quite useful even if conversions to
> and from void* had to be explicit.
>

Keith, am I hallucinating that you told me that all the C standard said 
of fortran was that it was a common extension?

As I recall there were two different paragraphs where fortan was mentioned.

All I see now is a reference to the fortran keyword.  3 times in the 
same paragraph.

If fortran isn't a common extension, what is?
-- 
Uno

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

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

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

csiph-web