[PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[Scott Wood]

Also, free file->dir when freeing file.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
 srcpos.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/srcpos.c b/srcpos.c
index 7340c33..7a0c47e 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -86,6 +86,16 @@ struct dtc_file *dtc_open_file(const char *fname,
 		return file;
 	}
 
+	if (fname[0] == '/') {
+		file->file = fopen(fname, "r");
+
+		if (!file->file)
+			goto out;
+
+		file->name = strdup(fname);
+		return file;
+	}
+
 	if (!search)
 		search = &default_search;
 
@@ -100,6 +110,7 @@ struct dtc_file *dtc_open_file(const char *fname,
 	}
 
 out:
+	free((void *)file->dir);
 	free(file);
 	return NULL;
 }
@@ -109,5 +120,6 @@ void dtc_close_file(struct dtc_file *file)
 	if (fclose(file->file))
 		die("Error closing \"%s\": %s\n", file->name, strerror(errno));
 
+	free((void *)file->dir);
 	free(file);
 }
-- 
1.5.3

Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[David Gibson]

On Fri, Jan 04, 2008 at 03:10:45PM -0600, Scott Wood wrote:
> Also, free file->dir when freeing file.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
>  srcpos.c |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/srcpos.c b/srcpos.c
> index 7340c33..7a0c47e 100644
> --- a/srcpos.c
> +++ b/srcpos.c
> @@ -86,6 +86,16 @@ struct dtc_file *dtc_open_file(const char *fname,
>  		return file;
>  	}
>  
> +	if (fname[0] == '/') {
> +		file->file = fopen(fname, "r");
> +
> +		if (!file->file)
> +			goto out;
> +
> +		file->name = strdup(fname);
> +		return file;
> +	}
> +
>  	if (!search)
>  		search = &default_search;
>  
> @@ -100,6 +110,7 @@ struct dtc_file *dtc_open_file(const char *fname,
>  	}
>  
>  out:
> +	free((void *)file->dir);

That cast shouldn't be there.

>  	free(file);
>  	return NULL;
>  }
> @@ -109,5 +120,6 @@ void dtc_close_file(struct dtc_file *file)
>  	if (fclose(file->file))
>  		die("Error closing \"%s\": %s\n", file->name, strerror(errno));
>  
> +	free((void *)file->dir);

Or here.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[Scott Wood]

On Sun, Jan 06, 2008 at 02:37:16PM +1100, David Gibson wrote:
> >  out:
> > +	free((void *)file->dir);
> 
> That cast shouldn't be there.

It generates a constness warning otherwise.  I was on the fence over
whether to just remove the constness (even though the data is never
modified during its lifetime); would that be preferable?

-Scott

Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[Jon Loeliger]

So, like, the other day Scott Wood mumbled:
> Also, free file->dir when freeing file.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>

Applied.

Thanks.

jdl

Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[Jon Loeliger]

So, like, the other day Scott Wood mumbled:
> On Sun, Jan 06, 2008 at 02:37:16PM +1100, David Gibson wrote:
> > >  out:
> > > +	free((void *)file->dir);
> > 
> > That cast shouldn't be there.
> 
> It generates a constness warning otherwise.  I was on the fence over
> whether to just remove the constness (even though the data is never
> modified during its lifetime); would that be preferable?

The earlier patch was applied for functionality reasons.
If needed, a follow-up patch to sort this out is still welcome.

jdl

Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.

[David Gibson]

On Sun, Jan 06, 2008 at 04:46:24PM -0600, Scott Wood wrote:
> On Sun, Jan 06, 2008 at 02:37:16PM +1100, David Gibson wrote:
> > >  out:
> > > +	free((void *)file->dir);
> > 
> > That cast shouldn't be there.
> 
> It generates a constness warning otherwise.  I was on the fence over
> whether to just remove the constness (even though the data is never
> modified during its lifetime); would that be preferable?

I think that is preferable.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson