Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12449 > unrolled thread

I am learning C: a little problem with a simple source code

Back to article view | Back to comp.lang.c

Contents

  I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 08:27 -0700
    Re: I am learning C: a little problem with a simple source code Mark Bluemel <mark_bluemel@pobox.com> - 2011-11-01 15:49 +0000
    Re: I am learning C: a little problem with a simple source code nroberts <roberts.noah@gmail.com> - 2011-11-01 08:52 -0700
    Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 16:22 +0000
    Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-01 09:31 -0700
      Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-01 16:57 +0000
        Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:51 -0700
          Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 15:04 -0400
            Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-01 20:21 +0000
              Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2011-11-01 21:41 +0100
          Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 08:06 +1300
            Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:17 -0700
              Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 16:24 -0400
                Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:27 -0700
                  Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-01 20:24 -0700
                    Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-02 10:24 +0000
                      Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-02 11:04 +0000
                        Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 07:41 -0400
                        Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 18:00 +0000
                        Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-02 14:06 -0700
                          Re: I am learning C: a little problem with a simple source code John Bode <jfbode1029@gmail.com> - 2011-11-03 15:05 -0700
                          Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:55 -0800
                            Re: I am learning C: a little problem with a simple source code jgk@panix.com (Joe keane) - 2012-01-26 15:59 +0000
                              Re: I am learning C: a little problem with a simple source code Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> - 2012-01-27 20:28 +0100
                                Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-28 14:11 +0100
                                  Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-29 09:34 -0500
                                    Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-30 13:38 +0100
                                      Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-30 12:10 -0500
                                Re: I am learning C: a little problem with a simple source code Zoltan Kocsi <zoltan@bendor.com.au> - 2012-01-29 08:55 +1100
                                Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:48 -0800
                              Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:46 -0800
                                Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-01-31 22:30 -0800
                                  Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:11 -0800
                                    Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-08 13:51 -0800
                                      Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 12:51 -0800
                                        Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 13:36 -0800
                                          Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-09 23:50 +0100
                                          Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 15:01 -0800
                                            Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 16:21 -0800
                                              Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 00:57 +0000
                                                Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-10 13:37 +0100
                                                  Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 13:58 +0000
                                              Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-10 12:24 -0800
                                                Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-10 14:16 -0800
                                                  Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-11 12:50 -0700
                                          Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-11 00:57 -0800
                                            Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-11 03:20 -0700
                                              Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-12 02:10 -0700
                                                Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-12 10:49 -0700
                                                  Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-14 01:16 -0700
                                            Re: I am learning C: a little problem with a simple source code Robert Miles <milesrf@Usenet-News.net> - 2012-04-15 06:53 -0500
                                              Re: I am learning C: a little problem with a simple source code Nomen Nescio <nobody@dizum.com> - 2012-04-15 19:45 +0200
                                              Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-04-15 15:06 -0700
                                Re: I am learning C: a little problem with a simple source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-04-16 10:56 -0700
                        Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-03 10:19 +1300
                          Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 21:10 +0000
                          Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 05:13 +0000
                Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:29 -0700
              Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
                Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 06:33 -0700
                  Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-03 07:05 -0700
                    Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
                      Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:44 -0700
                        Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 07:30 -0700
                          Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:03 +0000
                            Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:20 -0700
                              Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:45 +0000
                                Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:59 -0700
                                  Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 19:32 +0000
                                  Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-05 04:07 -0700
                              Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:54 +0000
                                Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:58 -0700
                            Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 18:25 +0100
                          Re: I am learning C: a little problem with a simple source code gordonb.e1fpi@burditt.org (Gordon Burditt) - 2011-11-04 13:50 -0500
                            Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 11:57 -0700
                              Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-04 14:44 -0700
                            Re: I am learning C: a little problem with a simple source code "osmium" <r124c4u102@comcast.net> - 2011-11-04 14:03 -0500
                            Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 21:37 +0000
                              Re: I am learning C: a little problem with a simple source code Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-06 12:20 +0200
                      Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:32 -0700
                        Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:04 -0700
                          Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 10:28 -0700
                  Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 18:35 +0000
                    Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-03 14:50 -0700
                      Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-03 15:59 -0700
                        Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:00 -0700
                        Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 20:58 +0100
                          Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 21:13 +0100
                      Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:56 -0700
                        Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:12 -0700
                          Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:09 +1300
                    Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
                      Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 22:53 +0000
                        Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 17:57 -0700
                          Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:35 -0500
                            Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 03:31 +0000
                          Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 02:25 -0700
                    Re: I am learning C: a little problem with a simple source code Kulin Remailer <remailer@reece.net.au> - 2011-11-03 22:47 +0000
                      Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 16:14 -0700
                    Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:55 -0500
                    Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:10 -0700
                  Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 14:21 -0700
                    Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 16:31 -0500
                    Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:41 +1300
                    Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 21:38 +0000
                      Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 22:18 -0500
                        Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:11 -0400
                          Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:13 -0400
                            Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-05 23:35 -0500
                        Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-06 07:40 +0000
                    Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 18:15 -0400
                      Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:00 -0700
                        Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 23:19 -0400
                          Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:33 -0700
                        Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 03:52 +0000
                          Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 17:01 +1300
                          Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 21:48 -0700
            Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:19 -0700
              Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:26 +1300
            Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:23 -0700
              Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:27 +1300
                Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:31 -0700
          Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 22:48 +0000
            Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 23:09 -0800
          Re: I am learning C: a little problem with a simple source code gordonb.prbii@burditt.org (Gordon Burditt) - 2011-11-01 21:24 -0500
          Re: I am learning C: a little problem with a simple source code Dann Corbit <dcorbit@connx.com> - 2011-11-02 21:03 -0700
            Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 06:39 +0000
            Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-03 18:33 -0700
              Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 03:03 -0700
                Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 11:40 +0100
                Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 11:36 +0000
                  Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:58 +0000
            Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 07:24 +0100
              Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 10:28 +0100
                Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:02 +0100
                  Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:20 +0100
                    Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:39 +0100
              Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 18:07 +0100
                Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-06 09:59 -0800
                  Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 19:23 +0100
                  Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-06 15:23 -0500
        Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:52 -0700
          Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-01 23:02 +0000
    Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 03:53 -0700
      Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 08:03 -0400
        Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 06:11 -0700

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

#12680

On Nov 3, 8:35 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
>  One of the interesting side effects was that some Windows compilers
> chose not to offer a working <stdio.h> or the related functionality when
> they were used in the mode where they started execution at winmain().
> (I believe I've seen claims that at least one omitted *sprintf* too in
> this mode.  Which is allowed, and goes to show why you always want a
> hosted implementation if possible.)
>
Yes, that's a terrible nuisance. If stderr is vandalised then a lot of
code which should be portable becomes non-portable.

As a non-debugger user, I also like to print diagnostics. I ended up
writing a special console for the task.
--
How is floating point arithmetic implemented? Read Basic Algorithms,
now also available as an Apple iBook.
http://www.malcolmmclean.site11.com/www

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

#12722

On Nov 3, 9:33 am, Bill Reid <hormelf...@gmail.com> wrote:
> On Nov 1, 2:44 pm, Seebs <usenet-nos...@seebs.net> wrote:> On 2011-11-01, zemir <zemir...@libero.it> wrote:
>
> > > Yes, of course........... int main() is more right but my choice is
> > > such common that it is not more a error......
>
> > This is not how computers work.  A common mistake is still a mistake.
>
> Oh great, somebody who knows how computers work, I've been looking
> for somebody like that to explain something...
>
> > This is like saying that, if enough people believe that gravity's
> > acceleration on the earth's surface is 9 meters/second/second, it's not
> > bad to use that number to design an airplane.
>
> Oh yes, people could die...soooooooo, please explain how a
> common OS, such as say, Windows(TM), uses the return value
> from main()?  Or for that matter, a TRUE Unix(TM)?  Or any
> other OSs that you are an expert on?
>
> And while you're on the subject, how should a computer
> expert such as yourself set the return value of main() to be
> correct?
> Can you define what conditions would cause me to set it one
> way or another?  Of course, I'm assuming that since the
> ANSI C committee decreed that main() have a specific set
> of return values, every computer in the world conforms
> to those values and does something useful with them, so
> I would have perfect "portability" between platforms
> for my "correct" C code, and nobody would die as a result
> of my using an incorrect return value...
>
> Also, what's "winmain()"?  I've seen that a lot, returns
> something called a "Windows handle", what's up with that?
>
> You know, I've asked these questions here before, but
> never received an answer, but I'm sure that's because
> there wasn't a computer expert such as yourself to answer
> them...
>
> P.S.  Note carefully that I didn't ask if it was OK
> to return a value from main() (or any function) when
> the function prototype does not have a return value,
> and I always use the correct prototype for main(),
> just because it's annoying to have the error messages
> from the compiler, just like this topic is annoying...

I'm curious about the whole 'int' return type placed on 'main' as
well.  The only idea that I can come up with is that since Ritchie
designed C to support the Unix operating system, and the Unix
operating system wanted to implement pipes for inter-program
communication, 'int main(...)' became the de-facto standard to use the
return value in that sense.  What's interesting is that there are
other scenarios where returning a value from 'main' makes little to no
sense, like in embedded systems designed to run a single stand-alone
application "forever", with no opportunity for inter-process
communication, and yet 'void main(...)' is ridiculed even though it
seems to have a logical place in some application design domains.

Best regards,
John D.

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

#12723

On Fri, 4 Nov 2011 14:21:00 -0700 (PDT), ImpalerCore 
>I'm curious about the whole 'int' return type placed on 'main' as
>well.  The only idea that I can come up with is that since Ritchie
>designed C to support the Unix operating system, and the Unix
>operating system wanted to implement pipes for inter-program
>communication, 'int main(...)' became the de-facto standard to use the
>return value in that sense.  What's interesting is that there are
>other scenarios where returning a value from 'main' makes little to no
>sense, like in embedded systems designed to run a single stand-alone
>application "forever", with no opportunity for inter-process
>communication, and yet 'void main(...)' is ridiculed even though it
>seems to have a logical place in some application design domains.


An "embedded systems designed to run a single stand-alone application
'forever', with no opportunity for inter-process communication" is
probably running a freestanding C implementation, and main is no
longer the standard entry point for the application, nor are there
standard parameters passed in or returned values from the application
startup.

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

#12725

On 11/ 5/11 10:21 AM, ImpalerCore wrote:
>
> I'm curious about the whole 'int' return type placed on 'main' as
> well.  The only idea that I can come up with is that since Ritchie
> designed C to support the Unix operating system, and the Unix
> operating system wanted to implement pipes for inter-program
> communication, 'int main(...)' became the de-facto standard to use the
> return value in that sense.  What's interesting is that there are
> other scenarios where returning a value from 'main' makes little to no
> sense, like in embedded systems designed to run a single stand-alone
> application "forever", with no opportunity for inter-process
> communication, and yet 'void main(...)' is ridiculed even though it
> seems to have a logical place in some application design domains.

void main() or any other form (I've used embedded systems where main had 
quite lengthy parameter lists!) is perfectly acceptable as an 
implementation defined form for main.

int main() {}

Is also permitted by the standard.

-- 
Ian Collins

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

#12727

On 2011-11-04, ImpalerCore <jadill33@gmail.com> wrote:
> I'm curious about the whole 'int' return type placed on 'main' as
> well.  The only idea that I can come up with is that since Ritchie
> designed C to support the Unix operating system, and the Unix
> operating system wanted to implement pipes for inter-program
> communication, 'int main(...)' became the de-facto standard to use the
> return value in that sense.

I've not yet heard of an operating system which doesn't have some concept
roughly analagous to a return status.

> What's interesting is that there are
> other scenarios where returning a value from 'main' makes little to no
> sense, like in embedded systems designed to run a single stand-alone
> application "forever", with no opportunity for inter-process
> communication, and yet 'void main(...)' is ridiculed even though it
> seems to have a logical place in some application design domains.

It's not for *actual* freestanding systems -- the C standard only specifies
the type of main for hosted systems.  For non-hosted systems, the standard
doesn't even specify where execution starts!

The thing is, it doesn't matter whether or not you run a program forever;
what matters is whether the operating system's startup code is expecting
the call ABI to match that of a function which returns a value.  If it does,
then (at least on machines where call ABI cares, which some do), it's
pretty important that the actual function matches what the calling code
expects.

If you aren't in a hosted environment, all bets are off; it may be prohibited
for you to name a function main(), it may be permissible but irrelevant,
who knows?  Up to the implementation to document what you do and how you
do it.

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

#12753

On 04 Nov 2011 21:38:29 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2011-11-04, ImpalerCore <jadill33@gmail.com> wrote:
>> I'm curious about the whole 'int' return type placed on 'main' as
>> well.  The only idea that I can come up with is that since Ritchie
>> designed C to support the Unix operating system, and the Unix
>> operating system wanted to implement pipes for inter-program
>> communication, 'int main(...)' became the de-facto standard to use the
>> return value in that sense.
>
>I've not yet heard of an operating system which doesn't have some concept
>roughly analagous to a return status.


Surely you know better than to start a sentence like that around
here...  ;-)

From it's first incarnation in roughly 1964, S/360 DOS, the "small"
mainframe OS, and its descendents DOS/VS, DOS/VSE, VSE/SP, VSE/ESA and
zVSE had no return codes dealt with by the OS.  They were adding in
about 1990 (give-or-take - it may have been the first release of
VSE/ESA).  There was no good way to have conditional JCL either
(although there were always hacks).

This was always a huge omission, and the other mainframe OS's didn't
suffer the same limitation.

Interestingly, since more than a few bits of software were shared with
MVS, you often had those applications set and display a return code,
even though it went nowhere.  Thus IDCAMS (a utility for defining and
managing certain types of files), would, if passed an invalid control
statement, display a message saying that it was ending with a return
code of 12.  Or worse, if the file in question was in use and IDCAMS
couldn't make the requested change, it would cheerfully print that it
had failed, and was exiting with a return code of 8.  And then you
couldn't do anything with that.  Very frustrating.

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

#12779

On November 4, 2011 23:18, in comp.lang.c, robertwessel2@yahoo.com wrote:

> On 04 Nov 2011 21:38:29 GMT, Seebs <usenet-nospam@seebs.net> wrote:
> 
>>On 2011-11-04, ImpalerCore <jadill33@gmail.com> wrote:
>>> I'm curious about the whole 'int' return type placed on 'main' as
>>> well.  The only idea that I can come up with is that since Ritchie
>>> designed C to support the Unix operating system, and the Unix
>>> operating system wanted to implement pipes for inter-program
>>> communication, 'int main(...)' became the de-facto standard to use the
>>> return value in that sense.
>>
>>I've not yet heard of an operating system which doesn't have some concept
>>roughly analagous to a return status.
> 
> 
> Surely you know better than to start a sentence like that around
> here...  ;-)
> 
> From it's first incarnation in roughly 1964, S/360 DOS, the "small"
> mainframe OS, and its descendents DOS/VS, DOS/VSE, VSE/SP, VSE/ESA and
> zVSE had no return codes dealt with by the OS.  They were adding in
> about 1990 (give-or-take - it may have been the first release of
> VSE/ESA).

Returncodes were introduced in VSE/ESA, as I recall.

As a System Programmer for a number of VSE/ESA systems, I wrote a little
utility that permitted COBOL programs to properly return returncodes to the
OS (IBM's native COBOL compiler and runtime didn't have that ability yet)
so that conditional JCL could evaluate the results and take appropriate
action.

> There was no good way to have conditional JCL either 
> (although there were always hacks).

Conditional JCL was available, but only useful if the program could return a
condition code. That restricted it to IBM utilities and /some/ programs
written in C (not IBM's C compiler, IIRC)

> This was always a huge omission, and the other mainframe OS's didn't
> suffer the same limitation.

[snip]

-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

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

#12780

On November 5, 2011 11:11, in comp.lang.c, lpitcher@teksavvy.com wrote:

> On November 4, 2011 23:18, in comp.lang.c, robertwessel2@yahoo.com wrote:
> 
>> On 04 Nov 2011 21:38:29 GMT, Seebs <usenet-nospam@seebs.net> wrote:
>> 
>>>On 2011-11-04, ImpalerCore <jadill33@gmail.com> wrote:
>>>> I'm curious about the whole 'int' return type placed on 'main' as
>>>> well.  The only idea that I can come up with is that since Ritchie
>>>> designed C to support the Unix operating system, and the Unix
>>>> operating system wanted to implement pipes for inter-program
>>>> communication, 'int main(...)' became the de-facto standard to use the
>>>> return value in that sense.
>>>
>>>I've not yet heard of an operating system which doesn't have some concept
>>>roughly analagous to a return status.
>> 
>> 
>> Surely you know better than to start a sentence like that around
>> here...  ;-)
>> 
>> From it's first incarnation in roughly 1964, S/360 DOS, the "small"
>> mainframe OS, and its descendents DOS/VS, DOS/VSE, VSE/SP, VSE/ESA and
>> zVSE had no return codes dealt with by the OS.  They were adding in
>> about 1990 (give-or-take - it may have been the first release of
>> VSE/ESA).
> 
> Returncodes were introduced in VSE/ESA, as I recall.

Correction. It was DOS/VSE. VSE/ESA introduced native returncodes to the
compiler suite IIRC

> As a System Programmer for a number of VSE/ESA systems, I wrote a little
> utility that permitted COBOL programs to properly return returncodes to
> the OS (IBM's native COBOL compiler and runtime didn't have that ability
> yet) so that conditional JCL could evaluate the results and take
> appropriate action.
> 
>> There was no good way to have conditional JCL either
>> (although there were always hacks).
> 
> Conditional JCL was available, but only useful if the program could return
> a condition code. That restricted it to IBM utilities and /some/ programs
> written in C (not IBM's C compiler, IIRC)
> 
>> This was always a huge omission, and the other mainframe OS's didn't
>> suffer the same limitation.
> 
> [snip]
> 
> --
> Lew Pitcher
> Master Codewright & JOAT-in-training   | Registered Linux User #112576
> Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
> ----------      Slackware - Because I know what I'm doing.         ------
> 
> 

-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

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

#12799

On Sat, 05 Nov 2011 11:13:43 -0400, Lew Pitcher
<lpitcher@teksavvy.com> wrote:

>On November 5, 2011 11:11, in comp.lang.c, lpitcher@teksavvy.com wrote:
>
>> On November 4, 2011 23:18, in comp.lang.c, robertwessel2@yahoo.com wrote:
>> 
>>> On 04 Nov 2011 21:38:29 GMT, Seebs <usenet-nospam@seebs.net> wrote:
>>> 
>>>>On 2011-11-04, ImpalerCore <jadill33@gmail.com> wrote:
>>>>> I'm curious about the whole 'int' return type placed on 'main' as
>>>>> well.  The only idea that I can come up with is that since Ritchie
>>>>> designed C to support the Unix operating system, and the Unix
>>>>> operating system wanted to implement pipes for inter-program
>>>>> communication, 'int main(...)' became the de-facto standard to use the
>>>>> return value in that sense.
>>>>
>>>>I've not yet heard of an operating system which doesn't have some concept
>>>>roughly analagous to a return status.
>>> 
>>> 
>>> Surely you know better than to start a sentence like that around
>>> here...  ;-)
>>> 
>>> From it's first incarnation in roughly 1964, S/360 DOS, the "small"
>>> mainframe OS, and its descendents DOS/VS, DOS/VSE, VSE/SP, VSE/ESA and
>>> zVSE had no return codes dealt with by the OS.  They were adding in
>>> about 1990 (give-or-take - it may have been the first release of
>>> VSE/ESA).
>> 
>> Returncodes were introduced in VSE/ESA, as I recall.
>
>Correction. It was DOS/VSE. VSE/ESA introduced native returncodes to the
>compiler suite IIRC


I think we're both wrong.  Return codes and conditional JCL were first
added to VSE/SP v2 or v3.

The compilers did take longer (you could set return codes from an
assembler program, of course), but I seem to remember some hack to
store a return code before the compiler RTL's EOJ was issued.  Maybe
we just wrapped the Cobol programs with an assembler mainline to do
it, although I seems to recall some more hacking (storing the RC in a
control block somewhere, maybe the PIB, or some such thing).  Not that
it matters anymore...

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

#12804

On 2011-11-05, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On 04 Nov 2011 21:38:29 GMT, Seebs <usenet-nospam@seebs.net> wrote:
>>I've not yet heard of an operating system which doesn't have some concept
>>roughly analagous to a return status.

> Surely you know better than to start a sentence like that around
> here...  ;-)

I was sort of hoping to find one, because I love to know strange
counterexamples.

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

#12732

On 11/04/2011 05:21 PM, ImpalerCore wrote:
...
> I'm curious about the whole 'int' return type placed on 'main' as
> well.  The only idea that I can come up with is that since Ritchie
> designed C to support the Unix operating system, and the Unix
> operating system wanted to implement pipes for inter-program
> communication, 'int main(...)' became the de-facto standard to use the
> return value in that sense.

AFAIK, the exit status from a program is used in Unix-like systems only
for communication between child processes and their parents, pipes need
not be involved, and usually aren't. In my personal experience, a shell
(sh, csh, tcsh, bsh, etc.) and make are the most common parent
processes. I'm not aware of any special connection between the exit
status and the use of pipes. Therefore, I find it odd that you might
consider pipes to have been the prime motivation for exit statuses.
Could you explain that idea in a little more detail?

Keep in mind that in C as it was originally designed, there was no
'void'. Functions declared with no return type were implicitly treated
as if they had a return type of 'int'. There were functions which didn't
bother setting the return value, and function calls which didn't bother
checking the return value, but there was no such thing as functions that
were declared as not returning a value. In such an environment, it would
be natural for main() to return an int, even if there was no particular
need to; and there was certainly a need for some mechanism whereby a
child process could report simple status information to its parent.

> ...  What's interesting is that there are
> other scenarios where returning a value from 'main' makes little to no
> sense, like in embedded systems designed to run a single stand-alone
> application "forever", with no opportunity for inter-process
> communication, and yet 'void main(...)' is ridiculed even though it
> seems to have a logical place in some application design domains.

I wouldn't ridicule void main(); the only thing I've ever done is point
out that it's not supported by the standard. If it were added to the
list of permitted signatures for main(), I'd have no objection.

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

#12752

On Nov 4, 6:15 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 11/04/2011 05:21 PM, ImpalerCore wrote:
> ...
>
> > I'm curious about the whole 'int' return type placed on 'main' as
> > well.  The only idea that I can come up with is that since Ritchie
> > designed C to support the Unix operating system, and the Unix
> > operating system wanted to implement pipes for inter-program
> > communication, 'int main(...)' became the de-facto standard to use the
> > return value in that sense.
>
> AFAIK, the exit status from a program is used in Unix-like systems only
> for communication between child processes and their parents, pipes need
> not be involved, and usually aren't. In my personal experience, a shell
> (sh, csh, tcsh, bsh, etc.) and make are the most common parent
> processes. I'm not aware of any special connection between the exit
> status and the use of pipes. Therefore, I find it odd that you might
> consider pipes to have been the prime motivation for exit statuses.
> Could you explain that idea in a little more detail?

Yes, you're correct.  I just used "pipes" in the sense of "one program
communicating with another".  It was phrased poorly.  Is there a
better term?

> Keep in mind that in C as it was originally designed, there was no
> 'void'. Functions declared with no return type were implicitly treated
> as if they had a return type of 'int'.

