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

#8717

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

#8731

On Jul 26, 8:56 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-07-26, 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:

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

oops sorry! I misread the original post! *I* think things that are NOT
in the standard C++ (or C) should NOT be in angle brackets. Both unix
and windows disagree with my opinion.

Personnally I think this blurs the definition of environment. When is
a third party library "provided by the environemnt" and when is it
"provided by me"?

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

#8733

On 2011-07-26, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On Jul 26, 8:56?am, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> 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.
>
> oops sorry! I misread the original post! *I* think things that are NOT
> in the standard C++ (or C) should NOT be in angle brackets. Both unix
> and windows disagree with my opinion.
>
> Personnally I think this blurs the definition of environment. When is
> a third party library "provided by the environemnt" and when is it
> "provided by me"?

The line is a bit blurry of course, but consider where the library is
located. Is it part of your source code? Then it's provided by you and
"" should be used. If it is in a place that has nothing to do with your
source code, then it's provided by the environment.

I'm not sure about other implementations, but on Unix, <> will look only
in implementation-defined places (usually /usr/include) while "" will
look in the current directory first.


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

#8755

On 2011-07-26, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> oops sorry! I misread the original post! *I* think things that are NOT
> in the standard C++ (or C) should NOT be in angle brackets. Both unix
> and windows disagree with my opinion.

I think I do too.

> Personnally I think this blurs the definition of environment. When is
> a third party library "provided by the environemnt" and when is it
> "provided by me"?

This is all "implementation-defined".  To oversimplify standard Unix
considerably:

	/usr/include/foo.h => <foo.h>
	./foo.h            => "foo.h"

The basic idea is, if something is in the place where the compiler
automatically looks for all headers, it's <header.h>, and if it's somewhere
else (usually the current directory), it's "header.h".  This makes it
easy to decide; if I just wrote "foo.h", and it's in this directory, it gets
double quotes, if I expect "foo.h" to exist without this program having
to do anything specific about it, it gets angle brackets.

It might have been nice to have a third delimiter available so we could
distinguish between "language base" and "local extensions", but that was not
the way it was done.  The fact is, though, by the time the ANSI/ISO people
got involved, it had been <sys/types.h> for over a decade.

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

#8788

On Tue, 26 Jul 2011 04:50:58 -0700, Nick Keighley wrote:

> oops sorry! I misread the original post! *I* think things that are NOT
> in the standard C++ (or C) should NOT be in angle brackets. Both unix
> and windows disagree with my opinion.
> 
> Personnally I think this blurs the definition of environment. When is
> a third party library "provided by the environemnt" and when is it
> "provided by me"?

The C standard only says that using quotes results in the preprocessor
searching for the header file in additional (implementation-defined)
locations prior to the locations which are searched when angle brackets
are used.

"Typical" compiler behaviour when quotes are used is to search for the
header relative to the directory containing the source file. IOW, quotes
are intended for headers which are "part of" the program being compiled,
while angle brackets are for anything which is "external"

This means that you don't have to worry about "local" headers conflicting
with "installed" headers, as installed headers will be included using
angle brackets, and won't be searched for in the program's source
directory.

In large projects with multiple, distinct components, angle brackets may
be used for headers belonging to a different component. In general, if the
header is going to be installed as part of the "package", you have to
choose a name which won't conflict with any other installed package. OTOH,
if the header is "internal" and won't be installed, the name only needs to
be locally unique; including the header using quotes will ensure that it
gets used in spite of any external header of the same name.

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

#8732

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

???

From the manual page of the Unix system call open():


NAME
       open, creat - open and possibly create a file or device

SYNOPSIS
       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>

[...]


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

#8714

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

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

#8726

On 07/26/2011 03:07 AM, Nick Keighley wrote:
> On Jul 26, 12:45�am, Uno <U...@example.invalid> wrote:
...
>> #define RIGHT HERE
> 
> what is this for?

