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.unix.questions
mailing list