From: Edevaldo Pereira da Silva Junior <Edevaldo DOT Pereira AT motorola DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: TCL Port to DJGPP - Bug + Advices.
Date: Wed, 28 Jul 1999 09:34:47 -0300
Organization: Motorola - Semiconductor Producrs Sector
Lines: 60
Message-ID: <379EF8E7.98BB0896@motorola.com>
NNTP-Posting-Host: caiapo.jag.br.mot.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.07 [en] (X11; I; SunOS 5.5.1 sun4u)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hi Eli!

	As you already know, I could manage to configure and make TCL from the
unix sources. With a lot of help from you, of course. TCL sources have a
testsuit that I'm using to check the port. Some interpreter functions
are still failing and I'm working to solve these problems.

	One of these problems regards the sscanf implementation. In fact I
believe it's a bug, what I do not know is if it is a already known one.
I'm working with DJGPP 2.02 and the code below shows the problem:

#include <stdio.h>

void main( void)
{
 int a,b,c,d,e;
 char *teste="12345670 1234567890ab cdefg";


 e=sscanf(teste,"%o %o %x %lx",&a,&b,&c,&d);
 printf("\n%d %d %d %d %d\n",a,b,c,d,e);
};

	The problem is that sscanf is recognizing 8 & 9 as octal chars and is
returning garbage in b & c variables. I did not test the scanf & fscanf
(exists?) derivatives. As they may share the same implementation they
might also have bugs.

	But there are other problems ;) ...


	TCL sources make heavy use of the pipe function (unistd.h). I believe
this function creates a pipe and returns two file descriptors, one for
writing and another for reading from the pipe. In djgpp this always
fail.
	I'm not used to unix pipes and this kind of thing. Dos anybody knows if
there is a way to emulate this kind of functionality? This is a
particularly bad problem because it prevents many important functions
from working. Most of these functions relate to calling programs from
TCL and file handling.


	One of the testsuit programs make recursive calls to itself until it
fails. As far as I know it will generate a stack overflow. In other
platforms is fails nicely and gives a message about too many nested
calls but in DJGPP is crashes and the computer reboots under win95. Is
there a way to catch stack overflows in DJGPP? Is there a way to see the
current stack size and test if it is about to overflow?


	The last for today... TCL documentation comes in manpages and DJGPP
uses textinfo as a standard. I believe that this two formats are result
of two very different concepts. Is there a way to convert the manpages
to info format? I was thinking about generating a info page that would
address all the converted manpages.

	Thanks in advance,


						Edevaldo