Yeah, I seem to keep forgetting that.

> There were functions which didn't
> bother setting the return value, and function calls which didn't bother
> checking the return value, but there was no such thing as functions that
> were declared as not returning a value. In such an environment, it would
> be natural for main() to return an int, even if there was no particular
> need to; and there was certainly a need for some mechanism whereby a
> child process could report simple status information to its parent.

Agreed.

> > ...  What's interesting is that there are
> > other scenarios where returning a value from 'main' makes little to no
> > sense, like in embedded systems designed to run a single stand-alone
> > application "forever", with no opportunity for inter-process
> > communication, and yet 'void main(...)' is ridiculed even though it
> > seems to have a logical place in some application design domains.
>
> I wouldn't ridicule void main(); the only thing I've ever done is point
> out that it's not supported by the standard. If it were added to the
> list of permitted signatures for main(), I'd have no objection.

I feel that after writing a bunch of test programs for library API
functions, it feels a little bit tedious to include the same
boilerplate code to #include <stdlib.h> and return EXIT_SUCCESS for
every example to try to keep everything kosher when all the example
does is demonstrate how to use the function.  There is no intent to
design it to communicate in any meaningful way with other programs
through the OS.  A 'void main(...)' could communicate this intent in
as a don't care to a hosted environment (semantics could be that the
program implicitly returns EXIT_SUCCESS no matter what).  This would
be in contrast to a program defined with 'int main(...)' whose intent
would be "Ya better look at my return code, cause you're going to need
it."  It just feels like 'void main(...)' could add a useful semantic
to programs even in hosted mode.  There are probably reasons for not
doing it; I'm just not familiar enough with the history to understand
why.

Thanks to everyone else that's responded; it's helped clarify things.

Best regards,
John D.

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

#12754

On 11/04/2011 11:00 PM, ImpalerCore wrote:
...
> Yes, you're correct.  I just used "pipes" in the sense of "one program
> communicating with another".  It was phrased poorly.  Is there a
> better term?

"interprocess communication"? A process is a particular instantiation of
a program, and it's processes which are communicating, not programs.

> I feel that after writing a bunch of test programs for library API
> functions, it feels a little bit tedious to include the same
> boilerplate code to #include <stdlib.h> and return EXIT_SUCCESS

In that case, just return 0; then you don't need <stdlib.h>.
-- 
James Kuyper

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

#12755

On Nov 4, 11:19 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 11/04/2011 11:00 PM, ImpalerCore wrote:
> ...
>
> > Yes, you're correct.  I just used "pipes" in the sense of "one program
> > communicating with another".  It was phrased poorly.  Is there a
> > better term?
>
> "interprocess communication"? A process is a particular instantiation of
> a program, and it's processes which are communicating, not programs.
>
> > I feel that after writing a bunch of test programs for library API
> > functions, it feels a little bit tedious to include the same
> > boilerplate code to #include <stdlib.h> and return EXIT_SUCCESS
>
> In that case, just return 0; then you don't need <stdlib.h>.

That will clean up quite a bit of extraneous code, thanks!

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

#12756

On 2011-11-05, ImpalerCore <jadill33@gmail.com> wrote:
> On Nov 4, 6:15 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 11/04/2011 05:21 PM, ImpalerCore wrote:
>> ...
>>
>> > I'm curious about the whole 'int' return type placed on 'main' as
>> > well.  The only idea that I can come up with is that since Ritchie
>> > designed C to support the Unix operating system, and the Unix
>> > operating system wanted to implement pipes for inter-program
>> > communication, 'int main(...)' became the de-facto standard to use the
>> > return value in that sense.
>>
>> AFAIK, the exit status from a program is used in Unix-like systems only
>> for communication between child processes and their parents, pipes need
>> not be involved, and usually aren't. In my personal experience, a shell
>> (sh, csh, tcsh, bsh, etc.) and make are the most common parent
>> processes. I'm not aware of any special connection between the exit
>> status and the use of pipes. Therefore, I find it odd that you might
>> consider pipes to have been the prime motivation for exit statuses.
>> Could you explain that idea in a little more detail?
>
> Yes, you're correct.  I just used "pipes" in the sense of "one program
> communicating with another".  It was phrased poorly.  Is there a
> better term?
>
>> Keep in mind that in C as it was originally designed, there was no
>> 'void'. Functions declared with no return type were implicitly treated
>> as if they had a return type of 'int'.
>
> Yeah, I seem to keep forgetting that.
>
>> There were functions which didn't
>> bother setting the return value, and function calls which didn't bother
>> checking the return value, but there was no such thing as functions that
>> were declared as not returning a value. In such an environment, it would
>> be natural for main() to return an int, even if there was no particular
>> need to; and there was certainly a need for some mechanism whereby a
>> child process could report simple status information to its parent.
>
> Agreed.
>
>> > ...  What's interesting is that there are
>> > other scenarios where returning a value from 'main' makes little to no
>> > sense, like in embedded systems designed to run a single stand-alone
>> > application "forever", with no opportunity for inter-process
>> > communication, and yet 'void main(...)' is ridiculed even though it
>> > seems to have a logical place in some application design domains.
>>
>> I wouldn't ridicule void main(); the only thing I've ever done is point
>> out that it's not supported by the standard. If it were added to the
>> list of permitted signatures for main(), I'd have no objection.
>
> I feel that after writing a bunch of test programs for library API
> functions, it feels a little bit tedious to include the same
> boilerplate code to #include <stdlib.h> and return EXIT_SUCCESS for
> every example to try to keep everything kosher when all the example

If you're inconvenienced by producing numerous test programs which
are similar to each other, that's a situation where you can apply some
code generation techniques.

The first tool to try would be the preprocessor.

Your boilerplate can be reduced to

  #define SOME_MACROS_CONFIGURING_BOILERPLATE
  #include "boilerplate.h"

Chances are it's not just the #include <stdlib.h> and EXIT_SUCCESS
that is repeated from tst to test.

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

#12757

On 11/ 5/11 04:52 PM, Kaz Kylheku wrote:
> On 2011-11-05, ImpalerCore<jadill33@gmail.com>  wrote:
>>
>> I feel that after writing a bunch of test programs for library API
>> functions, it feels a little bit tedious to include the same
>> boilerplate code to #include<stdlib.h>  and return EXIT_SUCCESS for
>> every example to try to keep everything kosher when all the example
>
> If you're inconvenienced by producing numerous test programs which
> are similar to each other, that's a situation where you can apply some
> code generation techniques.
>
> The first tool to try would be the preprocessor.
>
> Your boilerplate can be reduced to
>
>    #define SOME_MACROS_CONFIGURING_BOILERPLATE
>    #include "boilerplate.h"

Or use a unit testing framework.

-- 
Ian Collins

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

#12761

On Nov 4, 11:52 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2011-11-05, ImpalerCore <jadil...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 4, 6:15 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> On 11/04/2011 05:21 PM, ImpalerCore wrote:
> >> ...
>
> >> > I'm curious about the whole 'int' return type placed on 'main' as
> >> > well.  The only idea that I can come up with is that since Ritchie
> >> > designed C to support the Unix operating system, and the Unix
> >> > operating system wanted to implement pipes for inter-program
> >> > communication, 'int main(...)' became the de-facto standard to use the
> >> > return value in that sense.
>
> >> AFAIK, the exit status from a program is used in Unix-like systems only
> >> for communication between child processes and their parents, pipes need
> >> not be involved, and usually aren't. In my personal experience, a shell
> >> (sh, csh, tcsh, bsh, etc.) and make are the most common parent
> >> processes. I'm not aware of any special connection between the exit
> >> status and the use of pipes. Therefore, I find it odd that you might
> >> consider pipes to have been the prime motivation for exit statuses.
> >> Could you explain that idea in a little more detail?
>
> > Yes, you're correct.  I just used "pipes" in the sense of "one program
> > communicating with another".  It was phrased poorly.  Is there a
> > better term?
>
> >> Keep in mind that in C as it was originally designed, there was no
> >> 'void'. Functions declared with no return type were implicitly treated
> >> as if they had a return type of 'int'.
>
> > Yeah, I seem to keep forgetting that.
>
> >> There were functions which didn't
> >> bother setting the return value, and function calls which didn't bother
> >> checking the return value, but there was no such thing as functions that
> >> were declared as not returning a value. In such an environment, it would
> >> be natural for main() to return an int, even if there was no particular
> >> need to; and there was certainly a need for some mechanism whereby a
> >> child process could report simple status information to its parent.
>
> > Agreed.
>
> >> > ...  What's interesting is that there are
> >> > other scenarios where returning a value from 'main' makes little to no
> >> > sense, like in embedded systems designed to run a single stand-alone
> >> > application "forever", with no opportunity for inter-process
> >> > communication, and yet 'void main(...)' is ridiculed even though it
> >> > seems to have a logical place in some application design domains.
>
> >> I wouldn't ridicule void main(); the only thing I've ever done is point
> >> out that it's not supported by the standard. If it were added to the
> >> list of permitted signatures for main(), I'd have no objection.
>
> > I feel that after writing a bunch of test programs for library API
> > functions, it feels a little bit tedious to include the same
> > boilerplate code to #include <stdlib.h> and return EXIT_SUCCESS for
> > every example to try to keep everything kosher when all the example
>
> If you're inconvenienced by producing numerous test programs which
> are similar to each other, that's a situation where you can apply some
> code generation techniques.
>
> The first tool to try would be the preprocessor.
>
> Your boilerplate can be reduced to
>
>   #define SOME_MACROS_CONFIGURING_BOILERPLATE
>   #include "boilerplate.h"
>
> Chances are it's not just the #include <stdlib.h> and EXIT_SUCCESS
> that is repeated from tst to test.

