This is the mail archive of the
mailing list for the Cygwin project.
Re: I think I've GOT IT! The "Cannot open (null) for reading"bug!!!
----- Original Message -----
From: "Max Bowsher" <maxb at ukf dot net>
To: "Robert Collins" <rbcollins at cygwin dot com>
Cc: <cygwin-apps at cygwin dot com>
Sent: Sunday, March 09, 2003 10:08 AM
Subject: Re: I think I've GOT IT! The "Cannot open (null) for
> Robert Collins wrote:
> > On Sun, 2003-03-09 at 07:41, Max Bowsher wrote:
> >> I traced it to this curious condition:
> >> pkg.desired.sourcePackage() == false &&
> >> pkg.desired.sourcePackage().picked() == true
> >> How? Well, it turns out that the defaultversion placeholder object
> >> used, amongst other circumstances, when a package is has no source
> >> package, is returning *true* to picked()!
> >> Robert, how do you think this should be fixed?
> > Offhand, without referencing the source - make the defaultversion
> > return false to picked().
> Not that simple, unfortunately.
> defaultversion is a _defaultversion, which derives from
> In this, picked is a member variable.
default version is whats known as a NULL instance - it gives you
something to operate on, that never does anything, to remove the need
for if (foo != NULL) foo->blarg();
_packageversion is the parent for different types of package versions -
i.e. cygwin package versions, rpm package versions, dpkg package
versions. So it had core functionality that is not related to package
> So _defaultversion has no control over what the wrapping
> with its data members.
Well, it does actually :}. Thats what accessors and mutators are for, as
opposed to direct member access. I've tweaked packageversion to use a
mutator function, and overriden it in defaultversion. You can equally
trip an Exception in _defaultversion::pick(bool) if you want to find
where it was being set. I'll be interested to know if this solves the
problem ( I presume you've managed to create a test case ).
> Have I successfully conveyed the confusing complexity of this code?
Nope :]. I'll accept refactoring-for-clarity patches, if they are fairly
small. Large refactorings I'd like to see chopped up. Refactorings as
part of a patch follow the same guidelines :}.
Why? As we don't have a comprehensive test-suite, I need to be able to