lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] ihs_proddata.cpp assert


From: Greg Chicares
Subject: Re: [lmi] ihs_proddata.cpp assert
Date: Tue, 28 Mar 2006 15:06:39 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2006-3-28 9:38 UTC, Evgeniy Tarassov wrote:
>
> I've noticed that (ihs_proddata.cpp) TProductData::Init method
> enforces a leaf-only filenames while other classes don't, and then it
> adds default data directory path to the filename. As a consequence
> .pol could be read only from that default data directory. I guess it
> wasn't intentional. Is it correct?

I guess it's not trivial to decide. IIRC, the legacy product
editor could handle product files in any directory. Its code added
the default directory path to the filename, or not, depending on
the value of a boolean argument, whose name suggests a meaning that
can't really reflect its behavior. This is code that I ported in a
great hurry; perhaps I analyzed how that argument was used when
the legacy code actually called it, but such analysis, if I indeed
performed it at all, may have been incorrect, or it may have been
limited to the legacy sources without the product-editor code.

IOW, haste makes waste. I'm trying to clean all this stuff up, one
module at a time. This module's time hasn't come, yet.

Now we have code in production with an assertion that may be
unnecessary, or may not. It may be necessary only for some code
you've never seen (which generates '.pol' files), or, again, it
may not. It may break regression tests that you can't run, or
maybe not. Only careful analysis can tell, and we have to do that
analysis in our office. We can't do that right now, so I think
it's best to leave the production system as it is and commit this
change on the product-editor branch, if that's feasible.

If doing that doesn't make sense, then it's probably okay not to
do it for now. If users can edit files that aren't in the default
directory, then we should probably also permit them to use those
files. Today, I think they can't.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]