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

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

Problem with the function that should display new letter

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

Contents

  Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 09:52 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:06 -0700
      Re: Problem with the function that should display new letter John Gordon <gordon@panix.com> - 2015-10-27 17:16 +0000
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:28 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:09 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:12 -0700
      Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-27 13:12 -0700
        Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-27 13:23 -0700
          Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-27 13:49 -0700
            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 21:27 +0000
              Re: Problem with the function that should display new letter Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-27 18:00 -0400
              Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 02:53 +0000
                Re: Problem with the function that should display new letter Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 00:43 -0500
                Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 06:08 +0000
                  Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 08:44 +0000
              Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 09:26 +0100
                Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:44 +0000
                  Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 10:40 +0100
                  Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:44 -0700
                Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:35 -0700
    Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:40 -0400
      Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:47 -0400
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:38 -0700
          Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 16:46 -0400
      Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:39 -0700
    Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 18:20 +0000
      Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:36 -0700
      Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:09 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:51 -0700
    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 19:25 +0000
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:27 -0700
      Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 10:07 +1300
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 00:50 -0700
          Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:04 +1300
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 01:13 -0700
            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:40 +0000
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:02 +0000
              Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 11:28 +0000
                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:57 +0000
                  Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:53 +0000
                  Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 13:33 +0000
          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:35 +0000
            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:59 +0000
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:04 +0000
                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:38 +0000
                  Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:43 +0000
                    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 12:10 +0000
                      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:58 +0000
                        Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 13:55 +0000
                          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 14:02 +0000
                            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 15:01 +0000
                              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 15:44 +0000
                                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:22 +0000
                                  Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 16:26 +0000
                                    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:44 +0000
                                      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 18:45 +0000
                                        Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 19:26 +0000
                                          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 20:44 +0000
                                  Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 22:59 +0100
                                    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 22:48 +0000
                                      Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 01:14 +0100
                                        Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:07 +0000
                                          Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 14:07 +0100
                                            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 13:57 +0000
                                              Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 16:22 +0100
                                                Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 08:38 -0700
                                                  Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 17:25 +0100
                                                    Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 12:46 -0700
                                                      Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:03 +0100
                                                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 19:19 +0000
                                                  Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:54 +0100
                                                    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-30 12:20 +0000
                                                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 21:36 +0000
                                                  Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 10:47 +1300
                                                    Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 22:25 +0000
                                                    Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:59 +0100
                                                  Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 10:07 +0100
                          Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 16:25 +0100
                            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:01 +0000
                              Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 09:50 -0700
                              Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:57 +0000
                                Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:25 -0700
                              Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:23 -0700
                                Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:44 +0000
              Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 07:07 -0700
            Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 07:07 -0700
              Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 09:08 -0700
                Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 14:29 -0700
                  Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 16:10 -0700
                    Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 20:27 -0700
                      Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-31 12:40 -0700
                        Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:16 -0800
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:36 -0700
      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 10:46 +0000
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:56 -0700
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:00 -0700
          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:02 +0000
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:05 -0700
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:14 +0000
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:14 -0700
              Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 11:26 +0000
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:26 +0000
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:29 -0700
                  Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:23 -0400
                    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 07:44 -0700
                      Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 11:39 -0400
                        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:52 -0700
                      Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 16:02 +0000
                        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:56 -0700
                          Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 13:41 -0400
                            Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:46 +0000
                              Re: Problem with the function that should display new letter Udyant Wig <udyantw@gmail.com> - 2015-10-30 00:14 +0530
                                Re: Problem with the function that should display new letter raltbos@xs4all.nl (Richard Bos) - 2015-10-29 19:30 +0000
                                  Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 22:08 +0000
                                    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 22:28 -0700
                                Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:10 -0700
                                  Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-30 08:56 -0700
                                    Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:18 -0700
                              Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 09:11 +1300
                            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:21 -0700
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:04 -0700
          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:11 +0000
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:19 -0700
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:24 +0000
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:26 -0700
                  Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-29 08:31 -0700
              Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:42 -0400
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 08:31 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 10:17 -0700
      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:36 +0000
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:18 -0700
          Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:36 +0000
            Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:38 +0000
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 02:26 -0700
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:32 +0000
                Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:39 +0000
            Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 03:59 -0700
              Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 11:18 +0000
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:24 -0700
                  Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-30 14:18 -0400
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:34 -0700
                  Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:39 +0000
                    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:57 -0700
                      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:06 +0000
              Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 08:49 -0700
                Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 10:18 -0700
      Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 11:48 -0700
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:23 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:42 -0700
      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:13 +0000
      Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:17 +0000
        Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 10:23 +0000
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:39 -0700
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:45 -0700
      Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:55 +0000
        Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 07:05 -0700
      Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-30 23:29 +0000
        Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:14 +0000
          Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:02 +0000
            Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 18:05 +0000
              Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:46 +0000
                Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 08:46 -0800
                  Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 23:43 +0000
                    Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 16:05 -0800
                Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 21:41 +0000
                  Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 22:46 +0000
            Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 18:22 +0000
              Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:57 +0000
          Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:20 +0000
        Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 13:38 +0000
          Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-31 11:28 -0700
            Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 00:06 +0000
          Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:58 +0000
    Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-31 01:14 -0700

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

#74109

Bartc <bc@freeuk.com> wrote:
> On 28/10/2015 15:25, David Brown wrote:

(snip on main(int argc, char **argv)

>> You are reading the developers handbook for a *nix system, and you are
>> surprised and confused that it refers to UNIX, and think that means that
>> Windows does something different?  The people writing that handbook are
>> only writing about how things work in *nix in general, and FreeBSD in
>> particular.
 
> No, I'm fairly sure that Windows does it differently (but people are so 
> used to C implementations pulling strings behind the scenes, that even 
> experts have come to think that Windows actually supplies those argc and 
> argv parameters).

At some point before it gets to main(), windows has to generate
the appropriate argc and argv.

One that windows C compilers usually have as an option is to
expand the command line similar to C shell globbing.

That is:

C:\>  myprog *.c

without this option will give one argument to main(), but with it
will give a list containing all the *.c files in the current directory.

How windows calls non-C programs doesn't apply here.

-- glen

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

#74131

On Wed, 28 Oct 2015 21:57:42 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>One that windows C compilers usually have as an option is to
>expand the command line similar to C shell globbing.
>
>That is:
>
>C:\>  myprog *.c
>
>without this option will give one argument to main(), but with it
>will give a list containing all the *.c files in the current directory.

What compiler and what option is that? I don't see it in Visual Studio
and I've always had to do my own globbing.

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

#74130

On Wed, 28 Oct 2015 16:01:02 +0000, Bartc <bc@freeuk.com> wrote:

>> To save your limited googling abilities, console applications in Windows
>> get their argc/argv parameters like in Unix.
>
>No they don't.
>
>If they use C, then some C startup code will set up those parameters 
>(possibly by calling GetCommandLine() in the Win32 API like I have to).
>
>But Windows itself does not pass anything like that.

Not correct.

Windows _console_ programs written in C, that start with the
traditional int main (int argc, char *argv[]) will receive the
arguments via the application startup code from the system just as
they do in *nix.

Windows _GUI_ programs, written in C, that start with the traditional 
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpszCmdLine, int cmdShow) will receive a pointer to the complete
command line in the lpszCmdLine parameter. 

GetCommandLine() when used in a console program returns a pointer to
the complete command line as a single string just as in the
lpszCmdLine parameter for a GUI program.

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

#74133

On 29/10/2015 01:23, Geoff wrote:
> On Wed, 28 Oct 2015 16:01:02 +0000, Bartc <bc@freeuk.com> wrote:

>> If they use C, then some C startup code will set up those parameters
>> (possibly by calling GetCommandLine() in the Win32 API like I have to).
>>
>> But Windows itself does not pass anything like that.
>
> Not correct.
>
> Windows _console_ programs written in C, that start with the
> traditional int main (int argc, char *argv[]) will receive the
> arguments via the application startup code from the system just as
> they do in *nix.
>
> Windows _GUI_ programs, written in C, that start with the traditional
> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
> LPSTR lpszCmdLine, int cmdShow) will receive a pointer to the complete
> command line in the lpszCmdLine parameter.
>
> GetCommandLine() when used in a console program returns a pointer to
> the complete command line as a single string just as in the
> lpszCmdLine parameter for a GUI program.
>

Windows GUI programs can have a main() entry point (of either kind), and 
console programs can have a WinMain entry point.

Both main(argc,argc) and WinMain(a,b,c,d) kinds of 'entry points' (they 
aren't true ones), require special start-up code that is not part of 
Windows, not part of the C standard library, and not part of an 
application, that sets up the argc, argc, or a,b,c,d arguments to pass 
to those functions.

Usually a C implementation will quietly take care of those details.

Those of us wanting to make use of the C library but also trying to 
eliminate an untidy dependency on a C compiler, have to take a DIY 
approach to those functions if we want to the main(argc,argv) or 
WinMain(a,b,c,d) forms.

-- 
Bartc

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

#74080

Bartc <bc@freeuk.com> writes:
> On 28/10/2015 08:35, Richard Heathfield wrote:
>> So, in any hosted implementation (such as the one you are using), the
>> interface to main must be either:
>>
>> int main(void);
>> OR
>> int main(int argc, char **argv);
>
> (That's what I used to think. But you don't get the latter interface 
> automatically, not under Windows anyway.
>
> The only interface the OS recognises is 'int main(void)' (or 'int 
> anyfunction(void)' depending on what entry point name is used in the 
> executable).
>
> The use of 'main(argc, argv)' requires that the C implementation 
> arranges to call an internal function which obtains these arguments from 
> the OS. It's usually done transparently so that it looks like the OS 
> calls main(argc, argv) directly.

You say it's not done automatically; then you say it's "usually done
transparently".

Sounds like it *is* done automatically.  It doesn't matter whether the
OS calls main directly, or whether it "looks like" it does so.  The
point is that it works.

> You find this stuff out when, for example, you try and use the 'ld' 
> linker directly without going through gcc.)

So don't do that.  Sure *you* might have circumstances where that might
be necessary.  Alla doesn't.  You're adding needless confusion.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74307

Richard Heathfield <rjh@cpax.org.uk> writes:

> [snip] in any hosted implementation (such as the one you are
> using), the interface to main must be either:
>
> int main(void);
> OR
> int main(int argc, char **argv);
> OR
> an exact equivalent of one of those two interfaces.

This isn't quite right.  The function main() may
be declared without a prototype:

    int main();

and also may be defined without one, eg,

    int
    main( argc, argv )
        int argc;
        char *argv[];
    { ... }

The difference is perhaps minor, but definitely
non-zero and IMO should be noted.

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

#74333

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [snip] in any hosted implementation (such as the one you are
>> using), the interface to main must be either:
>>
>> int main(void);
>> OR
>> int main(int argc, char **argv);
>> OR
>> an exact equivalent of one of those two interfaces.
>
> This isn't quite right.  The function main() may
> be declared without a prototype:
>
>     int main();
>
> and also may be defined without one, eg,
>
>     int
>     main( argc, argv )
>         int argc;
>         char *argv[];
>     { ... }
>
> The difference is perhaps minor, but definitely
> non-zero and IMO should be noted.

The forms explicitly required by the standard are
    int main(void)
and
    int main(int argc, char *argv[])
"or equivalent, or in some other implementation-defined manner".

There is no *direct* statement that a definition without a prototype
is permitted.  To argue that the forms without a prototype are
permitted, you have to establish that those forms are "equivalent"
to the forms with a prototype.  And if you're making that argument,
then you actually agree with what Richard said, unless you're making
a distinction between the standard's "equivalent" and Richard's
"exact equivalent".

I've argued before that (a) the literal wording of the standard
can be read to imply that they are *not* equivalent, but (b) the
1989 Committee did not want to break every existing C program,
so they must have intended to permit main to be defined without a
prototype, but (c) as a programmer, you can neatly avoid the entire
issue by using prototypes consistently, something that you should
be doing anyway.

I've discussed the issue at some length here:
http://the-flat-trantor-society.blogspot.com/2014/02/c-standard-quibbles.html
A more up-to-date version of the same article is here:
https://github.com/Keith-S-Thompson/the-flat-trantor-society/blob/master/005-c-standard-quibbles.md#is-int-main-necessarily-valid-should-it-be
or, equivalently:
http://preview.tinyurl.com/oplvk5b

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74371

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> [snip] in any hosted implementation (such as the one you are
>>> using), the interface to main must be either:
>>>
>>> int main(void);
>>> OR
>>> int main(int argc, char **argv);
>>> OR
>>> an exact equivalent of one of those two interfaces.
>>
>> This isn't quite right.  The function main() may
>> be declared without a prototype:
>>
>>     int main();
>>
>> and also may be defined without one, eg,
>>
>>     int
>>     main( argc, argv )
>>         int argc;
>>         char *argv[];
>>     { ... }
>>
>> The difference is perhaps minor, but definitely
>> non-zero and IMO should be noted.
>
> The forms explicitly required by the standard are
>     int main(void)
> and
>     int main(int argc, char *argv[])
> "or equivalent, or in some other implementation-defined manner".

More precisely, the Standard requires that 'main' be
defined [with a return type of int and] with no parameters

    int main(void){ /* ... */ }

or with two parameters [which may have different names]

    int main(int argc, char *argv[]){ /* ... */ }

or equivalent, [or in some implmentation-defined manner,
which is beside the point for this discussion].

> There is no *direct* statement that a definition without a
> prototype is permitted.  To argue that the forms without a
> prototype are permitted, you have to establish that those forms
> are "equivalent" to the forms with a prototype.  And if you're
> making that argument, then you actually agree with what Richard
> said, unless you're making a distinction between the standard's
> "equivalent" and Richard's "exact equivalent".

I think you have reached some wrong conclusions here because you
are taking two distinct questions and treating them as being
synonymous.  Let me elaborate.

Even if there is some question about whether main() may be
defined without a prototype, I believe there is general agreement
that there may be a declaration (without giving a definition) of
main() that does not include a prototype.  Do you agree?

Furthermore, whether or not we consider a definition of main()
that does not have a prototype to be equivalent to a definition
of main() that does have a prototype, there is no question that
two declarations of main() (neither attached to any definition)
are /not/ equivalent if one has a prototype and the other does
not.  Do you agree?

The point I'm making is different from the question about what
the Standard says about main(), because that is concerned with
how main() is /defined/, whereas my point is about how main() may
be /declared/ (not as part of a definition).  I think it is fair
to say that even though the first matter may be debatable, the
second matter is not.  Do you agree?

The key takeaway here is there are two different contexts in
which we might ask if two things are "equivalent", and the
point I'm making is in a different context than the question
of what the Standard allows for main()'s definition.  Sorry if
that was unclear or confusing.

> I've argued before that (a) the literal wording of the standard
> can be read to imply that they are *not* equivalent, but (b) the
> 1989 Committee did not want to break every existing C program, so
> they must have intended to permit main to be defined without a
> prototype, but (c) as a programmer, you can neatly avoid the
> entire issue by using prototypes consistently, something that you
> should be doing anyway.

I understand what you're saying, but it's not really relevant in
the context I was trying to address.

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

#74380

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>> [snip] in any hosted implementation (such as the one you are
>>>> using), the interface to main must be either:
>>>>
>>>> int main(void);
>>>> OR
>>>> int main(int argc, char **argv);
>>>> OR
>>>> an exact equivalent of one of those two interfaces.
>>>
>>> This isn't quite right.  The function main() may
>>> be declared without a prototype:
>>>
>>>     int main();
>>>
>>> and also may be defined without one, eg,
>>>
>>>     int
>>>     main( argc, argv )
>>>         int argc;
>>>         char *argv[];
>>>     { ... }
>>>
>>> The difference is perhaps minor, but definitely
>>> non-zero and IMO should be noted.
>>
>> The forms explicitly required by the standard are
>>     int main(void)
>> and
>>     int main(int argc, char *argv[])
>> "or equivalent, or in some other implementation-defined manner".
>
> More precisely, the Standard requires that 'main' be
> defined [with a return type of int and] with no parameters
>
>     int main(void){ /* ... */ }
>
> or with two parameters [which may have different names]
>
>     int main(int argc, char *argv[]){ /* ... */ }
>
> or equivalent, [or in some implmentation-defined manner,
> which is beside the point for this discussion].
>
>> There is no *direct* statement that a definition without a
>> prototype is permitted.  To argue that the forms without a
>> prototype are permitted, you have to establish that those forms
>> are "equivalent" to the forms with a prototype.  And if you're
>> making that argument, then you actually agree with what Richard
>> said, unless you're making a distinction between the standard's
>> "equivalent" and Richard's "exact equivalent".
>
> I think you have reached some wrong conclusions here because you
> are taking two distinct questions and treating them as being
> synonymous.  Let me elaborate.
>
> Even if there is some question about whether main() may be
> defined without a prototype, I believe there is general agreement
> that there may be a declaration (without giving a definition) of
> main() that does not include a prototype.  Do you agree?

Sure.

> Furthermore, whether or not we consider a definition of main()
> that does not have a prototype to be equivalent to a definition
> of main() that does have a prototype, there is no question that
> two declarations of main() (neither attached to any definition)
> are /not/ equivalent if one has a prototype and the other does
> not.  Do you agree?

I agree that they're not equivalent.  I don't agree that there's no
question; others have given different opinions on the matter.  (We
needn't get into that detail.)

> The point I'm making is different from the question about what
> the Standard says about main(), because that is concerned with
> how main() is /defined/, whereas my point is about how main() may
> be /declared/ (not as part of a definition).  I think it is fair
> to say that even though the first matter may be debatable, the
> second matter is not.  Do you agree?

I won't express an opinion on whether it's debatable, but otherwise I
agree with you.  For example, this:

    int main();
    int main(void) { }

is valid.  (It's also poor style, but that's not the point we're
discussiong.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74395

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
[snip]

>> Furthermore, whether or not we consider a definition of main()
>> that does not have a prototype to be equivalent to a definition
>> of main() that does have a prototype, there is no question that
>> two declarations of main() (neither attached to any definition)
>> are /not/ equivalent if one has a prototype and the other does
>> not.  Do you agree?
>
> I agree that they're not equivalent.  I don't agree that there's
> no question;  others have given different opinions on the matter.
> (We needn't get into that detail.)

How does anyone think that a declaration of main() without a
prototype and a declaration of main() with a prototype are
equivalent (to be clear, considered just as declarations, with no
associated definitions involved)?  If translation unit A declares
main() with no prototype, and translation unit B declares main()
with a prototype, and neither TU A nor TU B defines main(), how
can those declarations be equivalent?  It is possible the two
declarations have the same consequences is some circumstances,
ie, what is going on (or not) in other translation units, but
AFAICT it is not possible that they have the same consequences in
all (external) circumstances.  Given that, how can they be viewed
as equivalent?

Note that I am not asking you to defend the view that the two are
equivalent, since you don't agree with it, but just to explain
the view of someone who would say that they are equivalent.  I'm
at a loss to understand how someone could have that point of
view.

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

#74478

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [snip]
>
>>> Furthermore, whether or not we consider a definition of main()
>>> that does not have a prototype to be equivalent to a definition
>>> of main() that does have a prototype, there is no question that
>>> two declarations of main() (neither attached to any definition)
>>> are /not/ equivalent if one has a prototype and the other does
>>> not.  Do you agree?
>>
>> I agree that they're not equivalent.  I don't agree that there's
>> no question;  others have given different opinions on the matter.
>> (We needn't get into that detail.)
>
> How does anyone think that a declaration of main() without a
> prototype and a declaration of main() with a prototype are
> equivalent (to be clear, considered just as declarations, with no
> associated definitions involved)?
[snip]

I have again foolishly glossed over the distinction between
declarations and definitions.  There has been a great deal of
discussion about *definitions* of main.  There has been very little
about *declarations* of main.  Because declaring main other than
as part of its definition is uncommon and not particularly useful,
I tend to ignore it.

The opinion has been stated that *definitions* of main with and without
a prototype are "equivalent".  Concretely, it was argued that these:

    int main() { }

    int main(void) { }

are equivalent programs.  My counterargument (with which I think you'd
agree) was that these:

    int main() { if (0) return main(42); }

    int main(void) { if (0) return main(42); }

are not equivalent (the first is valid, the second violates a
constraint).

Sorry for the confusion.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74633

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>> [snip]
>>
>>>> Furthermore, whether or not we consider a definition of main()
>>>> that does not have a prototype to be equivalent to a definition
>>>> of main() that does have a prototype, there is no question that
>>>> two declarations of main() (neither attached to any definition)
>>>> are /not/ equivalent if one has a prototype and the other does
>>>> not.  Do you agree?
>>>
>>> I agree that they're not equivalent.  I don't agree that there's
>>> no question;  others have given different opinions on the matter.
>>> (We needn't get into that detail.)
>>
>> How does anyone think that a declaration of main() without a
>> prototype and a declaration of main() with a prototype are
>> equivalent (to be clear, considered just as declarations, with no
>> associated definitions involved)?
>
> [snip]
>
> I have again foolishly glossed over the distinction between
> declarations and definitions.  [snip]

Perhaps, but you may also have been led astray by my earlier
posting that gave both a declaration and a definition and
(unintentionally on my part) implicitly equated them.

> The opinion has been stated that *definitions* of main with and
> without a prototype are "equivalent".  Concretely, it was argued
> that these:
>
>     int main() { }
>
>     int main(void) { }
>
> are equivalent programs.  My counterargument (with which I think
> you'd agree) was that these:
>
>     int main() { if (0) return main(42); }
>
>     int main(void) { if (0) return main(42); }
>
> are not equivalent (the first is valid, the second violates a
> constraint).

I don't think there is any question but that the second pair are
not equivalent /as programs/.  The question is, are they
equivalent in the sense that's intended as it was used in the
relevant section of the Standard.  Because the Standard does not
spell that out clearly, there is no way to answer the question
short of guessing what was intended (or filing a defect report or
something like that).

> Sorry for the confusion.

Well we ultimately got here, so no worries.

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

#74144

Hello!

I am going a bit further with these cipher versions.

Now in the main function I have a word as one of the arguments
typed in by the user. 
According to the task I have to make sure that the argument contain
only letters. Trying to use isalpha on argv[1] led to a segmentation
fault. 

I am using a while loop to access each letter in argv. I would
be grateful for a hint on what I am doing wrong. Also, if I 
take out this for loop for argv, the function works perfectly. 

int main (int argc, char *argv[])
{
    char message[80];
    int argv_len = strlen(argv[1]);
    int i, j;
    
    if (argc == 1 || argc > 2)
    {
        printf("\a");
        printf("Please, provide one argument - a word\n");
        return 1;
    }
    
    for (i = 0; i < argv_len; i++)
    {
        while(j != '\0')
        {
            if (!isalpha(argv[i][j]))
                return 1;
                
            j++;
        }
    }
    
    char *key = argv[1];
        
    printf("Please, enter your message: \n");
        
    if (fgets (message, sizeof message, stdin) != NULL)
            new_text(message, key);
    
    return 0;
}
Thank you!

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

#74145

On 29/10/15 10:36, Alla _ wrote:
> Hello!
>
> I am going a bit further with these cipher versions.
>
> Now in the main function I have a word as one of the arguments
> typed in by the user.
> According to the task I have to make sure that the argument contain
> only letters. Trying to use isalpha on argv[1] led to a segmentation
> fault.

When you use the command line arguments version of main, argv is a 
pointer to the first element in an array of pointers to char.

argv[argc] is a null pointer.

If argc > 0, then argv[0] through argv[argc - 1] are pointers to char.

So argv[1] is a pointer to char.

isalpha() takes a character (expressed as an int), not a pointer.

So it's not surprising that things start to go wrong if you pass a 
pointer instead.

> I am using a while loop to access each letter in argv. I would
> be grateful for a hint on what I am doing wrong. Also, if I
> take out this for loop for argv, the function works perfectly.

You are missing, at the very least:

#include <stdio.h>
#include <string.h>
#include <ctype.h>

> int main (int argc, char *argv[])
> {
>      char message[80];
>      int argv_len = strlen(argv[1]);

As long as there /is/ an argv[1], this is fine (although I hope you have 
"the size_t type" written down on your to-learn-later list).

strlen takes a pointer to char, specifically the address of the first 
character in a string, and returns the length of the string. So far so good.


>      int i, j;
>
>      if (argc == 1 || argc > 2)
>      {
>          printf("\a");
>          printf("Please, provide one argument - a word\n");
>          return 1;
>      }

Again, that's fine, although you will want to add "portable return 
values from main()" to your "to-learn-later" list.

>
>      for (i = 0; i < argv_len; i++)
>      {
>          while(j != '\0')

Since you haven't given j a value, what do you expect this test to do? 
Because whatever it is that you're expecting, it isn't going to happen 
the way you think!

Don't just stick random lines into your code. What is j's job? (The name 
gives me no clue.) Until you know what j is for and can describe it in a 
way that makes it clear to other people, you should not put it into your 
program.

>          {
>              if (!isalpha(argv[i][j]))

Since j could be anything at this stage, it's very *unlikely* to be a 
legal subscript for argv[i]. Hence your segfault.

<snip>


-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#74148

<snip>

Thank you very much for your help. I understand my mistake now.

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

#74149

I have tried to add the initial value of j,
but, when called, the program still returns 
segmentation fault.

for (i = 0; i < argv_len; i++)
    {
        j = 0;
        
        while(j != '\0')
        {
            if (!isalpha(argv[i][j]))
                return 1;
                
            j++;
        }
    }

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

#74150

On 29/10/15 11:00, Alla _ wrote:
> I have tried to add the initial value of j,
> but, when called, the program still returns
> segmentation fault.
>
> for (i = 0; i < argv_len; i++)
>      {
>          j = 0;
>
>          while(j != '\0')

Again, you're not thinking it through. What do you want this test to do?

My educated guess is that you are intending to ensure that you don't 
overstep the bounds of argv[i], so you are looking for the null 
terminating character of argv[i]. You can do that like this:

while(argv[i][j] != '\0')

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#74152

On Thursday, October 29, 2015 at 3:02:45 PM UTC+4, Richard Heathfield wrote:
> On 29/10/15 11:00, Alla _ wrote:
> > I have tried to add the initial value of j,
> > but, when called, the program still returns
> > segmentation fault.
> >
> > for (i = 0; i < argv_len; i++)
> >      {
> >          j = 0;
> >
> >          while(j != '\0')
> 
> Again, you're not thinking it through. What do you want this test to do?
> 
> My educated guess is that you are intending to ensure that you don't 
> overstep the bounds of argv[i], so you are looking for the null 
> terminating character of argv[i]. You can do that like this:
> 
> while(argv[i][j] != '\0')
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

I am so sorry! I did post a wrong code, accidentally.
Here is the one I have now:

for (i = 0; i < argv_len; i++)
    {
        for (j = 0; j != '\0'; j++)
        {
            if (!isalpha(argv[i][j]))
                return 1;
        }
    }

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

#74154

On 29/10/15 11:05, Alla _ wrote:
> On Thursday, October 29, 2015 at 3:02:45 PM UTC+4, Richard Heathfield wrote:
>> On 29/10/15 11:00, Alla _ wrote:
>>> I have tried to add the initial value of j,
>>> but, when called, the program still returns
>>> segmentation fault.
>>>
>>> for (i = 0; i < argv_len; i++)
>>>       {
>>>           j = 0;
>>>
>>>           while(j != '\0')
>>
>> Again, you're not thinking it through. What do you want this test to do?
>>
>> My educated guess is that you are intending to ensure that you don't
>> overstep the bounds of argv[i], so you are looking for the null
>> terminating character of argv[i]. You can do that like this:
>>
>> while(argv[i][j] != '\0')
>>
> I am so sorry! I did post a wrong code, accidentally.
> Here is the one I have now:
>
> for (i = 0; i < argv_len; i++)
>      {
>          for (j = 0; j != '\0'; j++)
>          {

You swapped the while-loop for a for-loop, but again, you didn't think 
through what you want the loop control test to do.

My educated guess, still, is that you are intending to ensure that you 
don't overstep the bounds of argv[i], so you are looking for the null
terminating character of argv[i]. You can do that like this:

for(j = 0; argv[i][j] != '\0'; j++)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#74155

On Thursday, October 29, 2015 at 3:02:45 PM UTC+4, Richard Heathfield wrote:
> On 29/10/15 11:00, Alla _ wrote:
> > I have tried to add the initial value of j,
> > but, when called, the program still returns
> > segmentation fault.
> >
> > for (i = 0; i < argv_len; i++)
> >      {
> >          j = 0;
> >
> >          while(j != '\0')
> 
> Again, you're not thinking it through. What do you want this test to do?
> 
> My educated guess is that you are intending to ensure that you don't 
> overstep the bounds of argv[i], so you are looking for the null 
> terminating character of argv[i]. You can do that like this:
> 
> while(argv[i][j] != '\0')
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

I am sorry again. 

Did you have a chance to see my explanation below?
Please, let me repeat it here, followed by a correct
part of the code:

My goal is to check if the argv[1] is a word, i.e.
there are only letters in it. If there are some, or all,
non-alphabetical characters, the program should return 1. 

To do that, I iterate through each character in argv[1]
to check if it is an alphabetical character. 

for (i = 0; i < argv_len; i++)
    {
        for (j = 0; j != '\0'; j++)
        {
            if (!isalpha(argv[i][j]))
                return 1;
        }
    }

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

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

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

csiph-web