Xref: utzoo comp.lang.c:19033 comp.unix.questions:13928
Path: utzoo!attcan!lsuc!ecicrl!clewis
From: clewis@ecicrl.UUCP (Chris Lewis)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: sccs troubles
Keywords: ndir sccs access errors
Message-ID: <235@ecicrl.UUCP>
Date: 30 May 89 02:05:41 GMT
References: <784@jonlab.UUCP>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Followup-To: comp.lang.c
Organization: Elegant Communications Inc. (Ferret Division)
Lines: 38

In article <784@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
>I've recently begun using the BSD program called sccs, to interface
>to the sccs system.  I've run into a defect using the "info" command
>that requests which files are currently open for editing.  "sccs" always
>reports "Nothing being edited"!

>I've tracked the problem down to the fact that sccs is reading the wrong
>directory.  It is using the current directory rather than the designated
>SCCS directory.  Here is the situation:

[Further stuff on the bug.]

This may or not be your problem depending on how "sccs" is written, but 
there is a bug (feature?!) in the version of ndir distributed with B-news.
It will *not* work recursively.  If you nest opendir (ye olde recursive
directory scan algorithm), subsequent readdir's can be somewhat confusing.
The reason is that, while "opendir" does malloc and return a new structure
on each invocation, there is no attempt to malloc a new area for
readdir to return - there's precisely one statically allocated buffer.
So:
	dirp1 = opendir("foo");
	dirp2 = opendir("foo2");

	d1 = readdir(dirp1);
	d2 = readdir(dirp2);

The d1 and d2 pointers point at the same place....

I have a version of ndir that has *this* particular bug fixed in the unlikely 
event that anybody needs it.  I didn't bother retrofitting the fix into
News because it doesn't matter to news - I was using these routines for
another program...

-- 
Chris Lewis, Markham, Ontario, Canada
{uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis
Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request
(or lsuc!gate!eci386!clewis or lsuc!clewis)