sccs troubles

Chris Lewis clewis at ecicrl.UUCP
Tue May 30 12:05:41 AEST 1989


In article <784 at jonlab.UUCP> jon at 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)



More information about the Comp.lang.c mailing list