public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: chrubis@suse.cz
To: Mats Liljegren <mats.liljegren@enea.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH 1/2] SAFE_POPEN: Added function to safe_stdio.h
Date: Tue, 13 May 2014 14:02:36 +0200	[thread overview]
Message-ID: <20140513120236.GC12144@rei> (raw)
In-Reply-To: <20140512175927.62b098ce@mats-desktop>

Hi!
> > > > I've added missing return stream; here and pushed both patches,
> > > > thanks.
> > > 
> > > Whoa, did I really miss that? Wondering how my test could have
> > > run... Must have used the wrong version of the code when testing or
> > > something.
> > 
> > I've seen cases where such code was running fine because the register
> > used to return function value was the same that was allocated for the
> > temporary variable...
> 
> I thought about that alternative but discarded it as too unlikely, but
> apparently, I shouldn't have been so quick about it apparently...
> 
> > > Now you know why I really liked forcing people into using
> > > -Werror ;-) Could it be a good idea to actually use -Werror by
> > > default, and having a "production" flag for those who don't want
> > > it? Just to ensure that lazy people are those being best looked
> > > after...
> > 
> > I would be for reversing the logic, i.e. adding developer flag that
> > enables -Werror. Unfortunatelly LTP has tons of legacy code that
> > produces megatons of warnings and fixing all of these would be a big
> > effort.
> > 
> 
> Hmm, but a compromise could be this:
> 
> Let's say we have a "production flag" which then each module could make
> their mind up whether it should have any effect or not. If it should
> have an effect, then the effect should be to disable -Werror.

I'm still not convinced that enabling -Werror by default is a good idea.
Compiler warnings are quite unstable among different versions and code
that produces no warnings with one version is not guaranteed not to
produce anything with another, and there are false positives too.

Cloning LTP from git, running configure and make must not fail just
because you have different compiler version than developers.

> This way, you can fix warnings on one module at a time, no big bang
> change. When a module is fixed, you change it to use -Werror unless
> this "production flag" is used.

That sounds to me as too much work for not so much gain.

I guess that we can add a configure parameter that adds a variable into
config.mk something as WERROR which gets set to -Werror only if it's
supported by compiler and enabled by user. Then we can do
CFLAGS+=$(WERROR) in a few Makefiles.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  parent reply	other threads:[~2014-05-13 12:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 14:48 [LTP] [PATCH 0/2] safe_stdio: Added SAFE_POPEN() + new error message format Mats Liljegren
2014-05-12 14:48 ` [LTP] [PATCH 1/2] SAFE_POPEN: Added function to safe_stdio.h Mats Liljegren
2014-05-12 15:03   ` chrubis
     [not found]     ` <20140512171433.0ce9f681@mats-desktop>
2014-05-12 15:34       ` chrubis
     [not found]         ` <20140512175927.62b098ce@mats-desktop>
2014-05-13 12:02           ` chrubis [this message]
2014-05-12 14:48 ` [LTP] [PATCH 2/2] safe_stdio: Error messages in new format Mats Liljegren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140513120236.GC12144@rei \
    --to=chrubis@suse.cz \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=mats.liljegren@enea.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox