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

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

Program to output initials of a name

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

Contents

  Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 03:09 -0700
    Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 03:22 -0700
      Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:32 -0700
        Re: Program to output initials of a name Barry Schwarz <schwarzb@dqel.com> - 2015-10-26 14:34 -0700
    Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 10:38 +0000
      Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:37 -0700
        Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 13:53 +0000
          Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 07:33 -0700
            Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 15:21 +0000
              Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 16:26 +0000
                Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 16:41 +0000
                  Re: Program to output initials of a name Geoff <geoff@invalid.invalid> - 2015-10-26 10:27 -0700
                  Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 17:29 +0000
                    Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:40 +0000
                  Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 13:36 +0000
                    Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:45 +0000
                    Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 15:10 +0100
                      Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 20:08 +0000
                        Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 22:28 +0100
                          Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 21:34 +0000
                            Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 08:50 +0100
                          Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 15:19 +0000
                            Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 22:17 +0100
                              Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 19:54 +0000
                                Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-30 08:44 +0100
                                  Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-30 13:44 -0400
                        Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 04:19 -0700
                          Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 12:50 +0100
                            Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 08:19 -0700
                              Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 10:21 -0700
                              Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 22:34 +0100
                                Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:50 +0000
                    Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 14:13 +0000
                      Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 14:15 +0000
                      Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-27 08:59 -0700
                        Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:34 +0000
                    Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-27 12:09 -0400
                      Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 20:03 +0000
                        Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-27 19:36 -0400
                          Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 09:06 +0100
                          Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 12:28 +0000
                Re: Program to output initials of a name Geoff <geoff@invalid.invalid> - 2015-10-26 10:15 -0700
                Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 07:34 +1300
                  Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 18:40 +0000
                  Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 19:00 +0000
                    Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 08:53 +1300
                      Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 20:41 +0000
                        Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 10:24 +1300
                          Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 16:06 -0700
                            Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 13:16 +1300
                              Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-27 08:46 -0700
                                Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-28 07:25 +1300
                          Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:52 +0000
                    Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:15 +0000
                      Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 19:28 -0700
                        Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:39 +0000
                          Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 02:59 -0700
                            Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 10:24 +0000
                              Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 03:57 -0700
                                Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:09 +0000
                                  Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 11:23 +0000
                                    Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:28 +0000
                                Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:37 +0000
                                  Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:46 +0000
                                    Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:50 +0000
                            Re: Program to output initials of a name supercat@casperkitty.com - 2015-10-27 08:44 -0700
                          Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:19 +0000
                            Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:25 +0000
                            Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 14:24 +0000
              Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-26 14:00 -0400
              Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 11:00 +1300
                Re: Program to output initials of a name Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-10-27 15:39 -0400
        Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:17 -0700
          Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 10:28 -0700
    Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 10:43 +0000
      Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 03:52 -0700
        Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 13:11 +0000
          Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 15:14 +0100
            [OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-10-27 12:01 -0400
              Re: [OT] family naming conventions Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-27 13:17 -0600
                Re: [OT] family naming conventions Siri Cruz <chine.bleu@yahoo.com> - 2015-10-27 13:55 -0700
                Re: [OT] family naming conventions Robert Wessel <robertwessel2@yahoo.com> - 2015-10-27 17:59 -0500
              Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:56 +0000
                Re: [OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-11-10 11:41 -0500
                  Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 19:00 +0000
                    Re: [OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-11-10 14:11 -0500
                      Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 21:19 +0000
                        Re: [OT] family naming conventions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 13:32 -0800
                          Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-13 21:38 +0000
                        Re: [OT] family naming conventions Udyant Wig <udyantw@gmail.com> - 2015-11-11 15:47 +0530
                          Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-13 21:36 +0000
          Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 08:50 -0700
            Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 16:23 +0000
              Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 10:06 -0700
      Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:40 -0700
    Re: Program to output initials of a name Udyant Wig <udyantw@gmail.com> - 2015-10-26 16:20 +0530
      Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 10:55 +0000
        Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:20 -0700
          Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 17:36 +0000
            Re: Program to output initials of a name Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 16:54 -0700
              Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-29 00:50 +0000
                Re: Program to output initials of a name Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:18 -0700
    Re: Program to output initials of a name Barry Schwarz <schwarzb@dqel.com> - 2015-10-26 06:15 -0700
    Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:42 -0700
      Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 11:20 -0700
    Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:44 -0700
      Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 11:21 -0700
    Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:47 -0700
      Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 10:47 -0700
        Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 18:20 +0000
          Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 11:56 -0700
            Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 19:24 +0000
          Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 12:01 -0700
      Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:48 +0000
    Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:43 -0700

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

#74071

On Tue, 2015-10-27, James Kuyper wrote:
> On 10/27/2015 04:03 PM, Jorgen Grahn wrote:
>> On Tue, 2015-10-27, James Kuyper wrote:
>> ...
>>> Why even write a make file? The default rules for Unix make pick up the
>>> CFLAGS environment variable, and use it in an appropriate fashion.
>> 
>> To have them recorded together with the source code.  I hate receiving
>> source code from someone, and having to figure out myself how to build
>> it.
>
> I only suggested that because this particular program has a vey simple
> structure. If you receive source code that relies entirely upon make's
> default rules, among other things that implies that the program consists
> entirely of one module, so it can't be a very complicated build.

In this case, if I got the code from a student I'd see what warning
levels she used, and I could repeat the compilation.  Also suggest
better flags, perhaps with a commit in the version control tool.

But the main reason I'd like a Makefile is for the student's benefit.
You can set an environment variable or use the shell's history
mechanism but they're not tied to /this/ piece of code.

> For programs of any reasonable size, knowing and making good use of
> make's default rules can greatly simplify your make file, but does not
> eliminate the need for one.

Agree.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#73876

On Mon, 26 Oct 2015 16:26:35 +0000, Bartc <bc@freeuk.com> wrote:

>(BTW Clang, the Windows version anyway, will warn against using 
>assignments as conditional expressions. I was under the impression the 
>above version of 'gcc' is really clang, but presumably that warning 
>option is not automatic. Perhaps to keep it 'compatible'.)

It's not clang. Clang identifies itself differently and makes no
mention of gcc. Invoking gcc -v on an up to date Mac yields a
completely different version string: Apple LLVM version 7
(clang-700.1.76) on my system for example. She's running gcc from the
command line. Yes, clang warns about using = in conditional
expressions by default on Mac systems. 

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

#73897

Bartc wrote:
> On 26/10/2015 15:21, Richard Heathfield wrote:
>> On 26/10/15 14:33, Alla _ wrote:
>>
>> <snip>
>>
>>> Here is the information on compiler
>>>
>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>>> build 5658) (LLVM build 2336.11.00)
>
>> So here's a decent set to get you started:
>>
>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef
>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
>
> And a very intimidating set of options that is enough to put anyone off
> for life.
>
> Next problem is how to arrange for that lot to be given to the compiler
> automatically, without having to type them in every time.

If you study your keyboard carefully, you will find a key with a upwards 
pointing arrow on it.

-- 
Ian Collins

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

#73899

On 26/10/15 18:34, Ian Collins wrote:
> Bartc wrote:
>> On 26/10/2015 15:21, Richard Heathfield wrote:
>>> On 26/10/15 14:33, Alla _ wrote:
>>>
>>> <snip>
>>>
>>>> Here is the information on compiler
>>>>
>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>>>> build 5658) (LLVM build 2336.11.00)
>>
>>> So here's a decent set to get you started:
>>>
>>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
>>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
>>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef
>>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
>>
>> And a very intimidating set of options that is enough to put anyone off
>> for life.
>>
>> Next problem is how to arrange for that lot to be given to the compiler
>> automatically, without having to type them in every time.
>
> If you study your keyboard carefully, you will find a key with a upwards
> pointing arrow on it.

But if you're using a PC-XT keyboard, you have to turn off NUM LOCK to 
get access to the up arrow! And then it's too easy to forget to turn it 
on again!

What we really need, of course, is to replace the compiler, the 
makefile, the keyboard, and the command line with a tablet-sized screen 
with a single button on it. (Such devices exist already, so it's just a 
matter of Somebody Else re-programming them.)

The single button would of course not need to be labelled, since it's 
the only one. But, if it did have a label, that label would be "DWIM".

Scott Adams has, of course, been there before me:

http://dilbert.com/strip/1995-03-25

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

#73901

On 26/10/2015 18:34, Ian Collins wrote:
> Bartc wrote:
>> On 26/10/2015 15:21, Richard Heathfield wrote:

>>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
>>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
>>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef
>>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings

>> Next problem is how to arrange for that lot to be given to the compiler
>> automatically, without having to type them in every time.
>
> If you study your keyboard carefully, you will find a key with a upwards
> pointing arrow on it.

On Windows that's next to useless because it uses a strange ordering of 
the command history. (While the 'F7' key that allows you to scroll 
through only shows the first 20 or 30 characters.)

But, you can't seriously be suggesting that that list has to be 
submitted each time to the compiler in such an obtrusive manner.

Any such list, preferably considerably shorter than the above (eg is 
'-Winline' really necessary?) should be hidden way. But then the process 
of hiding away will start detracting from the normal compilation 
process. As will the dozens of unnecessary warnings that will now appear.

(The first compiler I ever used, not for C, was invoked something like 
this, following the "." prompt, and in capitals which I'll refrain from:

  .r algol filename.alg

I forget exactly how the filename was submitted, but I'm fairly sure 
there were no compiler options were ever necessary, not for the student
programs we were compiling.

40 years on, now that computers are so much more powerful and user 
friendly, it's merely necessary to type:

$ gcc -c -W -Wall -pedantic -Wformat-nonliteral -Wcast-align
  -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
  -Wstrict-prototypes -Wno-missing-field-initializers
  -Wmissing-declarations -Winline -Wundef -Wnested-externs
  -Wcast-qual -Wshadow -Wconversion -Wwrite-strings filename.c

That apparently is progress!)

-- 
Bartc

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

#73905

Bartc wrote:
> On 26/10/2015 18:34, Ian Collins wrote:
>> Bartc wrote:
>>> On 26/10/2015 15:21, Richard Heathfield wrote:
>
>>>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
>>>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
>>>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef
>>>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
>
>>> Next problem is how to arrange for that lot to be given to the compiler
>>> automatically, without having to type them in every time.
>>
>> If you study your keyboard carefully, you will find a key with a upwards
>> pointing arrow on it.
>
> On Windows that's next to useless because it uses a strange ordering of
> the command history. (While the 'F7' key that allows you to scroll
> through only shows the first 20 or 30 characters.)

The OP has the good sense not to be using Windows.

> But, you can't seriously be suggesting that that list has to be
> submitted each time to the compiler in such an obtrusive manner.

# alias gc="gcc -std=c99 -W -Wall -pedantic -Wformat-nonliteral 
-Wcast-align -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes 
-Wstrict-prototypes -Wno-missing-field-initializers 
-Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual 
-Wshadow -Wconversion -Wwrite-strings"

 > gc --version
gcc (GCC) 4.9.2

-- 
Ian Collins

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

#73910

On 26/10/2015 19:53, Ian Collins wrote:
> Bartc wrote:
>> On 26/10/2015 18:34, Ian Collins wrote:

>>>> Next problem is how to arrange for that lot to be given to the compiler
>>>> automatically, without having to type them in every time.
>>>
>>> If you study your keyboard carefully, you will find a key with a upwards
>>> pointing arrow on it.


>> But, you can't seriously be suggesting that that list has to be
>> submitted each time to the compiler in such an obtrusive manner.
>
> # alias gc="gcc -std=c99 -W -Wall -pedantic -Wformat-nonliteral
> -Wcast-align -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
> -Wstrict-prototypes -Wno-missing-field-initializers
> -Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual
> -Wshadow -Wconversion -Wwrite-strings"

How does that relate to using the Up arrow key?

>  > gc --version
> gcc (GCC) 4.9.2

When I try it, it forgets the alias when the terminal is restarted.

But don't bother telling me how to make it persistent. I understand 
there are a hundred different ways of achieving this.

I object to having to give so many warning options in a compiler, which 
then obliges you to have to find some such workaround to make using them 
practical. And which apparently (from your comments), makes it less 
viable to use Windows.

If someone has to use C, then why not keep it simple, especially for 
learning with. Then you can develop with it anywhere (unless C is really 
a Unix programming language and nobody's told me).

-- 
Bartc

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

#73913

Bartc wrote:
> On 26/10/2015 19:53, Ian Collins wrote:
>> Bartc wrote:
>>> On 26/10/2015 18:34, Ian Collins wrote:
>
>>>>> Next problem is how to arrange for that lot to be given to the compiler
>>>>> automatically, without having to type them in every time.
>>>>
>>>> If you study your keyboard carefully, you will find a key with a upwards
>>>> pointing arrow on it.
>
>
>>> But, you can't seriously be suggesting that that list has to be
>>> submitted each time to the compiler in such an obtrusive manner.
>>
>> # alias gc="gcc -std=c99 -W -Wall -pedantic -Wformat-nonliteral
>> -Wcast-align -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
>> -Wstrict-prototypes -Wno-missing-field-initializers
>> -Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual
>> -Wshadow -Wconversion -Wwrite-strings"
>
> How does that relate to using the Up arrow key?

It helps those who have trouble finding it.

>>   > gc --version
>> gcc (GCC) 4.9.2
>
> When I try it, it forgets the alias when the terminal is restarted.
>
> But don't bother telling me how to make it persistent. I understand
> there are a hundred different ways of achieving this.

In this case, there are probably more like 96 ways.

> I object to having to give so many warning options in a compiler, which
> then obliges you to have to find some such workaround to make using them
> practical. And which apparently (from your comments), makes it less
> viable to use Windows.

Windows makes it less viable to use Windows...

Due to the traditionally naff command shell on Windows (I do like the so 
called power shell), most people, me included, use an IDE on Windows. 
With a IDE, you only have to set up your preferred options once.  You 
can do the same in a Unix (like) environment if you struggle with basic 
shell usage (of finding the up arrow key).

> If someone has to use C, then why not keep it simple, especially for
> learning with. Then you can develop with it anywhere (unless C is really
> a Unix programming language and nobody's told me).

Which is the basic philosophy of the native compiler (cc) on my 
preferred platform:  if you want C89, use "-std=C89", if you want C99, 
use "-std=C99" and if you want C11, use "-std=C11".  All of these 
attempt to be as close to conforming as they can.  Plain cc implies the 
current standard.  If you want checking outside of the standards, use lint.

-- 
Ian Collins

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

#73919

Ian Collins <ian-news@hotmail.com> writes:
[...]
> Which is the basic philosophy of the native compiler (cc) on my 
> preferred platform:  if you want C89, use "-std=C89", if you want C99, 
> use "-std=C99" and if you want C11, use "-std=C11".  All of these 
> attempt to be as close to conforming as they can.  Plain cc implies the 
> current standard.  If you want checking outside of the standards, use lint.

Is "cc" on your platform a name (alias, symlink, wrapper, ...) for gcc?
If so, the argument to the -std= option is case-sensitive:

    -std=c89
    -std=c90 (equivalent, but not recognized until recently)
    -std=c99
    -std=c11

With gcc, not specifying "-std=..." defaults to "-std=gnu89" with older
versions, to "-std=gnu11" starting with release 5.

clang follows gcc's behavior fairly closely.

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

#73925

Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> [...]
>> Which is the basic philosophy of the native compiler (cc) on my
>> preferred platform:  if you want C89, use "-std=C89", if you want C99,
>> use "-std=C99" and if you want C11, use "-std=C11".  All of these
>> attempt to be as close to conforming as they can.  Plain cc implies the
>> current standard.  If you want checking outside of the standards, use lint.
>
> Is "cc" on your platform a name (alias, symlink, wrapper, ...) for gcc?

No, it's the Sun/Oracle C compiler.

-- 
Ian Collins

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

#73967

Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> [...]
>>> Which is the basic philosophy of the native compiler (cc) on my
>>> preferred platform:  if you want C89, use "-std=C89", if you want C99,
>>> use "-std=C99" and if you want C11, use "-std=C11".  All of these
>>> attempt to be as close to conforming as they can.  Plain cc implies the
>>> current standard.  If you want checking outside of the standards, use lint.
>>
>> Is "cc" on your platform a name (alias, symlink, wrapper, ...) for gcc?
>
> No, it's the Sun/Oracle C compiler.

Interesting.  I'm surprised that it uses an option syntax that's so
similar to what gcc uses, but without being entirely consistent.  Is the
argument case-insensitive (e.g., does "-std=c89" work)?  The version of
Sun/Oracle's C compiler (for Solaris 5.9) doesn't recognize either form.

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

#73986

Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Keith Thompson wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>> [...]
>>>> Which is the basic philosophy of the native compiler (cc) on my
>>>> preferred platform:  if you want C89, use "-std=C89", if you want C99,
>>>> use "-std=C99" and if you want C11, use "-std=C11".  All of these
>>>> attempt to be as close to conforming as they can.  Plain cc implies the
>>>> current standard.  If you want checking outside of the standards, use lint.
>>>
>>> Is "cc" on your platform a name (alias, symlink, wrapper, ...) for gcc?
>>
>> No, it's the Sun/Oracle C compiler.
>
> Interesting.  I'm surprised that it uses an option syntax that's so
> similar to what gcc uses, but without being entirely consistent.  Is the
> argument case-insensitive (e.g., does "-std=c89" work)?  The version of
> Sun/Oracle's C compiler (for Solaris 5.9) doesn't recognize either form.

Ah, I see what you were asking.  It was a consistent typo on my part, 
CXX should have been cXX.

I am surprised that anyone is still using Solaris 9!

-- 
Ian Collins

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

#75586

Ian Collins <ian-news@hotmail.com> wrote:

> Bartc wrote:

> > I object to having to give so many warning options in a compiler, which
> > then obliges you to have to find some such workaround to make using them
> > practical. And which apparently (from your comments), makes it less
> > viable to use Windows.
> 
> Windows makes it less viable to use Windows...
> 
> Due to the traditionally naff command shell on Windows (I do like the so 
> called power shell), most people, me included, use an IDE on Windows. 
> With a IDE, you only have to set up your preferred options once.  You 
> can do the same in a Unix (like) environment if you struggle with basic 
> shell usage (of finding the up arrow key).

Come on, Ian, now you're being as moronic about Windows as Bart is about
Gnu/Linux. Don't give us _more_ reason to hate Gnu, especially not when
it's unjustified.

Richard

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

#73928

On 26/10/15 19:00, Bartc wrote:
> On 26/10/2015 18:34, Ian Collins wrote:
>> Bartc wrote:
>>> On 26/10/2015 15:21, Richard Heathfield wrote:
>
>>>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
>>>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
>>>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef
>>>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
>
>>> Next problem is how to arrange for that lot to be given to the compiler
>>> automatically, without having to type them in every time.
>>
>> If you study your keyboard carefully, you will find a key with a upwards
>> pointing arrow on it.
>
> On Windows that's next to useless because it uses a strange ordering of
> the command history. (While the 'F7' key that allows you to scroll
> through only shows the first 20 or 30 characters.)

That's funny, because I use the up-arrow to recall commands (including 
compilation commands) all the time on Windows (well, all the time when 
I'm using Windows, which isn't that often but it does happen).

I don't find it next to useless *at all*. I find it very practical and 
intuitive.

> But, you can't seriously be suggesting that that list has to be
> submitted each time to the compiler in such an obtrusive manner.

make

That's all you have to type. It's ridiculously easy. All you have to do 
is set up the makefile, which is /also/ ridiculously easy.

> Any such list, preferably considerably shorter than the above (eg is
> '-Winline' really necessary?) should be hidden way.

make

> But then the process
> of hiding away will start detracting from the normal compilation
> process.

You can't have it both ways. Either you want the details tucked out of 
sight or you don't.


> As will the dozens of unnecessary warnings that will now appear.

By "unnecessary warnings" I take it you mean "warnings". I want to see 
*all* of them, so that /I/ can be the judge of whether or not they are 
necessary.

> (The first compiler I ever used, not for C, was invoked something like
> this, following the "." prompt, and in capitals which I'll refrain from:
>
>   .r algol filename.alg
>
> I forget exactly how the filename was submitted, but I'm fairly sure
> there were no compiler options were ever necessary, not for the student
> programs we were compiling.

It's hardly surprising that an ancient compiler for an ancient language 
had relatively primitive diagnostic flexibility. Thankfully, things have 
moved on.

> 40 years on, now that computers are so much more powerful and user
> friendly, it's merely necessary to type:

make

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

#73929

On Tuesday, October 27, 2015 at 2:15:35 AM UTC, Richard Heathfield wrote:
> 
> By "unnecessary warnings" I take it you mean "warnings". I want to see 
> *all* of them, so that /I/ can be the judge of whether or not they are 
> necessary.
> 
That strategy doesn't scale up.
If compilers warn about things like narrowing conversions (e.g. reading
a character using fgetc() into an int, and assigning to a char)
then pretty soon you get hundreds of such warnings, which make the real
warnings (e.g. pointer converted to wrong type, use of uninitialised
variable) get lost.

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

#73931

On 27/10/15 02:28, Malcolm McLean wrote:
> On Tuesday, October 27, 2015 at 2:15:35 AM UTC, Richard Heathfield wrote:
>>
>> By "unnecessary warnings" I take it you mean "warnings". I want to see
>> *all* of them, so that /I/ can be the judge of whether or not they are
>> necessary.
>>
> That strategy doesn't scale up.

Yes, it does. :-)

> If compilers warn about things like narrowing conversions (e.g. reading
> a character using fgetc() into an int, and assigning to a char)
> then pretty soon you get hundreds of such warnings, which make the real
> warnings (e.g. pointer converted to wrong type, use of uninitialised
> variable) get lost.

A conversion that potentially loses data *is* a real warning, and one 
that we should take seriously.

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

#73936

On Tuesday, October 27, 2015 at 2:40:08 AM UTC, Richard Heathfield wrote:
> On 27/10/15 02:28, Malcolm McLean wrote:
> > On Tuesday, October 27, 2015 at 2:15:35 AM UTC, Richard Heathfield wrote:
> 
> A conversion that potentially loses data *is* a real warning, and one 
> that we should take seriously.
> 
The constraints on the value are not the same as the width of the type, and
are generally too difficult for the compiler to work out at compile time.
My compiler even warns abut double to float conversions, "may lose precision".
Well yes, any programmer with the slightest experience who uses a float is
aware that he's trading precision for speed or size. 

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

#73937

On 27/10/15 09:59, Malcolm McLean wrote:
> On Tuesday, October 27, 2015 at 2:40:08 AM UTC, Richard Heathfield wrote:
>> On 27/10/15 02:28, Malcolm McLean wrote:
>>> On Tuesday, October 27, 2015 at 2:15:35 AM UTC, Richard Heathfield wrote:
>>
>> A conversion that potentially loses data *is* a real warning, and one
>> that we should take seriously.
>>
> The constraints on the value are not the same as the width of the type, and
> are generally too difficult for the compiler to work out at compile time.

It may even be impossible for the compiler to work out constraints on 
the value that are narrower than the width of the type. And so we get 
this warning when we're converting an int to a char, even if the value 
came from a char in the first place (eg text stream -> fgets -> array -> 
toupper -> array). Nevertheless, the compiler is right to diagnose code 
such as: d = e * f + g * h; if d is, say, an int but e, f, g, and h are 
longs and long is wider than int.

> My compiler even warns abut double to float conversions, "may lose precision".

Quite right; so it should.

> Well yes, any programmer with the slightest experience who uses a float is
> aware that he's trading precision for speed or size.

This discussion is in a thread started by a programmer who would be the 
first to concede that she /doesn't/ have the slightest experience.

As for scaling up, there is no need whatsoever for diagnostic switches 
to be immutable. A team working on a big project may find it more 
convenient to work with a less chatty compiler but, from time to time 
(perhaps weekly or fortnightly), it may be worth turning up the 
compiler's heat to see what pops out of the woodwork. Diagnostic 
messages that turn out to be spurious suggest that, at the very least, a 
comment in the code is called for, explaining the diagnostic message and 
exactly why it isn't a problem, so that anyone reviewing the code can 
check for themselves.

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

#73938

On Tuesday, October 27, 2015 at 10:24:47 AM UTC, Richard Heathfield wrote:
>
> Diagnostic messages that turn out to be spurious suggest that, at the very least, a 
> comment in the code is called for, explaining the diagnostic message and 
> exactly why it isn't a problem, so that anyone reviewing the code can 
> check for themselves.
>
Then the code gets littered with useless comments to explain away the behaviour
of some compiler or other. 
Most code can and should compile under any conforming C compiler. Only
code that interacts with non-standard IO needs to be platform specific (OK,
and a few parallel algorithms and things like that). But warnings vary according
to the compiler, or the options with which the using programmer invokes the
compiler. You can't reasonably be expected to handle every warning. And in fact
most of the big packages, like ffmpeg, don't compile without warnings.

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

#73939

On 27/10/15 10:57, Malcolm McLean wrote:
> On Tuesday, October 27, 2015 at 10:24:47 AM UTC, Richard Heathfield wrote:
>>
>> Diagnostic messages that turn out to be spurious suggest that, at the very least, a
>> comment in the code is called for, explaining the diagnostic message and
>> exactly why it isn't a problem, so that anyone reviewing the code can
>> check for themselves.
>>
> Then the code gets littered with useless comments to explain away the behaviour
> of some compiler or other.

No, the code gets enhanced by useful comments that explain the code for 
the benefit of maintenance programmers. That's what comments are *for*.

> Most code can and should compile under any conforming C compiler. Only
> code that interacts with non-standard IO needs to be platform specific (OK,
> and a few parallel algorithms and things like that). But warnings vary according
> to the compiler, or the options with which the using programmer invokes the
> compiler. You can't reasonably be expected to handle every warning. And in fact
> most of the big packages, like ffmpeg, don't compile without warnings.

I used to insist on a clean compile at -W4 (the highest) when using the 
Microsoft compiler, and it is in fact possible to compile cleanly at 
that warning level (unless you #include <math.h> - or did they fix that 
now?) without having to mangle the code.

That works for Microsoft, but it doesn't work for gcc. You're right - 
you /can't/ be expected to handle every warning in the code if you're 
using a very fussy compiler, such as gcc with all flags fluttering. So 
you use the diagnostics to identify *possible* problems with the code 
(which is what "warning" is supposed to mean, right?), and then either 
fix them or document the fact that they aren't actual problems.

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

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

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

csiph-web