see below:

...
>> Any comments about the code south of RIGHT HERE are welcome. �Cheers,

A better way to do the same thing would have been to put RIGHT HERE is a
comment:

// RIGHT HERE
-- 
James Kuyper

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

#8795

On 07/26/2011 04:29 AM, James Kuyper wrote:
> On 07/26/2011 03:07 AM, Nick Keighley wrote:
>> On Jul 26, 12:45�am, Uno<U...@example.invalid>  wrote:
> ...
>>> #define RIGHT HERE
>>
>> what is this for?
>
> see below:
>
> ...
>>> Any comments about the code south of RIGHT HERE are welcome. �Cheers,
>
> A better way to do the same thing would have been to put RIGHT HERE is a
> comment:
>
> // RIGHT HERE

It was for editting, which might not be my strong suit.  I'm amazed at 
people who choose a secretarial function in deliberative bodies.  I see 
that I forgot to adios the 3 non-standard headers before I did this this 
next step, but who cares.

I took the cast off the malloc, got no warnings, got no bad behavior.

I took the cast off the strcpy, got no warnings got no bad behavior.

$ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.
$ echo "taking cast off malloc"
taking cast off malloc
$ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.
$ cat cfunc3.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <string.h>

char * testc() {

     char * pa;
     pa = 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 cfunc3.c -o cfunc.o
$ echo "taking cast off strcpy"
taking cast off strcpy
$ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.
$ cat cfunc3.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <string.h>

char * testc() {

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

     return pa;
}

// gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$

Now, got those headers gone, and I think we all agree that this function 
is standard C.  As far as me and my compiler can tell, so has every 
other idea as far as what to cast.

$ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.
$ cat cfunc3.c
// right here begins standard C

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

char * testc() {

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

     return pa;
}

// gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
$

This motivates--not begs--the question: what is the best practice?
-- 
Uno

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

#8802

Uno <Uno@example.invalid> writes:
<snip>
> $ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
> $ gfortran -Wall -Wextra caller.o testc.o -o out
> $ ./out
>  this sentence is less than fifty bytes.

There's no sign here that the program "out" uses the code in "cfunc3.c".
You might want to check that it really does.

<snip>
> char * testc() {

It's better to write char *testc(void) here.

>
>     char * pa;
>     pa = malloc (50);
>     if (pa == NULL)
>       {
>      printf ("malloc failed.\n");

fprintf(stederr, ...) is more usual for error messages.

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

If you have a utility function:

  void *malloc_or_bust(size_t sz)
  {
      void *p = malloc(sz);
      if (p == NULL) {
          fprintf(stderr, "malloc failed.\n");
          exit(EXIT_FAILURE);
      }
      return p;
  }

then you can simply write

  char *testc(void)
  {
      return strcpy(malloc_or_bust(50),
                    "this sentence is less than fifty bytes.");
  }

<snip>
> Now, got those headers gone, and I think we all agree that this
> function is standard C.

You might want to use standard C (-std=c99 -pedantic) so as not to end
up relying on gcc extensions that are not available everywhere.  There
are also more warning options that can point you to potential problems
even if the code is 100% correct.  I often use -Wformat-nonliteral
-Wcast-align -Wbad-function-cast -Wstrict-prototypes -Wundef -Wcast-qual
-Wshadow -Wwrite-strings and -Wconversion though this last one can
produce a lot of warnings.

>  As far as me and my compiler can tell, so has
> every other idea as far as what to cast.

Sorry, I can't understand this.

<snip>
> This motivates--not begs--the question: what is the best practice?

Best practice for what?

-- 
Ben.

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

#8850

Ben Bacarisse wrote:

> If you have a utility function:
> 
>   void *malloc_or_bust(size_t sz)
>   {
>       void *p = malloc(sz);
>       if (p == NULL) {
>           fprintf(stderr, "malloc failed.\n");
>           exit(EXIT_FAILURE);
>       }
>       return p;
>   }
> 
> then you can simply write
> 
>   char *testc(void)
>   {
>       return strcpy(malloc_or_bust(50),
>                     "this sentence is less than fifty bytes.");
>   }

If malloc_or_bust(50) returns a null pointer within testc,
then you have undefined behavior in the strcpy call;
and then maybe testc will return a null pointer
or maybe it will return "this sentence is less than fifty bytes."
or maybe something else will happen.

-- 
pete

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

#8852

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>
>> If you have a utility function:
>> 
>>   void *malloc_or_bust(size_t sz)
>>   {
>>       void *p = malloc(sz);
>>       if (p == NULL) {
>>           fprintf(stderr, "malloc failed.\n");
>>           exit(EXIT_FAILURE);
>>       }
>>       return p;
>>   }
>> 
>> then you can simply write
>> 
>>   char *testc(void)
>>   {
>>       return strcpy(malloc_or_bust(50),
>>                     "this sentence is less than fifty bytes.");
>>   }
>
> If malloc_or_bust(50) returns a null pointer within testc,
> then you have undefined behavior in the strcpy call;
> and then maybe testc will return a null pointer
> or maybe it will return "this sentence is less than fifty bytes."
> or maybe something else will happen.

How can malloc_bust() return a null pointer?  If the pointer is null the
program exits.

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

#8853

Joe Pfeiffer wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> >
> >> If you have a utility function:
> >>
> >>   void *malloc_or_bust(size_t sz)
> >>   {
> >>       void *p = malloc(sz);
> >>       if (p == NULL) {
> >>           fprintf(stderr, "malloc failed.\n");
> >>           exit(EXIT_FAILURE);
> >>       }
> >>       return p;
> >>   }
> >>
> >> then you can simply write
> >>
> >>   char *testc(void)
> >>   {
> >>       return strcpy(malloc_or_bust(50),
> >>                     "this sentence is less than fifty bytes.");
> >>   }
> >
> > If malloc_or_bust(50) returns a null pointer within testc,
> > then you have undefined behavior in the strcpy call;
> > and then maybe testc will return a null pointer
> > or maybe it will return "this sentence is less than fifty bytes."
> > or maybe something else will happen.
> 
> How can malloc_bust() return a null pointer? 
> If the pointer is null the program exits.

Oops. I read it wrong.

-- 
pete

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

#8881

On Thu, 28 Jul 2011 07:19:53 -0400, Ben Bacarisse <ben.usenet@bsb.me.uk>  
wrote:
>
> If you have a utility function:
>
>   void *malloc_or_bust(size_t sz)
>   {
>       void *p = malloc(sz);
>       if (p == NULL) {
>           fprintf(stderr, "malloc failed.\n");
>           exit(EXIT_FAILURE);
>       }
>       return p;
>   }
>
> then you can simply write
>
>   char *testc(void)
>   {
>       return strcpy(malloc_or_bust(50),
>                     "this sentence is less than fifty bytes.");
>   }

Not picking on Ben here -- this is just the post that got me to notice
this:  This looks like a classic case where strncpy would be safer
than strcpy.  I certainly wouldn't want to rely on the length of
"this sentence ..." being less than the argument passed to malloc.
If I were writing something like this, with some reason for not having
the 50 in a #define, and also some reason for not using
    sizeof "this sentence is less than fifty bytes"
then I would probably write it as

     size_t size = 50;
     char *p = malloc_or_bust(size);
     strncpy(p, "this sentence is less than fifty bytes", size - 1);
     p[size - 1] = '\0'; // in case "this sentence" is a false sentence

I've seen way too much unnecessary use of strncpy (including recently
all-too-common idiom "strncpy(dst, src, strlen(src))" from students),
but this seems to be a case where its use would be prudent.


-- 
Morris Keesan -- mkeesan@post.harvard.edu

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

#8885

"Morris Keesan" <mkeesan@post.harvard.edu> writes:

> On Thu, 28 Jul 2011 07:19:53 -0400, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>>
>> If you have a utility function:
>>
>>   void *malloc_or_bust(size_t sz)
>>   {
>>       void *p = malloc(sz);
>>       if (p == NULL) {
>>           fprintf(stderr, "malloc failed.\n");
>>           exit(EXIT_FAILURE);
>>       }
>>       return p;
>>   }
>>
>> then you can simply write
>>
>>   char *testc(void)
>>   {
>>       return strcpy(malloc_or_bust(50),
>>                     "this sentence is less than fifty bytes.");
>>   }
>
> Not picking on Ben here -- this is just the post that got me to notice
> this:  This looks like a classic case where strncpy would be safer
> than strcpy.  I certainly wouldn't want to rely on the length of
> "this sentence ..." being less than the argument passed to malloc.
> If I were writing something like this, with some reason for not having
> the 50 in a #define, and also some reason for not using
>    sizeof "this sentence is less than fifty bytes"
> then I would probably write it as
>
>     size_t size = 50;
>     char *p = malloc_or_bust(size);
>     strncpy(p, "this sentence is less than fifty bytes", size - 1);
>     p[size - 1] = '\0'; // in case "this sentence" is a false sentence
>
> I've seen way too much unnecessary use of strncpy (including recently
> all-too-common idiom "strncpy(dst, src, strlen(src))" from students),
> but this seems to be a case where its use would be prudent.

I have a pathological hatred for strncpy -- it either does not make a
string or it pointlessly writes null bytes.  In only one case for the
length does it do what you want!

I'd use strncat:

  char *dest = malloc_or_bust(size);
  *dest = 0;
  return strncat(dest, "string", size - 1);

-- 
Ben.

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

#8894

On 07/29/2011 12:16 PM, Morris Keesan wrote:
> On Thu, 28 Jul 2011 07:19:53 -0400, Ben Bacarisse <ben.usenet@bsb.me.uk>
> wrote:
>>
>> If you have a utility function:
>>
>> void *malloc_or_bust(size_t sz)
>> {
>> void *p = malloc(sz);
>> if (p == NULL) {
>> fprintf(stderr, "malloc failed.\n");
>> exit(EXIT_FAILURE);
>> }
>> return p;
>> }
>>
>> then you can simply write
>>
>> char *testc(void)
>> {
>> return strcpy(malloc_or_bust(50),
>> "this sentence is less than fifty bytes.");
>> }
>
> Not picking on Ben here -- this is just the post that got me to notice
> this: This looks like a classic case where strncpy would be safer
> than strcpy. I certainly wouldn't want to rely on the length of
> "this sentence ..." being less than the argument passed to malloc.
> If I were writing something like this, with some reason for not having
> the 50 in a #define, and also some reason for not using
> sizeof "this sentence is less than fifty bytes"
> then I would probably write it as
>
> size_t size = 50;
> char *p = malloc_or_bust(size);
> strncpy(p, "this sentence is less than fifty bytes", size - 1);
> p[size - 1] = '\0'; // in case "this sentence" is a false sentence
>
> I've seen way too much unnecessary use of strncpy (including recently
> all-too-common idiom "strncpy(dst, src, strlen(src))" from students),
> but this seems to be a case where its use would be prudent.
>
>

Thanks for your comment, Morris.

$  gcc -c -Wall -Wextra cfunc5.c -o cfunc.o
$ 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
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
  this sentence is less than fifty bytes.
$ cat cfunc5.c
// right here begins standard C

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

   void *malloc_or_bust(size_t sz)
   {
       void *p = malloc(sz);
       if (p == NULL) {
           fprintf(stderr, "malloc failed.\n");
           exit(EXIT_FAILURE);
       }
       return p;
   }


   char *testc(void)
   {
     size_t size = 50;
     char *p = malloc_or_bust(size);
     strncpy(p, "this sentence is less than fifty bytes", size - 1);
     p[size - 1] = '\0'; // in case "this sentence" is a false sentence;
     return p;
   }

// gcc -c -Wall -Wextra cfunc5.c -o cfunc.o






$ --
Uno

"I have no idea why I could paste into this messaqge but could not to 
the previous.  Tja."~~Merrill Jensen during Idiocracy 2011 in the USA.

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

#8893

On 07/28/2011 05:19 AM, Ben Bacarisse wrote:
> Uno<Uno@example.invalid>  writes:
> <snip>
>> $ gcc -c -Wall -Wextra cfunc3.c -o cfunc.o
>> $ gfortran -Wall -Wextra caller.o testc.o -o out
>> $ ./out
>>   this sentence is less than fifty bytes.
>
> There's no sign here that the program "out" uses the code in "cfunc3.c".
> You might want to check that it really does.

It does by virtue of being a larger number than cfunc2.c.  I have a 
low-rent tool-chain.
>
> <snip>
>> char * testc() {
>
> It's better to write char *testc(void) here.


Thx.

Here's what I've got now.  I think I can only paste as quotation:

> > $ pwd
> /home/dan/source/fortran_stuff
> $ gcc -c -Wall -Wextra cfunc4.c -o cfunc.o
> $ gcc -c -Wall -Wextra cfunc4.c -o cfunc.o
> cfunc4.c: In function ‘testc’:
> cfunc4.c:25: error: expected declaration or statement at end of input
> $ gcc -c -Wall -Wextra cfunc4.c -o cfunc.o
> $ 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
> $ gfortran -Wall -Wextra caller.o testc.o -o out
> $ ./out
>  this sentence is less than fifty bytes.
> $


> $ cat cfunc4.c
> // right here begins standard C
>
> #include <stdio.h>
> #include <limits.h>
> #include <stdlib.h>
> #include <string.h>
>
>   void *malloc_or_bust(size_t sz)
>   {
>       void *p = malloc(sz);
>       if (p == NULL) {
>           fprintf(stderr, "malloc failed.\n");
>           exit(EXIT_FAILURE);
>       }
>       return p;
>   }
>
>
>   char *testc(void)
>   {
>       return strcpy(malloc_or_bust(50),
>                     "this sentence is less than fifty bytes.");
>   }
>
> // gcc -c -Wall -Wextra cfunc4.c -o cfunc.o
>
>
>
> $

snip

>> Now, got those headers gone, and I think we all agree that this
>> function is standard C.
>
> You might want to use standard C (-std=c99 -pedantic) so as not to end
> up relying on gcc extensions that are not available everywhere.  There
> are also more warning options that can point you to potential problems
> even if the code is 100% correct.  I often use -Wformat-nonliteral
> -Wcast-align -Wbad-function-cast -Wstrict-prototypes -Wundef -Wcast-qual
> -Wshadow -Wwrite-strings and -Wconversion though this last one can
> produce a lot of warnings.

Would the bad cast warning cherp up on any of this?
>
>>   As far as me and my compiler can tell, so has
>> every other idea as far as what to cast.
>
> Sorry, I can't understand this.
>
> <snip>
>> This motivates--not begs--the question: what is the best practice?
>
> Best practice for what?
>

The best practice for transmitting a string to fortran caller from C.
-- 
Uno

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

#8898

Uno <Uno@example.invalid> writes:

> On 07/28/2011 05:19 AM, Ben Bacarisse wrote:
>> Uno<Uno@example.invalid>  writes:
<snip>
>>> This motivates--not begs--the question: what is the best practice?
>>
>> Best practice for what?
>>
> The best practice for transmitting a string to fortran caller from C.

It's almost always the calling function that determines how you must
interface with the called language.  This applies to best practice as
much as it does to those things that are required.

-- 
Ben.

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

#8915

On 07/30/2011 05:23 AM, Ben Bacarisse wrote:

> It's almost always the calling function that determines how you must
> interface with the called language.  This applies to best practice as
> much as it does to those things that are required.
>

Ok.  Fortran is expecting a c-style pointer to a char.  This little 
snippet gives you a feel for it.  This is pretty-new syntax, and what 
makes it relevant to c is that fortran said *all* interop is with ISO C.

type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(:)
pa = testc()

...

Yes the horror of not seeing semicolons, but again I put the fortran 
stuff at the top, so it can disappear with a reasonable edit.

On the C side, I think I've got something that works well, but I don't 
know that without some code review.  This is what dinkumware has for 
strncpy; does anyone have a mnemonic for what the 'n' might mean?

strncpy

char *strncpy(char *restrict s1, const char *restrict s2, size_t n);

The function copies the string s2, not including its terminating null 
character, to successive elements of the array of char whose first 
element has the address s1. It copies no more than n characters from s2. 
The function then stores zero or more null characters in the next 
elements to be altered in s1 until it stores a total of n characters. It 
returns s1.

So I want a char * before i get to this statement, and that leaves the 
malloc:

char *p = malloc(sz);

The reason that I might put it on the left is that I haven't been handed 
anything that's broken, and if it doesn't draw warnings, then C might be 
just fine this.

Another version might be:

char *p = (char *)malloc(sz);
, and I'm naive enough not to see anything wrong there, technically. 
But as I'm sitting here, it looks like an unnecessary cast.

$ gcc -c -Wall -Wextra cfunc6.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.
$ 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

$ indent -i3 cfunc6.c

$ cat cfunc6.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
char *
malloc_or_bust (size_t sz)
{
    char *p = malloc (sz);
    if (p == NULL)
      {
	fprintf (stderr, "malloc failed.\n");
	exit (EXIT_FAILURE);
      }
    return p;
}
char *
testc (void)
{
    size_t size = 50;
    char *p = malloc_or_bust (size);
    strncpy (p, "this sentence is less than fifty bytes", size - 1);
    p[size - 1] = '\0
    return p;
}
// gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
$

Thanks for your comment.  How long have I known you now?  I bet that 
neither of us would move back to Michigan now.  what's going on in 
upper-midwest states is shocking.  The KKK and arsonists have showed up 
in 'Sconi ten days before people were almost going to have a free and 
fair election.

-- 
Uno

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

#8919

On 2011-08-01, Uno <Uno@example.invalid> wrote:
> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
> $ gfortran -c  -Wall -Wextra caller2.f03 -o caller.o
> $ gfortran -Wall -Wextra caller.o testc.o -o out

What is testc.o ?
Is it related to cfunc6.c ?

> $ ./out
>   this sentence is less than fifty bytes.

Just curious: where are the leading spaces and the trailing dot from?

> [snip fortran code]

> $ cat cfunc6.c
> #include <stdio.h>
> #include <limits.h>
> #include <stdlib.h>
> #include <string.h>
> char *
> malloc_or_bust (size_t sz)
> {
>     char *p = malloc (sz);
>     if (p == NULL)
>       {
> 	fprintf (stderr, "malloc failed.\n");
> 	exit (EXIT_FAILURE);
>       }
>     return p;
> }
> char *
> testc (void)
> {
>     size_t size = 50;
>     char *p = malloc_or_bust (size);
>     strncpy (p, "this sentence is less than fifty bytes", size - 1);
>     p[size - 1] = '\0
>     return p;
> }
> // gcc -c -Wall -Wextra cfunc6.c -o cfunc.o

$ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
cfunc6.c: In function 'testc':
cfunc6.c:22: error: missing terminating ' character
cfunc6.c:23: error: expected expression before 'return'
cfunc6.c:24: warning: control reaches end of non-void function

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

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

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

csiph-web