In my case, the example programs are more for users to demonstrate the
data structure and API in a sample task.  Eventually I'd like to get
more formal unit testing built, but I'm not there yet.

Here is an example of the kinds of examples I'm writing:

\code snippet
#include <stdio.h>
#include <stdlib.h>
#include <clover/config.h>
#include <clover/macros.h>
#include <clover/constraint.h>
#include <clover/strops.h>

int pstrnatvcmp( const void* p, const void* q );

int main( void )
{
  size_t idx;

  char* files[] =
  {
    "file02.txt",
    "file120.txt",
    "file12.txt",
    "file02a.txt",
    "file1.txt",
    "file05.txt",
    "file4.txt",
    "file100.txt",
    "file.txt",
    "file121.txt",
    "file7.txt",
    "file100b.txt",

    "file.3",
    "file.00",
    "file.02",
    "file.010",
    "file",
    "file.11",
    "file.1",
    "file.001",
    "file.125",
    "file.002",
    "file.3000",
  };

  printf( "---File Listing---\n" );
  for ( idx = 0; idx < C_ARRAY_N (files); ++idx ) {
    puts( files[idx] );
  }
  printf( "\n" );

  qsort( files, C_ARRAY_N (files), sizeof (char*), c_pstrvcmp );

  printf( "---File Listing (Lexicographical)---\n" );
  for ( idx = 0; idx < C_ARRAY_N (files); ++idx ) {
    puts( files[idx] );
  }
  printf( "\n" );

  qsort( files, C_ARRAY_N (files), sizeof (char*), pstrnatvcmp );

  printf( "---File Listing (Natural Ordering)---\n" );
  for ( idx = 0; idx < C_ARRAY_N (files); ++idx ) {
    puts( files[idx] );
  }

  return EXIT_SUCCESS;
}

int pstrnatvcmp( const void* p, const void* q )
{
  c_return_value_if_fail( p != NULL, -( p != q ) );
  c_return_value_if_fail( q != NULL, p != q );

  return c_strnatcmp( *((const char**)p), *((const char**)q) );
}
\endcode

There's not a lot of boilerplate in these kinds of "use-case"
examples, but I found that repeatedly including <stdlib.h> just for
EXIT_SUCCESS in these kinds of example programs felt tedious, since
they are more for show than as a component one would want to use in a
script.

When I come to the point of writing more formal testing, I'm sure
those techniques will come in handy.

Best regards,
John D.

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

#12474

I have tried to resolve with other ways as well as i understand but i
was not able to resolve it; only this way works such as i want. I have
changed cost Pi from float to bouble and i have changed c control
value from '121' to 'y'. Now all works fine. I think this binary can
run well on any other windows pc as well as run on my pc. The only
problem is if anyone want to change the name of binary but i think
this is not a common choice.

On Nov 1, 8:06 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> > void main() {
>
> This should be int main().  On modern compilers, this won't compile
> because you are returning values.
Yes, of course........... int main() is more right but my choice is
such common that it is not more a error......

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

#12479

On 11/ 2/11 09:19 AM, zemir wrote:
> I have tried to resolve with other ways as well as i understand but i
> was not able to resolve it; only this way works such as i want. I have
> changed cost Pi from float to bouble and i have changed c control
> value from '121' to 'y'. Now all works fine. I think this binary can
> run well on any other windows pc as well as run on my pc. The only
> problem is if anyone want to change the name of binary but i think
> this is not a common choice.
>
> On Nov 1, 8:06 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>>> void main() {
>>
>> This should be int main().  On modern compilers, this won't compile
>> because you are returning values.
> Yes, of course........... int main() is more right but my choice is
> such common that it is not more a error......

Well it is an error if you use a decent compiler.  In addition to being 
simply wrong, a void function can't return a value!

-- 
Ian Collins

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

#12476

I have tried to resolve with other ways as well as i understand but i
was not able to resolve it; only this way works such as i want. I have
changed cost Pi from float to bouble and i have changed c control
value from '121' to 'y'. Now all works fine. I think this binary can
run well on any other windows pc as well as run on my pc. The only
problem is if anyone want to change the name of binary but i think
this is not a common choice.

On Nov 1, 8:06 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> > void main() {
>
> This should be int main().  On modern compilers, this won't compile
> because you are returning values.
Yes, of course........... int main() is more right but my choice is
such common that it is not more a error......

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

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

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

csiph-web