Re: c/9072: -Wconversion should be split into two distinct flags

Re: c/9072: -Wconversion should be split into two distinct flags

[Segher Boessenkool]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Segher Boessenkool <segher@koffie.nl>
To: Zack Weinberg <zack@codesourcery.com>
Cc: 128950@bugs.debian.org, gcc-patches@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 09:48:17 +0100

 Zack Weinberg wrote:
 > 
 > I'm very much in favor of making -Wconversion more useful, but is
 > there any reason not to shift the argument-type-conversion warnings
 > entirely over to -Wtraditional?  Particularly if the warning is
 > avoided for prototypes in system headers (so that 'sinf' and the like
 > raise no complaints) -- this would, for instance, catch the occasional
 > problem we have with arguments of type 'bool' in GCC itself.
 > 
 > Then -Wconversion would be entirely for dubious type conversions on
 > assignment.
 
 This is the intended behaviour of my patch, modulo in my opinion passing
 a "too wide" argument to a function is a dubious assignment, too.
 
 
 Segher

Re: c/9072: -Wconversion should be split into two distinct flags

[Wolfgang Bangerth]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: 128950@bugs.debian.org, <agthorr@barsoom.org>, <gcc-bugs@gcc.gnu.org>,
   <segher@koffie.nl>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 3 Feb 2003 10:31:41 -0600 (CST)

 On Mon, 3 Feb 2003, Joseph S. Myers wrote:
 > >     Has been analyzed. Patch is even in the audit trail, but
 > >     seems to have become stuck in gcc's patch acceptance machinery...
 > 
 > The patch isn't even one suitable for review, as it lacks testcases.  It
 > is established procedure [0] that patches failing to follow the standards
 > adequately get ignored.
 
 Sorry, don't flame me :-) I am just trying to find ways to get patch 
 submitters and potential reviewers together. 
 
 The bug database is full with reports that have patches attached. If 
 nobody with the ability to judge things takes a look at them, then they 
 will remain open forever. I'm just trying to spark discussion on them. 
 Every once in a while I succeed to get a patch into CVS this way. I think 
 that's better than just letting them sleep.
 
 
 > [0] This is very bad procedure; ignoring patches rather than explaining
 > what is wrong is far too likely to lose potential contributors.
 
 Exactly. If there's someone with little knowledge of gcc processes who 
 manages to find a patch that then never gets any attention, he's not 
 likely to try again next time. If he does get feedback, and be it only 
 that the patch is basically that it is ok but a Changelog entry missing 
 and that the ChangeLog format is described at XYZ, then that'll motivate 
 people. 
 
 I do understand why this is so, but we're doing badly in this field!
 
 Regards
   Wolfgang
 
 PS: Segher - I think the idea of this PR is right, and I would certainly 
 appreciate if you could submit a patch! Thanks!
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: c/9072: -Wconversion should be split into two distinct flags

[Agthorr]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Agthorr <agthorr@barsoom.org>
To: Segher Boessenkool <segher@koffie.nl>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, bangerth@dealii.org,
	128950@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 2 Feb 2003 18:34:44 -0800

 On Mon, Feb 03, 2003 at 02:57:26AM +0100, Segher Boessenkool wrote:
 > I didn't intend for it to be reviewed; I just asked if this was
 > the kind of thing that was asked for.  Writing a good patch for
 > this was far more work (esp. writing a testcase that covers
 > all cases).  I have one in the works but as there was not
 > much interest I dropped it on the floor.  If anyone still wants
 > it, better speak up.
 
 Hello,
 
 I'm the person who originally filed this bug.  Your patch does indeed
 seem to do what I want, and I would love to see it (or something
 similar) in a future version of gcc.  I agree that passing a parameter
 to a function should be considered an assignment for -Wconversion
 purposes.  I also agree with Joseph Myers' statement that -Wconversion
 should "warn for any implicit conversion that may change a value".
 
 > True.  But no consensus was reached on whether this was a good idea
 > at all.  As this is mostly tedious, non-fun work and I don't get
 > paid a dime to do it, and no-one cheered me on, it wasn't a priority
 > work for me (and I forgot about it, really).
 
 CHEER!  CHEER!
 
 I apologize for not responding sooner.  I'm a graduate student and
 have been ill on-and-off since mid-December.  This does not make for
 free time for responding to email :)
 
 I realize that this is not a high-priority issue, but I do appreciate
 any effort that goes into making -Wconversion more useful.
 
 -- Agthorr

