Bug#141015: c/8609: Superfluous warning when -std=c99/gnu99 and noreturn on main()
Well, I also compile with -Wmissing-noreturn. If I add the noreturn attribute to main, gcc complains that the function returns. If I remove the noreturn, gcc complains that the function does not return. gcc can't have it both ways. ;) On Mon, Nov 18, 2002 at 10:55:07PM -, [EMAIL PROTECTED] wrote: > Synopsis: Superfluous warning when -std=c99/gnu99 and noreturn on main() > > State-Changed-From-To: open->analyzed > State-Changed-By: bangerth > State-Changed-When: Mon Nov 18 14:55:06 2002 > State-Changed-Why: > I can reproduce this. I think, the warning comes from the fact > that in C99, main() has an implicit "return 0" at its end, > indicating that if you fall off the end of main(), the > programs return value is zero. This also explains why it > only happens with main(), not if you rename the function. > > That being said, since you cannot control who calls main > and how, what reason should you have to mark main() as > noreturn? It should not make any difference, so why do > it? I have difficulty seeing this as a bug... > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8609 >
Bug#128950: c/9072: -Wconversion should be split into two distinct flags
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
Bug#121639: libgcj2: serialization of java.util.Date is broken
Package: libgcj2
Version: 1:3.0.2-3
Severity: important
Tags: patch
Serialization of the java.util.Date class is broken in libgcj.
Although the "Date" class is correctly marked as "implements
java.io.Serializable", the actual data stored in the Date class is
marked transient! This means that the field won't actually get
serialized. Below is a patch to correct the problem. I could write a
small demonstration program to show the difference in behavior from
javac, if desired.
-- Agthorr
--- gcc-20011024/libjava/java/util/Date.java~ Tue Jan 9 01:43:39 2001
+++ gcc-20011024/libjava/java/util/Date.javaWed Nov 28 16:09:36 2001
@@ -24,7 +24,7 @@ public class Date implements java.io.Ser
{
private static final long serialVersionUID = 7523967970034938905L;
- transient private long millis;
+ private long millis;
public Date() { millis = System.currentTimeMillis(); }
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux eleutheromania 2.4.12 #1 Fri Oct 12 15:06:20 PDT 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages libgcj2 depends on:
ii libc6 2.2.4-5GNU C Library: Shared libraries an
ii libgcc1 1:3.0.2-3 GCC support library.
ii zlib1g1:1.1.3-16 compression library - runtime
Bug#121636: libgcj2: ObjectInputStream.readObject() calls constructors
Package: libgcj2
Version: 1:3.0.2-3
Severity: normal
The implementation of ObjectInputStream.readObject() in this version
of libgcj calls the constructor of the serialize object it is reading.
Sun's implementation does not do this, nor (I think) did earlier
versions of libgcj. Below is a sample program which prints "foo" once
with javac, but twice with gcj/libgcj.
I found this while debugging a real program, where it was causing me
quite a bit of confusion.
-- Agthorr
import java.io.*;
class Break implements Serializable {
int x;
public Break () {
System.err.println ("foo");
}
static public void main (String [] args)
throws java.io.IOException, java.lang.ClassNotFoundException
{
ByteArrayOutputStream bufout = new ByteArrayOutputStream ();
ObjectOutputStream out = new ObjectOutputStream (bufout);
Break foo = new Break ();
foo.x = 5;
out.writeObject (foo);
byte [] bytes = bufout.toByteArray ();
ByteArrayInputStream bufin = new ByteArrayInputStream (bytes);
ObjectInputStream in = new ObjectInputStream (bufin);
in.readObject ();
}
public String toString () {return Integer.toString (x);}
}
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux eleutheromania 2.4.12 #1 Fri Oct 12 15:06:20 PDT 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages libgcj2 depends on:
ii libc6 2.2.4-5GNU C Library: Shared libraries an
ii libgcc1 1:3.0.2-3 GCC support library.
ii zlib1g1:1.1.3-16 compression library - runtime
Bug#126411: gcc-3.0: Improper warning when casting from pointer to non-const array to const
Package: gcc-3.0
Version: 1:3.0.2-4
Severity: normal
gcc generates a warning for the following test program, that I believe
is inappropriate. The warning is that it cannot implicitly cast from
(foo *) to (const foo *). This occurs when foo is an array type. The
sample program compiles without warnings if you remove the "const"
keyword, or if you remove the [16] making foo an array.
This also occurs in gcc 2.95.4.
This is a problem for me since I normally compile with -Werror and
make rigorous use of const. I can make explicit casts as a temporary
fix, but this makes my code ugly ;)
-- Agthorr
typedef char foo[16];
void bar (const foo *xyzzy)
{}
int main(void)
{
foo bozz;
bar (&bozz);
return 0;
}
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux eleutheromania 2.4.16 #1 Tue Dec 4 11:20:43 PST 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages gcc-3.0 depends on:
ii binutils2.11.92.0.12.3-3 The GNU assembler, linker and bina
ii cpp-3.0 1:3.0.2-4The GNU C preprocessor.
ii gcc-3.0-base1:3.0.2-4The GNU Compiler Collection (base
ii libc6 2.2.4-7 GNU C Library: Shared libraries an
ii libgcc1 1:3.0.2-4GCC support library.
Bug#128950: gcc-3.0: -Wconversion should be split into two distinct flags
Package: gcc-3.0 Version: 1:3.0.3-1 Severity: normal 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). -- Agthorr -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux eleutheromania 2.4.16 #1 Tue Dec 4 11:20:43 PST 2001 i686 Locale: LANG=C, LC_CTYPE= Versions of packages gcc-3.0 depends on: ii binutils2.11.92.0.12.3-4 The GNU assembler, linker and bina ii cpp-3.0 1:3.0.3-1The GNU C preprocessor. ii gcc-3.0-base1:3.0.3-1The GNU Compiler Collection (base ii libc6 2.2.4-7 GNU C Library: Shared libraries an ii libgcc1 1:3.0.3-1GCC support library.
Bug#140995: gcc-3.0: -Wswitch (also part of -Wall) is broken
Package: gcc-3.0
Version: 1:3.0.4-6
Severity: normal
-Wswitch doesn't actually seem to do anything in gcc-3.0, although it
works in gcc 2.95.4. Here's what the documentation says it *should*
do:
`-Wswitch'
Warn whenever a `switch' statement has an index of enumeral type
and lacks a `case' for one or more of the named codes of that
enumeration. (The presence of a `default' label prevents this
warning.) `case' labels outside the enumeration range also
provoke warnings when this option is used.
Here's a sample program:
enum foo {
FUBAR = 0,
SNAFU = 1
};
int main(void)
{
enum foo boop;
switch (boop) {
case FUBAR:
break;
case 3:
break;
}
return 0;
}
and here's what happen with gcc 2.95.4:
volition:~/tmp$ gcc -Wswitch switch.c
switch.c: In function `main':
switch.c:16: warning: enumeration value `SNAFU' not handled in switch
switch.c:16: warning: case value `3' not in enumerated type `foo'
volition:~/tmp$ gcc --version
2.95.4
volition:~/tmp$
but here's what happens with gcc-3.0:
volition:~/tmp$ gcc-3.0 -Wswitch switch.c
volition:~/tmp$
I normally compile with gcc 3.0 since it has so many more warnings
that I can turn on, so this is somewhat disheartening :-(
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux volition 2.4.18volition #1 Thu Mar 28 20:13:24 PST 2002 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages gcc-3.0 depends on:
ii binutils 2.12.90.0.1-1 The GNU assembler, linker and bina
ii cpp-3.01:3.0.4-6 The GNU C preprocessor.
ii gcc-3.0-base 1:3.0.4-6 The GNU Compiler Collection (base
ii libc6 2.2.5-3 GNU C Library: Shared libraries an
ii libgcc11:3.0.4-6 GCC support library.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#141015: gcc-3.0: Superfluous warning when -std=c99/gnu99 and noreturn on main()
Package: gcc-3.0
Version: 1:3.0.4-6
Severity: normal
The following program generates a superfluous warning when compiled
with -std=c99 or -std=gnu99.
#include
int main (void) __attribute__ ((noreturn));
int main (void)
{
exit(1);
}
volition:~/tmp$ gcc-3.0 -std=c99 -c test.c
test.c: In function `main':
test.c:6: warning: function declared `noreturn' has a `return' statement
volition:~/tmp$
Obviously, this warning is bogus since there is no return statement
anywhere in the program :> The warning is not produced by gcc 2.95.4
nor in the default -std=gnu89 mode.
Although this example is trivial, I encountered the bug in an actual
program that depends on -std=gnu99 (since C99 features are used). In
the program, main() starts an event loop which never directly returns;
the program exits by calling exit().
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux volition 2.4.18volition #1 Thu Mar 28 20:13:24 PST 2002 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages gcc-3.0 depends on:
ii binutils 2.12.90.0.1-1 The GNU assembler, linker and bina
ii cpp-3.01:3.0.4-6 The GNU C preprocessor.
ii gcc-3.0-base 1:3.0.4-6 The GNU Compiler Collection (base
ii libc6 2.2.5-3 GNU C Library: Shared libraries an
ii libgcc11:3.0.4-6 GCC support library.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
