[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

is there anything unstandard in the c part here

Uno

7/25/2011 11:46:00 PM

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
124 Answers

John Gordon

7/25/2011 11:53:00 PM

0

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"

Barry Schwarz

7/26/2011 12:52:00 AM

0

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

J. J. Farrell

7/26/2011 1:10:00 AM

0

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.

Seebs

7/26/2011 6:17:00 AM

0

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.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Nick Keighley

7/26/2011 7:04:00 AM

0

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

Nick Keighley

7/26/2011 7:08:00 AM

0

On Jul 26, 12:45 am, Uno <U...@example.invalid> wrote:

> I'm doing a mixed-language exercise, and C is the middle east as far as
> that goes.

what does "in the middle east" mean? "has a long history"?


<snip>

> It starts with fortran the common C extension:

Fortran is not a C extension common or otherwise

<snip>

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

non-standard headers. That dont appear to be used.

> #define RIGHT HERE

what is this for?

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

Kleuskes & Moos

7/26/2011 7:09:00 AM

0

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.

Ian Collins

7/26/2011 7:44:00 AM

0

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

Seebs

7/26/2011 7:56:00 AM

0

On 2011-07-26, Nick Keighley <nick_keighley_nospam@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:
>> 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

Huh?

I've yet to see a Unix system not advocate <>s for the Unixy headers like
unistd.h and sys/*.h. I assume Windows is the same, and so on.

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

gwowen

7/26/2011 8:51:00 AM

0

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.