This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] cygcheck: follow symbolic links


On Thu, 23 Feb 2006, Corinna Vinschen wrote:

> On Feb 22 13:55, Igor Peshansky wrote:
> > On Fri, 17 Feb 2006, Igor Peshansky wrote:
> > > On Fri, 17 Feb 2006, Corinna Vinschen wrote:
> > > > On Feb 16 12:26, Igor Peshansky wrote:
> > > > > On Thu, 16 Feb 2006, Corinna Vinschen wrote:
> > > > > > - Most of your patch should go into path.cc so it can be reused,
> > > > > >   for instance in strace.
> > > > >
> > > > > Agreed -- that's why I put that TODO in there. :-)  Should I move it
> > > > > in the next iteration of the patch?
> > > >
> > > > Please move it now.  I don't think it's non-trivial enough to justify
> > > > multiple iterations.
> > >
> > > Whoops.  Misspoke.  I meant "incarnation".  Never mind, I'll just do it.
> > > :-)  Expect a new patch today.
> >
> > I guess "today" is a stretchable concept. :-)  In any case, here's a
> > new patch.  Moving things into path.cc turned out to be indeed
> > non-trivial, since the new functionality was using static functions in
> > cygcheck.cc which now needed to be moved out into a separate file.  I
> > don't expect this to be applied right away (hence no ChangeLog), but
> > is this along the lines of what you were expecting?
>
> Yes, this looks generally ok to me.  I didn't *test* your patch, but
> from the look of it, it seems fine, with one exception:
>
> I don't see a reason to introduce a new fileutil.cc file.  Please move
> the functions into path.cc, add the extern declarations to path.h (so
> you can drop them from cygcheck.cc), and revert the Makefile changes.
> Then, together with a neat ChangeLog entry, we're pratically done :-)

The problem is that most of the functions don't belong in path.cc (e.g.,
display_error).  To do this properly, they will have to be rewritten in a
more general manner, to return the appropriate error code so that the
failure condition can be identified, and display_error should move back to
cygcheck.cc (in particular, display_error prints "cygcheck" as part of the
error).  That's why I chose to add all the functions to cygcheck first --
they are just not yet ready for consumption by other programs.

Sigh.  I'd really like this to get in by 1.5.20, but time is limited, so
that may not happen.  I'll see what I can do to separate the general and
the specific, and split this functionality between cygcheck.cc and
path.cc.

> Thanks for doing this, btw.  I really appreciate it.

Hey, I promised to look into it... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]