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 se
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.a
On Tue, Mar 20, 2007 at 11:09:40PM -0700, Stephen Fisher wrote:
> On Tue, Mar 20, 2007 at 05:57:12PM -0700, Guy Harris wrote:
>
> > Or do it in the config file - look for "-W" in the top-level
> > configure.in and the Wiretap configure.in.
>
> Thanks. I introduced -Werror into the configure.in
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 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 g
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)! Somethin
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 Tue, Mar 20, 2007 at 05:57:12PM -0700, Guy Harris wrote:
> Or do it in the config file - look for "-W" in the top-level
> configure.in and the Wiretap configure.in.
Thanks. I introduced -Werror into the configure.in file in wiretap/
locally to follow Ulf's lead on the Win32 side and it brok
I'm quite surprised of what you're saying. I don't know what exact
platforms you've tested and which compilers. But I'm working on a
simulator and a library of generic data structures which are more than
70.000 lines of code compiling without any warning since gcc-2.95 until
gcc-4.1.2 and for seve
On Tue, Mar 20, 2007 at 01:01:20PM -0700, Stephen Fisher wrote:
> > So here comes the buildbot into the scene. If we would use a compiler
> > option like "stop on warnings" (or "treat warnings as errors" or
> > alike), it would become at least much more obvious if new warnings
> > were added - t
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...
Aft
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 H
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
http://www.wireshark.org/
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 war
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 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 ...
>
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 buil
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)
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 s
> 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 th
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 heart
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
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
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 pr
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 configure
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 al
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 wrap
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
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
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.
But in order to follow that policy you'll have
Hi List!
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 topic: "but you cannot
write code which w
31 matches
Mail list logo
