On Thu, Mar 22, 2007 at 04:08:36PM -0700, Stephen Fisher wrote:
On Wed, Mar 21, 2007 at 05:46:50PM -0700, Stephen Fisher wrote:
I've found a way around this issue and have introduced it into the
same places in my tree on Unix as Ulf has on Windows so far. It's a
variable setup by
On Wed, Mar 21, 2007 at 05:46:50PM -0700, Stephen Fisher wrote:
I've found a way around this issue and have introduced it into the
same places in my tree on Unix as Ulf has on Windows so far. It's a
variable setup by the configure script that is tested in each
directory's Makefile.am.
On Tue, Mar 20, 2007 at 11:09:40PM -0700, Stephen Fisher wrote:
Thanks. I introduced -Werror into the configure.in file in wiretap/
locally to follow Ulf's lead on the Win32 side and it broke the glib
test program. The glib test program compiles with warnings (turned
errors)! Something
On Wed, Mar 21, 2007 at 08:29:45AM +0100, Joerg Mayer wrote:
On Tue, Mar 20, 2007 at 11:09:40PM -0700, Stephen Fisher wrote:
Thanks. I introduced -Werror into the configure.in file in wiretap/
locally to follow Ulf's lead on the Win32 side and it broke the glib
test program. The glib
Joerg Mayer wrote:
No, it won't work. I've spent many many hours in the past to get rid of
compiler warnings and it just won't work. While we definitely should try
to get rid of some warnings, fixing warnings on one platform may introduce
warnings on other platforms (or even gcc versions).
Jeff Morriss wrote:
In fact I meant it just as a stop-gap until someone (smarter--or at
least with more than to dedicate to the purpose--than me) can fix
Wireshark's unsigned-vs-signed char problem.
As it is, I have to scroll through hundreds of (probably not fixable by
me) warnings just
Ulf Lamping wrote:
I just meant that in the long run just ignoring a long list of warnings
is probably not a good idea ...
However, disabling the signed warning, fix the rest and setting the
stop on error barrier would still be a lot better than what we
currently have ...
I heartily
Currently, you don't tend to even notice new warnings that you introduce
on your own platform, as they get lost in the general compilation noise.
Part of the problem (when working from the command-line at least) is
how much output is generated, and how far you'd need to scroll back to
see the
Getting rid of warnings should not be confused with getting rid of the
*reasons* for those warnings.
--
Mark H. Wood, Lead System Programmer [EMAIL PROTECTED]
Typically when a software vendor says that a product is intuitive he
means the exact opposite.
pgpomulJckxPF.pgp
Description: PGP
Inline comments...
On 3/20/07, Martin Mathieson [EMAIL PROTECTED] wrote:
Currently, you don't tend to even notice new warnings that you introduce
on your own platform, as they get lost in the general compilation noise.
Part of the problem (when working from the command-line at least) is
On Tue, Mar 20, 2007 at 03:04:49AM +0100, Ulf Lamping wrote:
In my experience having a compiler warning free code is a good way to
prevent very subtle bugs and would also be a good addition to the
programs security - and BTW more pleasant to work with ;-)
Indeed.
So here comes the
On Tue, Mar 20, 2007 at 01:01:20PM -0700, Stephen Fisher wrote:
As usual, this is my Win32 point of view. I'm pretty sure the
above is possible to do for the Win32 platform. I'm not sure if it's
possible with the automake foo for the different unix/linux platform
builds ...
With
On Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote:
Part of the problem (when working from the command-line at least) is
how much output is generated, and how far you'd need to scroll back to
see the compilation of the file you've just changed.
Yup. I edit source files and
On 3/21/07, Stephen Fisher [EMAIL PROTECTED] wrote:
On Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote:
Yup. I edit source files and compile in the Emacs GUI. It makes it
easy to spot warnings errors during the compliation process (Control-X
` takes you to the next warning or
On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote:
How do you mean? Emacs is the only true editor!
No, it's not:
http://www.gnu.org/fun/jokes/ed.msg.html
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
On Mar 20, 2007, at 1:08 PM, Stephen Fisher wrote:
Of course, this assumes that all the C compilers we use accept -
Werror.
I doubt that they do (and they definitely don't, if by we you mean
everybody who compiles Wireshark - it's been compiled with Sun C,
HP's ANSI C compiler for HP-UX,
On 3/21/07, Guy Harris [EMAIL PROTECTED] wrote:
On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote:
How do you mean? Emacs is the only true editor!
No, it's not:
http://www.gnu.org/fun/jokes/ed.msg.html
There *must* be an ed mode for emacs. so the point is that...
After some
Joerg Mayer wrote:
No, it won't work. I've spent many many hours in the past to get rid of
compiler warnings and it just won't work. While we definitely should try
to get rid of some warnings, fixing warnings on one platform may introduce
warnings on other platforms (or even gcc versions).
On Mar 19, 2007, at 7:04 PM, Ulf Lamping wrote:
In my experience having a compiler warning free code is a good way to
prevent very subtle bugs and would also be a good addition to the
programs security - and BTW more pleasant to work with ;-)
You will often hear the following excuse on this
Luis Ontanon wrote:
the point is what kind of warnings can be cleaned up:
Well, do you mean cannot be cleanup up or I'm too lazy to clean them
up ;-)
to fix pointer arguments differ in signedness for example would be
a waste of time, as they are caused by guint8* used instaed of gchar*
I agree with Ulf. Warnings should not appear (at least most of them)
when compiling wireshark.
For the case differ in signedness case, you can use (guchar*). But as
it was already discussed with Guy, wireshark needs a library to handle
strings accurately. One starting point could simply be
Luis Ontanon wrote:
the point is what kind of warnings can be cleaned up:
to fix pointer arguments differ in signedness for example would be
a waste of time, as they are caused by guint8* used instaed of gchar*
on those systems (most) that treat char as an unsigned.
Actually GCC already
Guy Harris wrote:
The main reason for warnings you can't eliminate, I suspect, are
crufty vendor #include headers. At least some versions of Solaris
have, as I remember, crappy old X11 headers that don't have function
prototypes by default, hence the hack to turn them on in
Jeff Morriss wrote:
Actually GCC already has a way to avoid this: -Wno-pointer-sign.
Apparently:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00505.html
someone didn't like the fact that Linux had a few thousand such warnings
when compiled with GCC 4.
We could add that and probably cut
Ulf Lamping wrote:
Jeff Morriss wrote:
Actually GCC already has a way to avoid this: -Wno-pointer-sign.
Apparently:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00505.html
someone didn't like the fact that Linux had a few thousand such warnings
when compiled with GCC 4.
We could add
25 matches
Mail list logo
