Re: [lmi] product editor patch

[Greg Chicares]

On 2008-02-10 17:42Z, Greg Chicares wrote:
[...certain function pointers...]
> They reside in 'alert.o'. It looks like we're linking that object
> file in the dll as well as in the app. Then, I guess, the app
> initializes the pointer in its own copy of the object file, and
> the dll tries to report runtime errors by dereferencing the
> pointer in its own copy of the object file.

This defect in the 'product_files' binary was
  [20050612T1658Z, 20080211T0433Z) latent
  [20080211T0433Z, 20080211T0434Z) observable
  [20080211T0434Z,               ) fixed
in HEAD (timestamps truncated to minutes), and can't arise
again in the same way without producing an obvious runtime
error.

> Before moving on, I'd like to consider whether we might have
> similar problems elsewhere, and whether we can turn this into
> a link-time error so that we'll never meet it at run time again.

Perhaps the best we can hope to achieve is an in-your-face
runtime error that reliably occurs with HEAD, whether or not
any customized files not in HEAD are used.

I don't see how to make it a link-time error with ELF;
  http://www.haible.de/bruno/woe32dll.html
with PE, perhaps we could do that by introducing __declspec
decorations; yet, as noted in 'workhorse.make':

# The product_files target doesn't build with shared-library
# 'attributes'. That matters little because that target is deprecated.

We want to get rid of the 'product_files' program. But first we
want to change all product files to xml, so that, instead of
being generated by this program, they can be maintained with a
text editor. But it doesn't make sense to do that until the new
product editor is merged into HEAD.

Yet the product-editor patch strengthens certain consistency
tests, in code shared with the 'product_files' binary, and one
of those stronger tests reveals an issue in some code that's
maintained outside of cvs. We have to resolve that issue before
we can proceed with the product-editor merge.

So it's kind of like upgrading to a new compiler version with
stricter enforcement of language rules, and finding that you
have to fix your code first. Anyway, that's the roadmap, and
that's where we are today...

> But right now I must turn to some high-priority tax stuff that
> might take a few more days.

...and I'm afraid we won't be able to move forward before
Thursday at the earliest.