linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Justin Mitchell <jumitche@redhat.com>
To: Steve Dickson <SteveD@RedHat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 2/7] nfs-utils: Make config includes relative to current config
Date: Thu, 03 May 2018 11:11:31 +0100	[thread overview]
Message-ID: <1525342291.7550.16.camel@redhat.com> (raw)
In-Reply-To: <6f363a98-479a-8d7e-cbd5-bd5d7248f41d@RedHat.com>

On Wed, 2018-05-02 at 14:21 -0400, Steve Dickson wrote:
> Hi Justin,
> 
> Sorry for taking so long to get to this... 
> 
> Most of my comments is about the style you are using.
> 
> I would like to keep the coding style somewhat the same 
> and in a few places that is not just not happening...

Yeah sorry I should have paid more attention to maintaining style,
will fix it all up and repost.

> >  /*
> >   * Parse the line LINE of SZ bytes.  Skip Comments, recognize section
> >   * headers and feed tag-value pairs into our configuration database.
> >   */
> >  static void
> > -conf_parse_line(int trans, char *line, int lineno, char **section, char **subsection)
> > +conf_parse_line(int trans, char *line, const char *filename, int lineno, char **section, char **subsection)
> >  {
> >  	char *val, *ptr;
> >  
> > @@ -366,10 +395,12 @@ conf_parse_line(int trans, char *line, int lineno, char **section, char **subsec
> >  
> >  	if (strcasecmp(line, "include")==0) {
> >  		/* load and parse subordinate config files */
> > -		char * subconf = conf_readfile(val);
> > +		char * relpath = relative_path(filename, val);
> > +		char * subconf = conf_readfile(relpath);
> Same here no space also isn't subconf being over written?
nope, conf_readfile() returns a malloced chunk that gets freed at the
end of the include handler


> > @@ -383,10 +414,11 @@ conf_parse_line(int trans, char *line, int lineno, char **section, char **subsec
> >  				inc_subsection = strdup(*subsection);
> >  		}
> >  
> > -		conf_parse(trans, subconf, &inc_section, &inc_subsection);
> > +		conf_parse(trans, subconf, &inc_section, &inc_subsection, relpath);
> >  
> >  		if (inc_section) free(inc_section);
> >  		if (inc_subsection) free(inc_subsection);
> > +		if (relpath) free(relpath);
> Are these if even needed? Won't these either be NULL or allocated memory?
yes, inc_section and inc_subsection are strdup()ed copies of the current
section titles because conf_parse() will alter them if any new section
headers are encountered, yet we needed to know what section we were in
when we entered this included conf file.

the way it is written will correctly handle recursive includes.

in general all my code changes are avoiding any use of globals and
statics in the hope of eventually making the code base thread-safe and
suitable for use as a public library, so that tends to mean more freeing
of short lived malloced chunks.


  reply	other threads:[~2018-05-03 10:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23 15:19 [PATCH 0/7] nfs-utils: nfsconf cli tool and code tests Justin Mitchell
2018-04-23 15:24 ` [PATCH 1/7] nfs-utils: Fix minor memory leaks Justin Mitchell
2018-04-23 15:25 ` [PATCH 2/7] nfs-utils: Make config includes relative to current config Justin Mitchell
2018-05-02 18:21   ` Steve Dickson
2018-05-03 10:11     ` Justin Mitchell [this message]
2018-04-23 15:26 ` [PATCH 3/7] nfs-utils: Use config file name in error messages Justin Mitchell
2018-04-23 15:26 ` [PATCH 4/7] nfs-utils: Indicate if config file was missing Justin Mitchell
2018-04-23 15:27 ` [PATCH 5/7] nfs-utils: tidy up output of conf_report Justin Mitchell
2018-05-02 18:24   ` Steve Dickson
2018-04-23 15:34 ` [PATCH 6/7] nfs-utils: Add nfsconftool cli Justin Mitchell
2018-05-02 18:25   ` Steve Dickson
2018-04-23 15:35 ` [PATCH 7/7] nfs-utils: use nfsconftool cli to test library function Justin Mitchell

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=1525342291.7550.16.camel@redhat.com \
    --to=jumitche@redhat.com \
    --cc=SteveD@RedHat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).