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

#73941

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

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

It might be handy for a language to permit a relatively simple
annotation such as (sic) to an expression or statement, the point being
to alert the reader that the slightly odd-looking code was probably
intended.  The compiler would not normally produce warnings for such
expressions but could be asked to show suppressed warnings (indeed, it
would be helpful for it to show only suppressed warnings) so one could
check them every now and then.

In C, I suppose a compiler could take such action on seeing /* sic */.

<snip>
-- 
Ben.

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

#73943

On 27/10/15 11:23, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> 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*.
>
> It might be handy for a language to permit a relatively simple
> annotation such as (sic) to an expression or statement, the point being
> to alert the reader that the slightly odd-looking code was probably
> intended.  The compiler would not normally produce warnings for such
> expressions but could be asked to show suppressed warnings (indeed, it
> would be helpful for it to show only suppressed warnings) so one could
> check them every now and then.
>
> In C, I suppose a compiler could take such action on seeing /* sic */.

It is interesting to consider what the equivalent would be in COBOL, 
that most verbose of languages. Possibly:

SIC TRANSIT GLORIA MUNDI

placed just before the slightly odd-looking code, and then presumably 
just after it one would have to write

SIC TRANSIT GLORIA FRIDI.

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

#73944

On 27/10/2015 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.
> 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.
>

When I compile my (generated) C modules with that long list of warnings, 
then for every 1000 lines of source code, I get 200 to 350 lines of 
warnings and notes (550 lines in one case). Somewhere in that lot might 
be an actual error.

Otherwise, typically using 'gcc -m64 -c -O3' via my IDE, I usually get 
clean compiles and the code currently works perfectly. If there is a 
problem, then I would first try a different compiler (because using 
different options is a pain) which tend to have a stricter set of 
default options.

-- 
Bartc

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

#73945

On 27/10/15 11:37, Bartc wrote:
> On 27/10/2015 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.
>> 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.
>>
>
> When I compile my (generated) C modules with that long list of warnings,
> then for every 1000 lines of source code, I get 200 to 350 lines of
> warnings and notes (550 lines in one case).

I can think of at least two explanations for that amount of diagnostic 
feedback. One of those explanations would not be to your liking.

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

#73946

On 27/10/2015 11:46, Richard Heathfield wrote:
> On 27/10/15 11:37, Bartc wrote:

>> When I compile my (generated) C modules with that long list of warnings,
>> then for every 1000 lines of source code, I get 200 to 350 lines of
>> warnings and notes (550 lines in one case).
>
> I can think of at least two explanations for that amount of diagnostic
> feedback. One of those explanations would not be to your liking.

What's the other reason?

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

#73966

On Tuesday, October 27, 2015 at 4:59:57 AM UTC-5, Malcolm McLean wrote:
> 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.

IMHO, a lot of difficulties with numerical semantics result from the fact that
most languages only define one type for each size of floating-point number and
each size/signedness combination of integers, when there are different use
cases which require different semantics.

If I had my druthers, languages would include one type of each format which
was "strict" and warn of coercion to/from any other format, another of each
format other than the largest unsigned int which would behave as though all
computations were performed on the largest type of that general kind
(floating-point or signed-integer) but then silently downcast, and another
which would let the compiler pick whatever implementation was fastest.
Given three 32-bit floating-point numbers f1, f2, and f3, there are some
algorithms where one will routinely need f4=((double)f1+f2+f3) and others
others where one will routinely need f4=((float)(f1+f2)+f3); the C language
allows compilers to interpret f4=f1+f2+f3; either way at its convenience,
so code which needs one particular behavior and omits the cast will work on
some machines but not others.  Allowing type types of f1-f4 to be declared
in a way which would indicate what semantics would be required would help
greatly to alleviate such issues.

Additionally, including distinct types in the language would help compilers
better judge programmer intention, and consequently judge when code likely
deviates from that intention (implying a warning would be useful).  Given
the code: f1=f2*0.1; d1=f3*0.1f; some compilers would warn about the first;
few would warn about the second.  Depending upon what the code is wanting to
do, however, either might yield desired or undesired behavior (though I'd
consider the second more worthy of a warning than the first).  If f1-f2
were "strict" types, a compiler would warn in the first case; if they were
looser types, the use of the double constant 0.1 would be entirely
appropriate (note that 16000003.0f*0.1f yields 1600000.375--0.075 above the
numerically-correct value; 16000003.0f*0.1 would yield 1600000.25 which is
only 0.05 below the numerically-correct value).  I personally think the
latter form as written should generate warning regardless of whether d1
and f3 are strict or loose types, since 0.1f should be a strict type and
the product of 0.1f and f3 should be strict, meaning the coercion to double
should generate a warning unless the code makes clear the intention via
d1=(float)(f3*0.1f).


Warnings about possibly-unexpected conversions can be helpful, but only if
programmers have a means of indicating what they're genuinely expecting.

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

#73940

On 27/10/2015 02:39, 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:
>>>
>>> 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.

By a beginner? What exactly are they supposed to do about it? There 
several alternatives:

* Ignore the warning, and have dozens of such warnings swamp every 
single compilation for each of the many hundreds a times a source needs 
to be compiled, for pretty much every source file.

But someone who's inexperienced might not which can be safely ignored. 
And the real errors and warnings will be harder to see.

* Put in a comment that this is intended, but it doesn't stop the warnings

* Put in a cast, which could also need a comment, and which I understand 
you hate

* Change the code, so that instead of assigning to char, you're 
assigning to int. But that is not practical when assigning to an element 
of a char array.

* Or get rid of all those over-zealous warnings.

Can you understand that getting lots of useless warning is very frustrating?

To the OP, my suggestion is to set up, somehow, two ways of compiling a 
source file: using the compiler with default options, or ones they feel 
they need, and another stricter one with a few more warnings enabled, 
but not going as mad as with your list.

Then only invoke the latter when there is some inexplicable problem with 
theit code.


-- 
Bartc

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

#73942

On 27/10/15 11:19, Bartc wrote:
> On 27/10/2015 02:39, 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:
>>>>
>>>> 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.
>
> By a beginner? What exactly are they supposed to do about it?

Ask about it and learn from the answers.

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

#74081

On Tue, 2015-10-27, Bartc wrote:
> On 27/10/2015 02:39, 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:
>>>>
>>>> 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.
>
> By a beginner? What exactly are they supposed to do about it? There 
> several alternatives:
>
> * Ignore the warning, and have dozens of such warnings swamp every 
> single compilation for each of the many hundreds a times a source needs 
> to be compiled, for pretty much every source file.
>
> But someone who's inexperienced might not which can be safely ignored. 
> And the real errors and warnings will be harder to see.
>
> * Put in a comment that this is intended, but it doesn't stop the warnings
>
> * Put in a cast, which could also need a comment, and which I understand 
> you hate

That's what we did in one project, when someone added gcc -Wconversion
(which I think is the option you're talking about).

It made the code /worse/, not better: the compiler would now tolerate
/real/ errors introduced in that expression too!  Plus the added noise
of the cast itself, in code which was designed to do a lot of safe
narrowing.

-Wconversion is one of the warning options where, well, sure, it's
interesting to see all places where we throw away bits ... but there's
no sane way to /eliminate/ the warnings.

> * Change the code, so that instead of assigning to char, you're 
> assigning to int. But that is not practical when assigning to an element 
> of a char array.
>
> * Or get rid of all those over-zealous warnings.
>
> Can you understand that getting lots of useless warning is very frustrating?

/Jorgen

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

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

#73892

On 10/26/2015 11:21 AM, Richard Heathfield wrote:
...
> Okay, if that's gcc, which it looks very much like it is, then you could 
> do worse than use the following options BUT before I show them to you, 
> you obviously realise that any suggestion here provokes a veritable 
> storm of objections. Be prepared for that, and consider very closely any 
> advice on specific warning settings offered to you by, for example, Eric 
> Sosman, Keith Thompson, Ian Collins, Richard Bos, Ben Bacarisse, and 
> James Kuyper. I'm not suggesting that other people might not have good 
> suggestions, but you might want to consider those half-dozen names as 
> being 'trumps', so to speak. If a majority of them share the same 
> opinion (positive or negative) about a compiler warning, it's probably 
> worth going with that majority.
> 
> 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

In light of downstream complaints about how difficult it is to use such
a long list of options, here's my approach:
I don't use as many warning options as Richard does, but it's still a
long list. In the script that gets executed whenever I start up tcsh, my
normal shell for Unix, I have a line that says:

setenv CFLAGS '-std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes'

The line would only look slightly different if you were using one of the
other popular shells for Unix.

The Unix make utility implements a large number of default rules, even
if you don't provide it with any make file. CFLAGS is an environment
variable that has a special meaning under those default rules. The net
result is that if there's a file named 'program.c', and I type
   make program.o

It will execute the following command:
    cc -std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes   -c -o undefunc.o undefunc.c

So it's only necessary for me to type that long list of options once, in
my setup script.

It's been a long time since I made use of the corresponding features of
Windows, so I'm not the best person to ask about such things, but I'm
quite certain that corresponding features did exist in Windows 3.1. I
doubt they've been removed in more modern versions, unless they've been
replaced by something Microsoft thought was better. If so, you might
even be lucky enough to agree with them about that.
-- 
James Kuyper

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

#73916

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)
>
> Okay, if that's gcc, which it looks very much like it is, then you could
> do worse than use the following options BUT before I show them to you,
> you obviously realise that any suggestion here provokes a veritable
> storm of objections. Be prepared for that, and consider very closely any
> advice on specific warning settings offered to you by, for example, Eric
> Sosman, Keith Thompson, Ian Collins, Richard Bos, Ben Bacarisse, and
> James Kuyper. I'm not suggesting that other people might not have good
> suggestions, but you might want to consider those half-dozen names as
> being 'trumps', so to speak. If a majority of them share the same
> opinion (positive or negative) about a compiler warning, it's probably
> worth going with that majority.
>
> 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

An interesting set, many of these are saying "compile the code more like 
C++"!  I usually just use

-std=c99 -Wall -pedantic -Wextra -Werror

which is usually enough for C++ code (obviously with an appropriate std=).

I always thought that -pedantic needed a "std" to be pedantic about..

-- 
Ian Collins

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

#74000

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

> I always thought that -pedantic needed a "std" to be pedantic about..

In gcc's case, there's always a "standard," whether specified explicitly
or not. The default has changed at least once, but there always is (or
at least, has been for a very long time) one.

Clang doesn't seem to document anything on the subject. Its manual
*does* seem to indicate that a -std statement is required, but a quick
test shows that this is not the case.

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

#73878

Alla _ <modelling.data@gmail.com> writes:
> On Monday, October 26, 2015 at 2:38:25 PM UTC+4, Richard Heathfield wrote:
[...]
>> You would do well to spot this yourself, but if you're really stuck, 
>> scroll down past all the "spoiler space".
>> 
>> 
>>   Answer follows 100 spoiler warnings.
>> 
>>   Answer follows 99 spoiler warnings.
[...]
>>   Answer follows 2 spoiler warnings.
>> 
>>   Answer follows 1 spoiler warning.
>> 
>>   Answer follows 0 spoiler warnings.
>> 
>> = is the ASSIGNMENT operator. You wanted ==, the COMPARISON operator.
[...]
> Oh, no. Yet again. Same old mistake. I've
> made it many times, talked to myself about it,
> thought it's fixed, and ... voila - only one =,
> instead of ==.

It would be very helpful if you'd to trim quoted text when you post a
followup.  There's no need to quote *all* of the parent article; just
quote enough so that your followup mekes sense.  In particular, don't
quote signatures (unless you're actually commenting on them).

> What's interesting, my compiler didn't even 
> bother itself to warn me this time, and 
> compiled the program. 

It's likely there's a way to coax your compiler to produce more
warnings.

[...]

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

#73881

> It would be very helpful if you'd to trim quoted text when you post a
> followup.  There's no need to quote *all* of the parent article; just
> quote enough so that your followup mekes sense.  In particular, don't
> quote signatures (unless you're actually commenting on them).
> 
Keith,
I am sorry for this; yes, I did it again. I remember
you and other members asked me about it a few times, and you have 
also taught me how to write reader-friendly posts in terms 
of line length. I will do my best to abide by these rules: 
breach is unintentional.  
Thank you!

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

#73840

On 26/10/2015 10:09, Alla _ wrote:

> void toupper_initials(char user_name[])
> {
>      char initials[80];
>      char space = ' ';
>      int len = strlen(user_name);
>      int i;
>
>      printf("%c", toupper(user_name[0]));
>
>      for (i = 1; i < len; i++) /** also can be while(user_name[i] != '\0') **/
>      {
>
>           /** if the user has entered several names (divided by spaces),
>              then convert to upper case each letter after the space in the
>              user_name array; if the letter is in upper case, toupper prints
>              the letter as it is
>           **/
>          if (user_name[i] = space)
>          {
>              initials[i] = toupper(user_name[i + 1]);
>
>              printf("%c", initials[i]);
>          }
>      }
>      /** if there are no spaces between letters, the for loop terminates
>          after scanning the whole string, and should produce no outcome;
>          thus the program prints out only the first letter in upper case **/
>
>      printf("\n");
> }

The logic is wrong. You're using 'i' to index along the name, but also 
using i to index along the initials that are being generated. You need 
two separate indices.

If the name is "  bartholomew j sIMPSON " (the name itself may or may 
not follow conventional rules), indexed from 0 to 23.

The initials will be "BJS", indexed from 0 to 2.

The rule for an initial might be that it's the first non-space letter, 
or the first letter following a space. That suggests a flag indicating 
whether it's in 'space' mode, or 'non-space' mode, starting off in space 
mode. Whenever a letter is encountered in space mode, that will be the 
next letter of the initial, and the mode changes to non-space mode. [I 
haven't tested this...]

That's not perfect, but it's a start. It won't work for names that 
already have initials that aren't separated ("JB Priestly"), but then 
the input needs to follow some conventions. But probably you aren't 
worried about such details.

-- 
Bartc

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

#73842

On Monday, October 26, 2015 at 10:43:43 AM UTC, Bart wrote:
> On 26/10/2015 10:09, Alla _ wrote:
> 
> That's not perfect, but it's a start. It won't work for names that 
> already have initials that aren't separated ("JB Priestly"), but then 
> the input needs to follow some conventions. But probably you aren't 
> worried about such details.
> 
Completely off-topic, but it's JB Priestley. 

A descendant of his was a classmate. He was also JB Priestley. All the boys in
their family are give names starting with J and B in his honour. 

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

#73949

On Mon, 2015-10-26, Malcolm McLean wrote:
> On Monday, October 26, 2015 at 10:43:43 AM UTC, Bart wrote:
>> On 26/10/2015 10:09, Alla _ wrote:
>> 
>> That's not perfect, but it's a start. It won't work for names that 
>> already have initials that aren't separated ("JB Priestly"), but then 
>> the input needs to follow some conventions. But probably you aren't 
>> worried about such details.
>> 
> Completely off-topic, but it's JB Priestley. 
>
> A descendant of his was a classmate. He was also JB Priestley. All the boys in
> their family are give names starting with J and B in his honour. 

Still way off-topic, but very weird that the rule would apply to boys,
but not girls ...

/Jorgen

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

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

#73961

On 27/10/15 14:11, Jorgen Grahn wrote:
> On Mon, 2015-10-26, Malcolm McLean wrote:
>> On Monday, October 26, 2015 at 10:43:43 AM UTC, Bart wrote:
>>> On 26/10/2015 10:09, Alla _ wrote:
>>>
>>> That's not perfect, but it's a start. It won't work for names that 
>>> already have initials that aren't separated ("JB Priestly"), but then 
>>> the input needs to follow some conventions. But probably you aren't 
>>> worried about such details.
>>>
>> Completely off-topic, but it's JB Priestley. 
>>
>> A descendant of his was a classmate. He was also JB Priestley. All the boys in
>> their family are give names starting with J and B in his honour. 
> 
> Still way off-topic, but very weird that the rule would apply to boys,
> but not girls ...
> 

I knew a family in which all 6 siblings, girls and boys, were J.Smith.

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

#73970 — [OT] family naming conventions

On 10/27/2015 10:14 AM, David Brown wrote:
> On 27/10/15 14:11, Jorgen Grahn wrote:
...
>> Still way off-topic, but very weird that the rule would apply to boys,
>> but not girls ...
>>
> 
> I knew a family in which all 6 siblings, girls and boys, were J.Smith.

My wife and all three of her sisters were given names starting with the
same Chinese character. Those names are part of a pattern that goes back
hundreds of years. <https://en.wikipedia.org/wiki/Generation_name>
-- 
James Kuyper

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

#73995 — Re: [OT] family naming conventions

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/27/2015 10:14 AM, David Brown wrote:
>> On 27/10/15 14:11, Jorgen Grahn wrote:
> ...
>>> Still way off-topic, but very weird that the rule would apply to boys,
>>> but not girls ...
>>>
>> 
>> I knew a family in which all 6 siblings, girls and boys, were J.Smith.
>
> My wife and all three of her sisters were given names starting with the
> same Chinese character. Those names are part of a pattern that goes back
> hundreds of years. <https://en.wikipedia.org/wiki/Generation_name>

And of course we have the case of George Foreman's sons (George Jr.,
George III, George IV, George V, George VI).

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

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

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

csiph-web