Date:	Mon, 24 May 1999 11:53:46 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Markus F.X.J. Oberhumer" <markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: putpath.c test results
In-Reply-To:	<XFMail.990520212540.markus.oberhumer@jk.uni-linz.ac.at>
Message-ID:	<Pine.SUN.3.91.990524114859.14456E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 20 May 1999, Markus F.X.J. Oberhumer wrote:

> While experimeting with the new putpath I've added a test
> section to it - maybe this could go into the djtst CVS
> directory.

I will try to do it, thanks.

> The things that are somewhat surprising are the inconsitent
> handling of / vs. \, case sometimes matters, and multiple
> or trailing slashes sometimes survive.

This is known.  Originally, the "/dev/foo" feature was meant to
support Unix-style devices only.  But since we moved away from that in
v2.01, it probably should treat both styles of slashes equally.

I would like to postpone this change to v2.04, though.

> Otherwise it works fine so far. BTW, it crashes with
> recursive definitions.

Thanks, I now made the change below to prevent that.  If you have any
comments about it, please tell them.

*** putpath.c~4	Sun May 23 18:49:26 1999
--- putpath.c	Sun May 23 19:19:14 1999
***************
*** 10,15 ****
--- 10,25 ----
  
  static const char env_delim = '~';
  
+ /* Can't use stackavail, since it pollutes the namespace...  */
+ static int __inline__
+ enough_stack_p(void)
+ {
+   extern unsigned __djgpp_stack_limit;
+   unsigned sp;
+   __asm__ __volatile__ ("movl %%esp,%k0\n" : "=r" (sp) : );
+   return (int) (sp - __djgpp_stack_limit) > 4*1024;
+ }
+ 
  int
  _put_path(const char *path)
  {
***************
*** 76,81 ****
--- 86,101 ----
          /* The value of the env var can include special constructs
             like /dev/x/foo or even a reference to another env var, so
             we need to recursively invoke ourselves.  */
+ 	if (!enough_stack_p())
+ 	{
+ 	  /* This is probably a case of infinite recursion caused by
+ 	     a self-referencing /dev/env/foo value, in which case
+ 	     ENAMETOOLONG is probably right.  But it could also happen
+ 	     if they were short on stack to begin with, in which case
+ 	     we would lie if we use ENAMETOOLONG.  So:  */
+ 	  errno = ENOMEM;
+ 	  return offset;
+ 	}
          new_offset = _put_path2(var_value, offset);
          space -= new_offset - offset;
          o += new_offset - offset;
***************
*** 99,104 ****
--- 119,129 ----
          {
            *d = '\0';
            /* The default value may use special constructs as well.  */
+ 	  if (!enough_stack_p())	/* infinite recursion? */
+ 	  {
+ 	    errno = ENOMEM;
+ 	    return offset;
+ 	  }
            new_offset = _put_path2(var_name, offset);
            space -= new_offset - offset;
            o += new_offset - offset;

- Raw text -