Re: c/9072: -Wconversion should be split into two distinct flags

[Segher Boessenkool]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Segher Boessenkool <segher@koffie.nl>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: bangerth@dealii.org, 128950@bugs.debian.org, agthorr@barsoom.org,
	gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 03 Feb 2003 02:57:26 +0100

 Joseph S. Myers wrote:
 > On 2 Feb 2003 bangerth@dealii.org wrote:
 > 
 > 
 >>    Has been analyzed. Patch is even in the audit trail, but
 >>    seems to have become stuck in gcc's patch acceptance machinery...
 > 
 > 
 > The patch isn't even one suitable for review, as it lacks testcases.  It
 
 I didn't intend for it to be reviewed; I just asked if this was
 the kind of thing that was asked for.  Writing a good patch for
 this was far more work (esp. writing a testcase that covers
 all cases).  I have one in the works but as there was not
 much interest I dropped it on the floor.  If anyone still wants
 it, better speak up.
 
 > [0] This is very bad procedure; ignoring patches rather than explaining
 > what is wrong is far too likely to lose potential contributors.  It is,
 
 Agreed.
 
 > however, what happens; patches not following the standards are more
 > tedious to review than ones following the standards, and even many good
 > patches following the standards get ignored.  However, this patch was not
 > ignored; it received several comments on what ought to be done.
 
 True.  But no consensus was reached on whether this was a good idea
 at all.  As this is mostly tedious, non-fun work and I don't get
 paid a dime to do it, and no-one cheered me on, it wasn't a priority
 work for me (and I forgot about it, really).
 
 > I expect a patch that followed the GNU and GCC coding standards, including
 > thorough testcases, and implemented the simple specification I gave for
 > -Wconversion (warn for any implicit conversion that may change a value),
 > would get reviewed.
 
 I'd like to hear whether this change to the semantics of -Wconversion
 is likely to be accepted, first.
 
 
 Cheers,
 
 Segher
 

Re: c/9072: -Wconversion should be split into two distinct flags

[Joseph S. Myers]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: <bangerth@dealii.org>,  <128950@bugs.debian.org>,  <agthorr@barsoom.org>, 
     <gcc-bugs@gcc.gnu.org>,  <segher@koffie.nl>,  <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 3 Feb 2003 00:08:30 +0000 (GMT)

 On 2 Feb 2003 bangerth@dealii.org wrote:
 
 >     Has been analyzed. Patch is even in the audit trail, but
 >     seems to have become stuck in gcc's patch acceptance machinery...
 
 The patch isn't even one suitable for review, as it lacks testcases.  It
 is established procedure [0] that patches failing to follow the standards
 adequately get ignored.  Even with them, it just papers over particular
 problems rather than actually implementing a sensible consistent
 specification for -Wconversion.
 
 [0] This is very bad procedure; ignoring patches rather than explaining
 what is wrong is far too likely to lose potential contributors.  It is,
 however, what happens; patches not following the standards are more
 tedious to review than ones following the standards, and even many good
 patches following the standards get ignored.  However, this patch was not
 ignored; it received several comments on what ought to be done.
 
 I expect a patch that followed the GNU and GCC coding standards, including
 thorough testcases, and implemented the simple specification I gave for
 -Wconversion (warn for any implicit conversion that may change a value),
 would get reviewed.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Re: c/9072: -Wconversion should be split into two distinct flags

[bangerth]

Synopsis: -Wconversion should be split into two distinct flags

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Sun Feb  2 22:54:20 2003
State-Changed-Why:
    Has been analyzed. Patch is even in the audit trail, but
    seems to have become stuck in gcc's patch acceptance machinery...
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9072

Re: c/9072: -Wconversion should be split into two distinct flags

[Joseph S. Myers]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Segher Boessenkool <segher@koffie.nl>,  <128950@bugs.debian.org>, 
     <gcc-patches@gcc.gnu.org>,  <gcc-gnats@gcc.gnu.org>, 
     <debian-gcc@lists.debian.org>
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 11:59:26 +0000 (GMT)

 On Sun, 29 Dec 2002, Zack Weinberg wrote:
 
 > I'm very much in favor of making -Wconversion more useful, but is
 > there any reason not to shift the argument-type-conversion warnings
 > entirely over to -Wtraditional?  Particularly if the warning is
 > avoided for prototypes in system headers (so that 'sinf' and the like
 > raise no complaints) -- this would, for instance, catch the occasional
 > problem we have with arguments of type 'bool' in GCC itself.
 > 
 > Then -Wconversion would be entirely for dubious type conversions on
 > assignment.
 
 I believe -Wconversion should have exactly the following simple
 specification: warn for any implicit conversion that may change a value.  
 This implies -Wsign-compare, parts of the existing -Wconversion (but not
 those for widening through prototype, etc.), and various cases that there
 isn't currently a warning option for (e.g. assigning a signed int to an
 unsigned int), and would be useful for security auditing.  The same
 intelligence used by -Wsign-compare to avoid warning where problems cannot
 in fact arise (e.g. comparing a constant positive signed integer to an
 unsigned integer) should be used.  Depending on how many warnings this
 generates for reasonable code, there may need to be options to disable
 individual parts (beyond the existing -Wno-sign-compare).
 
 Some parts of this might also be useful in -Wtraditional.
 
 Such a -Wconversion implementation would need thorough testcases (probably
 a few hundred lines, likely rather longer than the rest of the patch) for
 all the different cases of implicit conversion that do warn, or don't warn
 because that type conversion can't change values, or don't warn because
 that conversion is converting a constant (etc.) to the same value.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Re: c/9072: -Wconversion should be split into two distinct flags

[Zack Weinberg]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Segher Boessenkool <segher@koffie.nl>
Cc: 128950@bugs.debian.org,  gcc-patches@gcc.gnu.org, 
 gcc-gnats@gcc.gnu.org,
	  debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 01:05:43 -0800

 Segher Boessenkool <segher@koffie.nl> writes:
 > Zack Weinberg wrote:
 >> 
 >> I'm very much in favor of making -Wconversion more useful, but is
 >> there any reason not to shift the argument-type-conversion warnings
 >> entirely over to -Wtraditional?  Particularly if the warning is
 >> avoided for prototypes in system headers (so that 'sinf' and the like
 >> raise no complaints) -- this would, for instance, catch the occasional
 >> problem we have with arguments of type 'bool' in GCC itself.
 >> 
 >> Then -Wconversion would be entirely for dubious type conversions on
 >> assignment.
 >
 > This is the intended behaviour of my patch, modulo in my opinion passing
 > a "too wide" argument to a function is a dubious assignment, too.
 
 I may have misunderstood the effect of your patch - it seemed like you
 would need to give both -Wconversion and -Wtraditional to get the
 argument-type conversion warnings.  I was suggesting that this should
 happen with just -Wtraditional.
 
 zw

Re: c/9072: -Wconversion should be split into two distinct flags

[Zack Weinberg]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Segher Boessenkool <segher@koffie.nl>
Cc: 128950@bugs.debian.org,  gcc-patches@gcc.gnu.org, 
 gcc-gnats@gcc.gnu.org,
	  debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 00:37:58 -0800

 Segher Boessenkool <segher@koffie.nl> writes:
 > Matthias Klose wrote:
 >> It'd be nice if these two behaviors were two controlled via two
 >> separate flags.  The second behavior would have caught a bug I've been
 >> hunting for hours, while the first behavior is very undesirable to me
 >> (and useless since I also compile with -Wstrict-prototypes).
 >
 > I remember having been annoyed by -Wconversion its behaviour, too.  Maybe
 > this patch will do what you want?
 
 I'm very much in favor of making -Wconversion more useful, but is
 there any reason not to shift the argument-type-conversion warnings
 entirely over to -Wtraditional?  Particularly if the warning is
 avoided for prototypes in system headers (so that 'sinf' and the like
 raise no complaints) -- this would, for instance, catch the occasional
 problem we have with arguments of type 'bool' in GCC itself.
 
 Then -Wconversion would be entirely for dubious type conversions on
 assignment.
 
 zw

Re: c/9072: -Wconversion should be split into two distinct flags

[Segher Boessenkool]

The following reply was made to PR c/9072; it has been noted by GNATS.

From: Segher Boessenkool <segher@koffie.nl>
To: 128950@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sat, 28 Dec 2002 17:56:27 +0100

 Matthias Klose wrote:
 > 
 > The -Wconversion option to gcc is documented as doing two things:
 > 
 > ------------------------------------------------------------------------
 > `-Wconversion'
 >      Warn if a prototype causes a type conversion that is different
 >      from what would happen to the same argument in the absence of a
 >      prototype.  This includes conversions of fixed point to floating
 >      and vice versa, and conversions changing the width or signedness
 >      of a fixed point argument except when the same as the default
 >      promotion.
 > 
 >      Also, warn if a negative integer constant expression is implicitly
 >      converted to an unsigned type.  For example, warn about the
 >      assignment `x = -1' if `x' is unsigned.  But do not warn about
 >      explicit casts like `(unsigned) -1'.
 > ------------------------------------------------------------------------
 > 
 > It'd be nice if these two behaviors were two controlled via two
 > separate flags.  The second behavior would have caught a bug I've been
 > hunting for hours, while the first behavior is very undesirable to me
 > (and useless since I also compile with -Wstrict-prototypes).
 
 I remember having been annoyed by -Wconversion its behaviour, too.  Maybe
 this patch will do what you want?
 
 
 Segher
 
 
 
 2002-12-28  Segher Boessenkool  <segher@koffie.nl>
 
 	* c-typeck.c (convert_arguments): Don't warn about arguments
 	passed as `float' unless -Wtraditional given.  Add warning
 	to -Wconversion for passing floating point arguments in smaller
 	precision.  Add warning to -Wtraditional for passing integers with
 	different width due to prototype.
 	* doc/invoke.texi (Warning Options): Document this.  Clarify.
 	* doc/trouble.texi (Protoize Caveats): Ditto.
 
 
 
 *** ../../gcc-clean/gcc/c-typeck.c	Fri Dec 27 03:21:39 2002
 --- ./c-typeck.c	Sat Dec 28 16:44:19 2002
 *************** convert_arguments (typelist, values, nam
 *** 1645,1657 ****
   		    {
   		      /* Warn if any argument is passed as `float',
   			 since without a prototype it would be `double'.  */
 ! 		      if (formal_prec == TYPE_PRECISION (float_type_node))
   			warn_for_assignment ("%s as `float' rather than `double' due to prototype", (char *) 0, name, parmnum + 1);
   		    }
   		  /* Detect integer changing in width or signedness.
 ! 		     These warnings are only activated with
   		     -Wconversion, not with -Wtraditional.  */
 ! 		  else if (warn_conversion && INTEGRAL_TYPE_P (type)
   			   && INTEGRAL_TYPE_P (TREE_TYPE (val)))
   		    {
   		      tree would_have_been = default_conversion (val);
 --- 1645,1659 ----
   		    {
   		      /* Warn if any argument is passed as `float',
   			 since without a prototype it would be `double'.  */
 ! 		      if (warn_traditional && formal_prec == TYPE_PRECISION (float_type_node))
   			warn_for_assignment ("%s as `float' rather than `double' due to prototype", (char *) 0, name, parmnum + 1);
 + 		      else if (warn_conversion && TYPE_PRECISION (TREE_TYPE (val)) < formal_prec)
 + 			warn_for_assignment ("%s with smaller precision due to prototype", (char *) 0, name, parmnum + 1);
   		    }
   		  /* Detect integer changing in width or signedness.
 ! 		     The warning for signedness is only activated with
   		     -Wconversion, not with -Wtraditional.  */
 ! 		  else if (INTEGRAL_TYPE_P (type)
   			   && INTEGRAL_TYPE_P (TREE_TYPE (val)))
   		    {
   		      tree would_have_been = default_conversion (val);
 *************** convert_arguments (typelist, values, nam
 *** 1666,1671 ****
 --- 1668,1675 ----
   		      else if (formal_prec != TYPE_PRECISION (type1))
   			warn_for_assignment ("%s with different width due to prototype", (char *) 0, name, parmnum + 1);
   		      else if (TREE_UNSIGNED (type) == TREE_UNSIGNED (type1))
 + 			;
 + 		      else if (!warn_conversion)
   			;
   		      /* Don't complain if the formal parameter type
   			 is an enum, because we can't tell now whether
 *** ../../gcc-clean/gcc/doc/invoke.texi	Fri Dec 27 03:21:40 2002
 --- ./doc/invoke.texi	Sat Dec 28 16:27:54 2002
 *************** traditional C case.
 *** 2600,2610 ****
   
   @item
   Conversions by prototypes between fixed/floating point values and vice
 ! versa.  The absence of these prototypes when compiling with traditional
   C would cause serious problems.  This is a subset of the possible
   conversion warnings, for the full set use @option{-Wconversion}.
   
   @item
   Use of ISO C style function definitions.  This warning intentionally is
   @emph{not} issued for prototype declarations or variadic functions
   because these ISO C features will appear in your code when using
 --- 2600,2616 ----
   
   @item
   Conversions by prototypes between fixed/floating point values and vice
 ! versa, and conversion by prototypes between different width types when
 ! not equal to the default promotions.
 ! The absence of these prototypes when compiling with traditional
   C would cause serious problems.  This is a subset of the possible
   conversion warnings, for the full set use @option{-Wconversion}.
   
   @item
 + Use of @code{float} in prototypes.  Traditional C would pass such
 + parameters as @code{double}, while ISO C does not.
 + 
 + @item
   Use of ISO C style function definitions.  This warning intentionally is
   @emph{not} issued for prototype declarations or variadic functions
   because these ISO C features will appear in your code when using
 *************** this is why we did not make @option{-Wal
 *** 2671,2681 ****
   
   @item -Wconversion
   @opindex Wconversion
 ! Warn if a prototype causes a type conversion that is different from what
 ! would happen to the same argument in the absence of a prototype.  This
 ! includes conversions of fixed point to floating and vice versa, and
 ! conversions changing the width or signedness of a fixed point argument
 ! except when the same as the default promotion.
   
   Also, warn if a negative integer constant expression is implicitly
   converted to an unsigned type.  For example, warn about the assignment
 --- 2677,2687 ----
   
   @item -Wconversion
   @opindex Wconversion
 ! Warn if a prototype causes an implicit type conversion that is different
 ! from the default promotion.  This includes conversions of fixed point to
 ! floating and vice versa, and conversions changing the width or
 ! signedness of a fixed point argument (except when the same as the default
 ! promotion).
   
   Also, warn if a negative integer constant expression is implicitly
   converted to an unsigned type.  For example, warn about the assignment
 *** ../../gcc-clean/gcc/doc/trouble.texi	Mon Sep 16 00:48:05 2002
 --- ./doc/trouble.texi	Sat Dec 28 16:29:53 2002
 *************** without them.
 *** 1110,1117 ****
   
   @opindex Wconversion
   You can find all the places where this problem might occur by compiling
 ! the program with the @option{-Wconversion} option.  It prints a warning
 ! whenever an argument is converted.
   
   @item
   Both conversion programs can be confused if there are macro calls in and
 --- 1110,1117 ----
   
   @opindex Wconversion
   You can find all the places where this problem might occur by compiling
 ! the program with the @option{-Wtraditional -Wconversion} options.  It
 ! prints a warning whenever an argument is converted.
   
   @item
   Both conversion programs can be confused if there are macro calls in and
 
 

c/9072: -Wconversion should be split into two distinct flags

[Matthias Klose]

>Number:         9072
>Category:       c
>Synopsis:       -Wconversion should be split into two distinct flags
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 27 15:36:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Agthorr <agthorr@barsoom.org>
>Release:        3.2.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
host: i386-linux
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.2 20021212 (Debian prerelease)
>Description:
[ Reported to the Debian BTS as report #128950.
  Please CC 128950@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/128950 ]
	
The -Wconversion option to gcc is documented as doing two things:

------------------------------------------------------------------------
`-Wconversion'
     Warn if a prototype causes a type conversion that is different
     from what would happen to the same argument in the absence of a
     prototype.  This includes conversions of fixed point to floating
     and vice versa, and conversions changing the width or signedness
     of a fixed point argument except when the same as the default
     promotion.

     Also, warn if a negative integer constant expression is implicitly
     converted to an unsigned type.  For example, warn about the
     assignment `x = -1' if `x' is unsigned.  But do not warn about
     explicit casts like `(unsigned) -1'.
------------------------------------------------------------------------

It'd be nice if these two behaviors were two controlled via two
separate flags.  The second behavior would have caught a bug I've been
hunting for hours, while the first behavior is very undesirable to me
(and useless since I also compile with -Wstrict-prototypes).

>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: