Re: [PATCH 2/3] Look for include files in the directory of the including file.

On Sun, Jan 06, 2008 at 04:52:52PM -0600, Scott Wood wrote:

On Fri, Jan 04, 2008 at 03:27:39PM +1100, David Gibson wrote:

quoted

quoted

+	newfile = dtc_open_file(filename, searchptr);
+	if (!newfile) {
+		yyerrorf("Couldn't open \"%s\": %s",
+		         filename, strerror(errno));
+		exit(1);

Use die() here, that's what it's for.

die() doesn't print file and line information.

quoted

quoted

+	while (search) {
+		if (dtc_open_one(file, search->dir, fname))
+			return file;

Don't we need a different case here somewhere for if someone specifies
an include file as an absolute path?  Have I missed something?

Yeah, I forgot about that, and sent another patch to fix it when I
noticed (jdl had already pulled, so I didn't send an amended patch).

quoted

[snip]

quoted

+struct search_path {
+	const char *dir; /* NULL for current directory */
+	struct search_path *prev, *next;
+};

I wouldn't suggest a doubly linked list here.  Or at least not without
converting our many existing singly linked lists at the same time.

The doubly-linked list is intended to make it easier to construct search
path lists one-at-a-time from arguments in the proper order, without
needing to reverse the list at the end.

We've already got that problem with a bunch of the lists we create
during parsing (we have several ugly add-to-end-of-singly-linked-list
functions).  Going to doubly-linked lists might not be a bad idea, but
we should do it across the board, probably using the kernel's list.h
or something like it.

-- 
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