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

#9036

On 08/05/2011 01:22 AM, Gareth Owen wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> Gareth Owen <gwowen@gmail.com> writes:
>>> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
...
>>>> I don't see how leaving out the cast can hide bugs.
>>>
>>> It can.
>>
>> Perhaps in very rare circumstances, far rarer than the circumstances in
>> which adding the cast can hide bugs.
> 
> Rarer, for you, probably.  In which case I heartily encourage you to
> continue with the style that works for you. But it is a balance, and in
> such issues of *style* people can hold the other view.  Which was, after
> all, my original point.

Whether or not it can hide bugs isn't a style issue; it a matter of
fact, either true or false, and your naked assertion that it can isn't
sufficient to prove it true. Can you provide an example of such a bug?
The only examples you've given so far are ones where the bug would have
remained even a cast had been inserted to matching the destination
pointer type.
-- 
James Kuyper

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

#9329

James Kuyper <jameskuyper@verizon.net> writes:

> The only examples you've given so far are ones where the bug would
> have remained even a cast had been inserted to matching the
> destination pointer type.

But that's the *point*.  

If you change the destination pointer at some distant code point (in a
header file say) the cast does not change.  So the code won't compile
and the runtime disaster is avoided.  

Now, you can assert "that can't happen", but it has happened.  I've seen
it happen. Someone codes something a malloc on the assumption the
pointer type is a char*, and omits the sizeof() because sizeof(char) is
1, and then the pointer type changes at some later date - to a wchar*,
say - and the malloc() is wrong.

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

#9337

On 08/13/2011 03:05 AM, Gareth Owen wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> The only examples you've given so far are ones where the bug would
>> have remained even a cast had been inserted to matching the
>> destination pointer type.
> 
> But that's the *point*.  
> 
> If you change the destination pointer at some distant code point (in a
> header file say) the cast does not change.  So the code won't compile
> and the runtime disaster is avoided.  

Let me review what we've been discussing, since the context has been
dropped along the way. The original claim was that leaving out the cast
hides an error. A simple example would be:

	char *p;

	// somewhere else, possibly not even in the same file:
	p = malloc(count);

At some later time, the declaration is changed:

	wchar *p;

Now there is certainly an error in the malloc() statement. However, the
absence of the cast doesn't hide the error; the error is in the argument
of malloc(), and it remains hidden even after inserting an unnecessary cast:

	p = (wchar*)malloc(count);

You could use the following kludge to "fix" the real problem:

	p = (wchar*)malloc(count * sizeof(wchar));

I believe that the point you're trying to raise is that the cast
automatically creates a diagnosable error if the type of *p changes
again. That will serve to remind you to fix the real error, which is in
the argument of malloc(), and which the compiler cannot diagnose.
However, why use such a kludge in the first place? With that approach
the line needs to be edited any time the type changes. The right way to
fix it is:

	p = malloc(count * sizeof *p);

Then if we were to change the type of p once again, say to allow storage
of UTF-32 values:

	unsigned long *p;

then the "missing" cast would not hide any errors, because there would
be no error to be hidden. The argument of malloc(), which was the real
problem in previous versions of this code, will automatically adjust to
match changes in the type of *p. The statement does not need to edited,
because it remains correct. The fact that it is correct can be verified
simply by looking only at the statement itself, without even knowing the
type of *p, a fact which is directly connected to the fact that the
statement doesn't need to be changed.

> Now, you can assert "that can't happen", but it has happened.  I've seen
> it happen. Someone codes something a malloc on the assumption the
> pointer type is a char*, and omits the sizeof() because sizeof(char) is
> 1, and then the pointer type changes at some later date - to a wchar*,
> say - and the malloc() is wrong.

I never claimed that something like what you describe couldn't happen;
we merely disagree on what the problem is, and therefore, on what the
right solution is. The problem not a missing cast, and it is not
properly fixed by using sizeof(char). The right fix is sizeof *p, which
completely eliminates any need for a cast.

Let me redefine the challenge somewhat: can you demonstrate a case where
the right idiom ( count * sizeof *p ) is used, where leaving out the
cast hides an error, an error that would  no longer be hidden if the
appropriate cast were inserted?
-- 
James Kuyper

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

#9340

Gareth Owen <gwowen@gmail.com> writes:

> James Kuyper <jameskuyper@verizon.net> writes:
>
>> The only examples you've given so far are ones where the bug would
>> have remained even a cast had been inserted to matching the
>> destination pointer type.
>
> But that's the *point*.  
>
> If you change the destination pointer at some distant code point (in a
> header file say) the cast does not change.  So the code won't compile
> and the runtime disaster is avoided.  

This goes round and round, in part because two issues keep getting mixed
up.  I, for  one, would happily accept that this:

  p = (T *)malloc(sizeof (T));

is better than this:

  p = malloc(sizeof (T));

but that's just because that way of writing the size is so buggy that
there is a lot of room for improvement.

You've made no arguments about the way the size is written so,
presumably, you accept that using the pointer itself to determine this
size indeed better.  In that context the argument is only about the
difference between this:

  p = (T *)malloc(sizeof *p);

and this:

  p = malloc(sizeof *p);

Here a change of type does not affect the correctness and avoids need to
make any edits at all.

> Now, you can assert "that can't happen", but it has happened.  I've seen
> it happen. Someone codes something a malloc on the assumption the
> pointer type is a char*, and omits the sizeof() because sizeof(char) is
> 1, and then the pointer type changes at some later date - to a wchar*,
> say - and the malloc() is wrong.

This is because the size has been written the wrong way.  I.e. the cast
helps buggy code to be less buggy.  If the correct idiom is used for the
size, the cast becomes an annoyance.

You may remember that I've posted an example of code with a bug where
the cast catches it and the "preferred" idiom does not, so I am not
being dogmatic here.  The point is not "what happens" but how often the
various kinds of bug occur and how well different idioms cope with these
bugs.  In my experience, cases where a cast helps are rare compared to
ones where it hinders.  I suspect you have seen a lot of code where the
size expression is badly written so you think the cast is helping, but
the error is in the size expression and correcting that renders the
cast, at best, pointless.

-- 
Ben.

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

#8964

On 8/2/2011 1:58 AM, Gareth Owen wrote:
> Nick Keighley<nick_keighley_nospam@hotmail.com>  writes:
[...]
>> I don't see how leaving out the cast can hide bugs.
>
> It can.

Example, please?

-- 
Kenneth Brody

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

#9135

On Aug 2, 5:58 pm, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 8/2/2011 1:58 AM, Gareth Owen wrote:
>
> > Nick Keighley<nick_keighley_nos...@hotmail.com>  writes:
> [...]
> >> I don't see how leaving out the cast can hide bugs.
>
> > It can.
>
> Example, please?

I must learn to be more direct. When I say "I don't see how leaving
out the cast can hide bugs" I actually mean "explain how leaving out
the cast can hide bugs"

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

#9141

On 08/10/2011 04:31 AM, Nick Keighley wrote:
> On Aug 2, 5:58�pm, Kenneth Brody <kenbr...@spamcop.net> wrote:
>> On 8/2/2011 1:58 AM, Gareth Owen wrote:
>>
>>> Nick Keighley<nick_keighley_nos...@hotmail.com> �writes:
>> [...]
>>>> I don't see how leaving out the cast can hide bugs.
>>
>>> It can.
>>
>> Example, please?
> 
> I must learn to be more direct. When I say "I don't see how leaving
> out the cast can hide bugs" I actually mean "explain how leaving out
> the cast can hide bugs"

Being more direct won't help. He's been repeatedly asked to provide an
example, and so far the only bug he's presented would have remained a
bug, and remained hidden, even after the cast was "corrected", so it was
clearly not the cast which was hiding the bug.
-- 
James Kuyper

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

#9330

James Kuyper <jameskuyper@verizon.net> writes:

> Being more direct won't help. He's been repeatedly asked to provide an
> example, and so far the only bug he's presented would have remained a
> bug, and remained hidden, even after the cast was "corrected", so it was
> clearly not the cast which was hiding the bug.

Stop being a dick, James. The bug becomes a compile time error.

float * foo;
// elision
foo = (float*) malloc(256*sizeof(float));

becomes

double * foo;
foo = (float*) malloc(256*sizeof(float));

Compile time error. Do you really think someone would fix that compile
time error by changing *JUST THE CAST*? 

foo = (float*)  malloc(256*sizeof(float));
foo = (double*) malloc(256*sizeof(float));

"Ohh, the bug is still there."  Yes it is, because you've sent a moron
to fix it, who doesn't look at the context of the code, and who thinks
type safety is just fixing casts and hoping for the best.

