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

#8703 — is there anything unstandard in the c part here

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.

It starts with fortran the common C extension:

$ pwd
/home/dan/source/fortran_stuff
$  gcc -c -Wall -Wextra cfunc2.c -o cfunc.o
$ gfortran -c  -Wall -Wextra caller2.f03 -o caller.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.

Those were the compilation commands and output.

$ cat caller2.f03
program test
use iso_c_binding
implicit none
interface
function testc() bind(c) result(pa)
use iso_c_binding
type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(:)
pa = testc()
call c_f_pointer(pa, fpa, [50])
print*, fpa(1:50)
end program test
! gfortran -c  -Wall -Wextra caller2.f03 -o caller.o
! gfortran -Wall -Wextra caller.o testc.o -o out
$

Fortran pointers and C pointers aren't the same thing at all.  With the 
c part I compiled with non-standard headers, but I didn't need them, so 
I'll re-order them, and then everything below that purports to be 
standard C:

$ cat cfunc2.c


#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

#define RIGHT HERE

#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>

char * testc() {

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

     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,
-- 
Uno

[toc] | [next] | [standalone]

#8704

In <996dhnFhnlU1@mid.individual.net> Uno <Uno@example.invalid> writes:

> char * testc() {

If testc() doesn't take any arguments, then spell it out explicitly:

  char *testc(void)

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

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.

>      strcpy((char *)pa, "this sentence is less than fifty bytes.");

Why are you casting pa to a char pointer when it already is one?

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

#8722

On Jul 26, 12:53 am, John Gordon <gor...@panix.com> wrote:
>   char *testc(void)
>
> >      char * pa;
> >      pa = (char *)malloc (50);
>
> 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.

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

#8734

On Jul 26, 4:50 am, gwowen <gwo...@gmail.com> wrote:
> On Jul 26, 12:53 am, John Gordon <gor...@panix.com> wrote:
>
> >   char *testc(void)
>
> > >      char * pa;
> > >      pa = (char *)malloc (50);
>
> > 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.

In C you do not need to cast void* to any other pointer type.
Specifically casting it to silence warnings shows you're doing
something wrong.  By default the compiler will think that malloc
returns "int" which in many cases is not the same size [or more
importantly castable] as a pointer.

I'd also point out this is something trolls question repeatedly to get
a rise out of the regulars [who aren't trolls, I'd argue the trolls
are also part of the set of regulars, just not the helpful subset].

Tom

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

#8740

On 7/26/2011 9:17 AM, tom st denis wrote:
[...]
> In C you do not need to cast void* to any other pointer type.
> Specifically casting it to silence warnings shows you're doing
> something wrong.  By default the compiler will think that malloc
> returns "int" which in many cases is not the same size [or more
> importantly castable] as a pointer.
[...]

More importantly still are those platforms with separate "data" and 
"address" registers, on which a pointer value is returned on a totally 
distinct register than an integer value.  On such platforms, it's not just 
that the value it sees can't be properly cast to a pointer, but it's looking 
in the wrong place to begin with.

-- 
Kenneth Brody

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

#8754

On Jul 26, 11:08 am, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 7/26/2011 9:17 AM, tom st denis wrote:
> [...]> In C you do not need to cast void* to any other pointer type.
> > Specifically casting it to silence warnings shows you're doing
> > something wrong.  By default the compiler will think that malloc
> > returns "int" which in many cases is not the same size [or more
> > importantly castable] as a pointer.
>
> [...]
>
> More importantly still are those platforms with separate "data" and
> "address" registers, on which a pointer value is returned on a totally
> distinct register than an integer value.  On such platforms, it's not just
> that the value it sees can't be properly cast to a pointer, but it's looking
> in the wrong place to begin with.

Also a good point ya.

Generally speaking I don't get why they insist on bringing it up over
and over.  Header files took me all of no time to learn when I was
teaching myself the very basics of C when I was 10.  Admittedly I
wasn't a developer then, but it wasn't exactly rocket surgery to
realize "oh wait, I need to include the definition of the function
with a header so the compiler knows how the function call works..."

Usually if I don't have it memorized I just read the man page.  Takes
me three seconds to look up a C function and I'm on my way.

Oddly enough the time these people save by writing quick and dirty
code they usually lose in multiple-fold by having to debug it later...

Tom

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

#8765

On Jul 26, 6:51 pm, tom st denis <t...@iahu.ca> wrote:
> On Jul 26, 11:08 am, Kenneth Brody <kenbr...@spamcop.net> wrote:
>
> > On 7/26/2011 9:17 AM, tom st denis wrote:
> > [...]> In C you do not need to cast void* to any other pointer type.
> > > Specifically casting it to silence warnings shows you're doing
> > > something wrong.  By default the compiler will think that malloc
> > > returns "int" which in many cases is not the same size [or more
> > > importantly castable] as a pointer.
>
> > [...]
>
> > More importantly still are those platforms with separate "data" and
> > "address" registers, on which a pointer value is returned on a totally
> > distinct register than an integer value.  On such platforms, it's not just
> > that the value it sees can't be properly cast to a pointer, but it's looking
> > in the wrong place to begin with.
>
> Also a good point ya.
>
> Generally speaking I don't get why they insist on bringing it up over
> and over.  Header files took me all of no time to learn when I was
> teaching myself the very basics of C when I was 10.  Admittedly I
> wasn't a developer then, but it wasn't exactly rocket surgery to
> realize "oh wait, I need to include the definition of the function
> with a header so the compiler knows how the function call works..."
>
> Usually if I don't have it memorized I just read the man page.  Takes
> me three seconds to look up a C function and I'm on my way.
>
> Oddly enough the time these people save by writing quick and dirty
> code they usually lose in multiple-fold by having to debug it later...

I always thought it should have been an error diagnosed by the
compiler- to not have a prototype in scope.

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

#8786

On 7/27/2011 3:08 AM, Nick Keighley wrote:
[...]
> I always thought it should have been an error diagnosed by the
> compiler- to not have a prototype in scope.

I'm sure many C compilers have that option.  For example, Microsoft's C 
compiler has the obvious "/we4013" flag to make such a thing a fatal error 
rather than just a warning.

My guess is that there is too much "legacy code" around w/o prototypes that 
would break if compilers were forced to generate an error.

-- 
Kenneth Brody

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

#8800

On 2011-07-27, Kenneth Brody <kenbrody@spamcop.net> wrote:
> On 7/27/2011 3:08 AM, Nick Keighley wrote:
> [...]
>> I always thought it should have been an error diagnosed by the
>> compiler- to not have a prototype in scope.
>
> I'm sure many C compilers have that option.  For example, Microsoft's C 
> compiler has the obvious "/we4013" flag to make such a thing a fatal error 
> rather than just a warning.
>
> My guess is that there is too much "legacy code" around w/o prototypes that 
> would break if compilers were forced to generate an error.

At the request of a friend, I've lately been trying to get some legacy
code to work with modern toolchains. The results were... interesting, in
the same sense that train wrecks are interesting.

To protect my own sanity, I sadly had to tell my friend I could not help
him.


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

#8808

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

> On 2011-07-27, Kenneth Brody <kenbrody@spamcop.net> wrote:
>> On 7/27/2011 3:08 AM, Nick Keighley wrote:
>> [...]
>>> I always thought it should have been an error diagnosed by the
>>> compiler- to not have a prototype in scope.
>>
>> I'm sure many C compilers have that option.  For example, Microsoft's C 
>> compiler has the obvious "/we4013" flag to make such a thing a fatal error 
>> rather than just a warning.
>>
>> My guess is that there is too much "legacy code" around w/o prototypes that 
>> would break if compilers were forced to generate an error.
>
> At the request of a friend, I've lately been trying to get some legacy
> code to work with modern toolchains. The results were... interesting, in
> the same sense that train wrecks are interesting.

Did you use legacy compiler options or try to get it through with
something more modern like -std=c90?  I've have old code (c1985) compile
and work first time.  I'd be interested to hear what seemed to be the
main sticking point.

<snip>
-- 
Ben.

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

#8783

On 7/26/2011 1:51 PM, tom st denis wrote:
> On Jul 26, 11:08 am, Kenneth Brody<kenbr...@spamcop.net>  wrote:
>> On 7/26/2011 9:17 AM, tom st denis wrote:
[... Unnecessary casting ...]
>>
>> More importantly still are those platforms with separate "data" and
>> "address" registers, on which a pointer value is returned on a totally
>> distinct register than an integer value.  On such platforms, it's not just
>> that the value it sees can't be properly cast to a pointer, but it's looking
>> in the wrong place to begin with.
>
> Also a good point ya.

BTDTGTTS.  I had the good fortune that the second platform[1] on which I 
used C was 68000-based, which did as I described above.

> Generally speaking I don't get why they insist on bringing it up over
> and over.  Header files took me all of no time to learn when I was
> teaching myself the very basics of C when I was 10.  Admittedly I
[...]

Some people don't want to learn.

[...]
> Oddly enough the time these people save by writing quick and dirty
> code they usually lose in multiple-fold by having to debug it later...

Perhaps "all the world's an x86-based Windows box"?


[1] The first being a CP/M system, which we got to "play" with while waiting 
for the "real" *nix system to arrive.

-- 
Kenneth Brody

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

#8801

On 2011-07-27, Kenneth Brody <kenbrody@spamcop.net> wrote:
>
> Perhaps "all the world's an x86-based Windows box"?

Considering all the issues I encountered with various packages when I
migrated from x86 to x86_64, I'd say that yes, there are a lot of
amateur programmmers who think that way. (I admit having been guilty of
that myself.)

Let's not even go into porting code to systems with a different
endianness, like Sparc or PowerPC... :-(


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

#8815

On 7/28/2011 7:07 AM, Angel wrote:
> On 2011-07-27, Kenneth Brody<kenbrody@spamcop.net>  wrote:
>>
>> Perhaps "all the world's an x86-based Windows box"?
>
> Considering all the issues I encountered with various packages when I
> migrated from x86 to x86_64, I'd say that yes, there are a lot of
> amateur programmmers who think that way. (I admit having been guilty of
> that myself.)
>
> Let's not even go into porting code to systems with a different
> endianness, like Sparc or PowerPC... :-(

Well, my first "real" C platform was a 32-bit big-endian 
returns-pointers-in-different-registers-than-numbers 68000 Unix box.  My 
second "real" C platform was a 16-bit little-endian 
has-different-code-pointers-than-data-pointers 8086 MS-DOS box.

I learned early on about maintaining portability between those sorts of things.

-- 
Kenneth Brody

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

#8836

 Angel  wrote:
> Kenneth Brody  wrote:
>>
>> Perhaps "all the world's an x86-based Windows box"?
>
>Considering all the issues I encountered with various packages when I
>migrated from x86 to x86_64, I'd say that yes, there are a lot of
>amateur programmmers who think that way. 

And many professionals too.  They were preceeded by the "All the world
is a VAX" crowd, begotten from the "All the world is a PDP-11" crowd.

Plus ça change, plus c'est la même chose...
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

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

#8735

On 07/26/2011 04:50 AM, gwowen wrote:
> On Jul 26, 12:53�am, John Gordon <gor...@panix.com> wrote:
>> � char *testc(void)
>>
>>> � � �char * pa;
>>> � � �pa = (char *)malloc (50);
>>
>> 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.

What are the drawbacks? I'm not familiar with any.
-- 
James Kuyper

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

#8764

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


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.

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.

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

#8772

On 07/27/2011 02: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.
> -----------------------------------------------------------------------------
> 
> 
> 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.

Well, no. If the missing cast were the the problem, then inserting an
(int*) would be the solution - in fact, the real problem would persist
even if an (int*) were inserted.

The change from (char*) to (int*) is not the solution, it's the problem.
If you have a policy of casting the value returned by malloc(), then you
have to modify the cast any time you change the type. It's a minor waste
of time, which doesn't come up very often. It would be easily
justifiable if it provided any corresponding benefit - but it provides
none. What needs to be matched up isn't the type, its the size, and you
can't do anything about that with a cast.

> Personally, when I accidentally write buggy code, I want a compiler
> error rather undefined behaviour. YMMV.

Nothing you can do in C will cause the real problem, the incorrect size
passed to malloc(), to be flagged as a compiler error. However, what you
can do is ensure that the size passed to malloc() is correct, regardless
of the type:

> Yes, I know all about the pa = malloc(50 * sizeof(*pa)) idiom, thanks,

So, in other words, you do know that the problem is not the "missing"
cast, but the argument passed to malloc().

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

There's style, and then there's functionality. Indentation is a pure
style issue; any consistently applied indentation style is workable, and
arguing over them is pointless. Unnecessarily casting the value returned
by malloc() is just a waste of time. However, passing the correct size
to malloc() is a functionality issue, not a size issue.
-- 
James Kuyper

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

#8775

Gareth Owen wrote:

> Lets look at the code (roughly) as given
> 
> char *pa;
> pa = (char*) malloc(50);
> /* code that presumably assumes 50 elements in pa[] */

"elements" is unnecessarily vague;
pa can (only) store 50 CHARACTERS,
(whether the cast is there or not.)

> 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;
> pa = (char*) malloc(50);
> /* code that presumably assumes 50 elements in pa[] */

The problem is to assume that pa can store anything else
but 50 CHARACTERS, since that is what was requested... o_O

So you go back to the assignment, and write what?

pa = (int *) malloc(50*4); // not portable

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

Why are you trying SO HARD to avoid the IDIOMATIC

pa = malloc(50 * sizeof *pa);

which doesn't require dicking around should you ever
want to modify pa's type?

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

#8779

In <87mxg01br8.fsf@gmail.com> Gareth Owen <gwowen@gmail.com> writes:

> With the cast
> -----------------------------------------------------------------------------
> int *pa;
> /* yadda yadda yadda */
> pa = (char*) malloc(50);
> /* code that presumably assumes 50 elements in pa[] */
> result: compiler error.

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

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

#8780

John Gordon <gordon@panix.com> writes:
> In <87mxg01br8.fsf@gmail.com> Gareth Owen <gwowen@gmail.com> writes:
>
>> With the cast
>> -----------------------------------------------------------------------------
>> int *pa;
>> /* yadda yadda yadda */
>> pa = (char*) malloc(50);
>> /* code that presumably assumes 50 elements in pa[] */
>> result: compiler error.
>
> 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.

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

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

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

csiph-web