Do you really believe that's how to use the idiom for defensive
programming?  Nice strawman. The point is, the cast is working as a
static assertion, flagging the assumption made within size calculation.
The fix is not to change the assertion until you've changed the
calculation.

double * foo;
// elision
foo = malloc(256*sizeof(float));

Nasal demons.

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

#9334

"Gareth Owen" <gwowen@gmail.com> ha scritto nel messaggio
news:87k4ahbx5h.fsf@gmail.com...
> James Kuyper <jameskuyper@verizon.net> writes:
>
>> Being more direct won't help. He's been repeatedly asked to provide an
>> example, and so far the only bug he's presented would have remained a
>> bug, and remained hidden, even after the cast was "corrected", so it was
>> clearly not the cast which was hiding the bug.
>
> Stop being a dick, James. The bug becomes a compile time error.
>
> float * foo;
> // elision
> foo = (float*) malloc(256*sizeof(float));
>
> becomes
>
> double * foo;
> foo = (float*) malloc(256*sizeof(float));
>
> Compile time error. Do you really think someone would fix that compile
> time error by changing *JUST THE CAST*?
>
> foo = (float*)  malloc(256*sizeof(float));
> foo = (double*) malloc(256*sizeof(float));

yes it seem to me i understand so could be ok use cast too
[so one see what is the type foo, check the memory allocation is ok
under the check of the compiler too]

> "Ohh, the bug is still there."  Yes it is, because you've sent a moron
> to fix it, who doesn't look at the context of the code, and who thinks
> type safety is just fixing casts and hoping for the best.
>
> Do you really believe that's how to use the idiom for defensive
> programming?  Nice strawman. The point is, the cast is working as a
> static assertion, flagging the assumption made within size calculation.
> The fix is not to change the assertion until you've changed the
> calculation.
>
> double * foo;
> // elision
> foo = malloc(256*sizeof(float));
>
> Nasal demons.

for what i think, you can write it as
mov  eax,  256*4 ; has to be 256*8 here
push  eax
call  _malloc
pop   edx

without cast without all
the problem goes out the same if you have a tool
that check if memory is write out the bounds
[if "the bounds" are written]

i think hll have their use for use less chars
on call functions on complex data type

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

#9338

On 08/13/2011 03:14 AM, Gareth Owen wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> Being more direct won't help. He's been repeatedly asked to provide an
>> example, and so far the only bug he's presented would have remained a
>> bug, and remained hidden, even after the cast was "corrected", so it was
>> clearly not the cast which was hiding the bug.
...
> Compile time error. Do you really think someone would fix that compile
> time error by changing *JUST THE CAST*? 
> 
> foo = (float*)  malloc(256*sizeof(float));
> foo = (double*) malloc(256*sizeof(float));

Not in this case, but in the case you described elsewhere:
> ... I've seen
> it happen. Someone codes something a malloc on the assumption the
> pointer type is a char*, and omits the sizeof() because sizeof(char) is
> 1,

I would expect that if someone was inexperienced enough to write code
like the following:

	p = (char*)malloc(count);

Then if they later change to wchar_t*, it's quite plausible that they'd
be inexperienced enough to respond to the error message by "correcting"
it as follows:

	p = (wchar_t*)malloc(count);

There right solution is

	p = malloc(count * sizeof(*p));

not
	p = (char*)malloc(count * sizeof(char));

-- 
James Kuyper

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

#9386

Gareth Owen wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> Being more direct won't help. He's been repeatedly asked to provide an
>> example, and so far the only bug he's presented would have remained a
>> bug, and remained hidden, even after the cast was "corrected", so it was
>> clearly not the cast which was hiding the bug.
> 
> Stop being a dick, James. The bug becomes a compile time error.
> 
> float * foo;
> // elision
> foo = (float*) malloc(256*sizeof(float));
> 
> becomes
> 
> double * foo;
> foo = (float*) malloc(256*sizeof(float));
> 
> Compile time error. Do you really think someone would fix that compile
> time error by changing *JUST THE CAST*? 

Err ... yes, certainly. I've seen exactly that done, many times, by many 
people.

> foo = (float*)  malloc(256*sizeof(float));
> foo = (double*) malloc(256*sizeof(float));
> 
> "Ohh, the bug is still there."  Yes it is, because you've sent a moron
> to fix it, who doesn't look at the context of the code, and who thinks
> type safety is just fixing casts and hoping for the best.

And because you had a moron write it in a way which wasn't safe in the 
first place, which caused the requirement for it to be "fixed" at all, 
and which included an unhelpful cast which distracted from the unsafe 
code which was the real problem.

> Do you really believe that's how to use the idiom for defensive
> programming?  Nice strawman. The point is, the cast is working as a
> static assertion, flagging the assumption made within size calculation.

If you can be certain that everyone who will ever work on this code in 
the future has been trained to know that an incompatible type warning is 
of course really an indication that the size of the allocation is wrong, 
then yes, it works in that way.

But why make and rely on that remarkable assumption when you can just 
write the allocation in a way which avoids it ever being wrong and ever 
needing to be changed if the type changes?

> The fix is not to change the assertion until you've changed the
> calculation.
> 
> double * foo;
> // elision
> foo = malloc(256*sizeof(float));
> 
> Nasal demons.

The fix is never to write allocations in such a silly way.

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

#9440

(Sorry, but there wasn't really anything to snip here.)

On 8/13/2011 3:14 AM, Gareth Owen wrote:
> James Kuyper<jameskuyper@verizon.net>  writes:
>
>> Being more direct won't help. He's been repeatedly asked to provide an
>> example, and so far the only bug he's presented would have remained a
>> bug, and remained hidden, even after the cast was "corrected", so it was
>> clearly not the cast which was hiding the bug.
>
> Stop being a dick, James. The bug becomes a compile time error.
>
> float * foo;
> // elision
> foo = (float*) malloc(256*sizeof(float));
>
> becomes
>
> double * foo;
> foo = (float*) malloc(256*sizeof(float));
>
> Compile time error. Do you really think someone would fix that compile
> time error by changing *JUST THE CAST*?
>
> foo = (float*)  malloc(256*sizeof(float));
> foo = (double*) malloc(256*sizeof(float));
>
> "Ohh, the bug is still there."  Yes it is, because you've sent a moron
> to fix it, who doesn't look at the context of the code, and who thinks
> type safety is just fixing casts and hoping for the best.
>
> Do you really believe that's how to use the idiom for defensive
> programming?  Nice strawman. The point is, the cast is working as a
> static assertion, flagging the assumption made within size calculation.
> The fix is not to change the assertion until you've changed the
> calculation.
>
> double * foo;
> // elision
> foo = malloc(256*sizeof(float));
>
> Nasal demons.

Sure, if you write code with the "put the type indicator in three times, and 
make sure to always keep them in sync" style, rather than the "write the 
code so the type is only specified once" style.

What's wrong with this:

    some_type *foo;
    ...
    foo = malloc(256*sizeof(*foo));

No matter what type you change foo to point to, the malloc line is 
guaranteed to allocate 256 of them.  (Or fail and return NULL, of course.)

-- 
Kenneth Brody

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

#9136

On Aug 2, 6:58 am, Gareth Owen <gwo...@gmail.com> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:

> > but on balance omitting the cast is the best option.
>
> For you, probably.  In which case I heartily encourage you to continue
> with the style that works for you. But it is a balance, and in such
> issues of *style* people can hold the other view.  Which was, after all,
> my original point.

In chess a draw is declared if a position is repeated a number of
times. I think this discussion has reached that point. I don't
consider it a mere matter of style but to have real concrete
consequences. IMNSHO the cast causes more problems than it solves.
People have explained them but; you seem unable to explain your "It
can [too].".

Have a nice day.

> > I don't see how leaving out the cast can hide bugs.
>
> It can.

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

#9331

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> IMNSHO the cast causes more problems than it solves.  People have
> explained them but; you seem unable to explain your "It can [too].".

I have, repeatedly. You seem unable to understand - but it's an open
question whose fault that is.  I'll take your zugzwang though.  

On matters of style, personal/corporate preference the only sensible
option - which was, I should note one more time, my original point.

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

#8706

On Mon, 25 Jul 2011 17:45:57 -0600, Uno <Uno@example.invalid> wrote:

>I'm doing a mixed-language exercise, and C is the middle east as far as 
>that goes.  So my listing is going to have non-standard parts,  I'll put 
>them at the top, so that people who chaff at the site of another syntax 
>won't have to retreat to under their bridges.

snip

>
>$ cat cfunc2.c
>
>
>#include <sys/types.h>
>#include <sys/stat.h>
>#include <unistd.h>

These are non-standard headers so you should be using the quotation
mark syntax instead of the angle bracket syntax.

>
>#define RIGHT HERE
>
>#include <stdio.h>
>#include <limits.h>
>#include <stdlib.h>
>#include <string.h>
>
>char * testc() {

  char *testc(void){
just looks cleaner.

>
>     char * pa;
>     pa = (char *)malloc (50);

The cast serves no purpose.

>     if (pa == NULL)
>       {
>      printf ("malloc failed.\n");
>      exit (EXIT_FAILURE);
>       }
>     strcpy((char *)pa, "this sentence is less than fifty bytes.");

This cast is redundant.

>
>     return pa;
>}
>
>// gcc -c -Wall -Wextra cfunc2.c -o cfunc.o
>
>I tried to follow Heathfield's development in chp 8 of _unleashed_ for 
>memory management.  For obvious reason, I don't free what I've 
>malloc'ed, because then it would suck as a pass.
>
>Any comments about the code south of RIGHT HERE are welcome.  Cheers,

-- 
Remove del for email

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

#8707

Barry Schwarz wrote:
> On Mon, 25 Jul 2011 17:45:57 -0600, Uno <Uno@example.invalid> wrote:
> 
>> I'm doing a mixed-language exercise, and C is the middle east as far as 
>> that goes.  So my listing is going to have non-standard parts,  I'll put 
>> them at the top, so that people who chaff at the site of another syntax 
>> won't have to retreat to under their bridges.
> 
> snip
> 
>> $ cat cfunc2.c
>>
>>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <unistd.h>
> 
> These are non-standard headers so you should be using the quotation
> mark syntax instead of the angle bracket syntax.

That's not correct. Since these headers are not part of the C Standard, 
C doesn't care which form of #include is used. As it happens, these are 
POSIX headers, and the POSIX standard requires the form used here.

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

#8709

On 2011-07-26, Barry Schwarz <schwarzb@dqel.com> wrote:
>>#include <sys/types.h>
>>#include <sys/stat.h>
>>#include <unistd.h>

> These are non-standard headers so you should be using the quotation
> mark syntax instead of the angle bracket syntax.

I would strongly disagree with this.  If headers are part of the local
system's implementation, rather than user-provided, they should be in
angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
ISO C", but for "stuff I am providing rather than my environment".

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#8711

On Jul 26, 7:17 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-07-26, Barry Schwarz <schwa...@dqel.com> wrote:
>
> >>#include <sys/types.h>
> >>#include <sys/stat.h>
> >>#include <unistd.h>
> > These are non-standard headers so you should be using the quotation
> > mark syntax instead of the angle bracket syntax.
>
> I would strongly disagree with this.  If headers are part of the local
> system's implementation, rather than user-provided, they should be in
> angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
> ISO C", but for "stuff I am providing rather than my environment".

yes but unix seems to disagree with you

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

#8712

On Jul 26, 9:03 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Jul 26, 7:17 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2011-07-26, Barry Schwarz <schwa...@dqel.com> wrote:
>
> > >>#include <sys/types.h>
> > >>#include <sys/stat.h>
> > >>#include <unistd.h>
> > > These are non-standard headers so you should be using the quotation
> > > mark syntax instead of the angle bracket syntax.
>
> > I would strongly disagree with this.  If headers are part of the local
> > system's implementation, rather than user-provided, they should be in
> > angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
> > ISO C", but for "stuff I am providing rather than my environment".
>
> yes but unix seems to disagree with you

?

Please elaborate.

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

#8713

On 07/26/11 07:03 PM, Nick Keighley wrote:
> On Jul 26, 7:17 am, Seebs<usenet-nos...@seebs.net>  wrote:
>> On 2011-07-26, Barry Schwarz<schwa...@dqel.com>  wrote:
>>
>>>> #include<sys/types.h>
>>>> #include<sys/stat.h>
>>>> #include<unistd.h>
>>> These are non-standard headers so you should be using the quotation
>>> mark syntax instead of the angle bracket syntax.
>>
>> I would strongly disagree with this.  If headers are part of the local
>> system's implementation, rather than user-provided, they should be in
>> angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
>> ISO C", but for "stuff I am providing rather than my environment".
>
> yes but unix seems to disagree with you

How?

-- 
Ian Collins

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

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

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

csiph-web