Re: 64-bit safe environment -- sorry, meant to cc all, not be private

[Michael Eager <eager at eagercon dot com>]

Again, jargon is not appropriate. Whether you call it a "64-bit safe
environment" or a "64-bit safe description", whatever is meant by "safe"
is both unclear and unnecessary.

If we adopt your proposal to support Dwarf 2 files which are larger than 
4Gb, and I'm not convinced that it is necessary, then we will craft text
to describe the contents of the Dwarf file.  Nothing will be "safe" or
"unsafe", it will just be as described.

With regard to your comment that you had agreement from Dave to adopt
your proposal, please understand that no matter how much respect we have
for his opinion, I'm sure that he will agree that his is only one opinion.
Neither his agreement nor your belief that there were no adverse comments
(which is, as I might point out, not accurate) is justification for
assuming that the entire committee will adopt your proposal.  We will discuss 
your proposal and come to a conclusion about whether to adopt, modify or
reject the proposal in just the same way we have with every other proposal.

Again, please do not update the draft with proposals which have not
been approved.  It's absolutely inappropriate to have "placeholders" in
the draft for proposals which have neither received discussion nor 
approval.  If you want to list the places which are "impacted" by your 
proposal, list them in the proposal, not in the draft document.

When editing the draft document, it needs to conform to the committee's 
decisions, not your personal desires.  This requires a modicum of discipline.
Yes, I do feel that your incorporating your proposal before it was approved 
by the committee was playing "fast and loose" as you describe it.  We don't 
work on the basis that by editing the document you get to put in your proposals 
and then the committee needs to act to remove them.  

Please remove any unapproved material and send me an update.  Or send me
the original file and I will edit it as needed.



Ron 603-884-2088 wrote:
> 
> From:   SMTP%"brender@gemevn.zko.dec.com" 12-APR-2000 14:58:44.26
> To:     SMTP%"eager@eagercon.com"
> CC:     BRENDER
> Subj:   Re: 64-bit safe environment
> 
> >Ron 603-884-2088 wrote:
> >>
> >>         "In a 64-bit safe environment, this field is an 8-byte unsigned
> >>         offset."
> >
> >I saw this terminology in the draft and I have no idea what it means.
> >What is a "64-bit safe environment"?  What does being safe mean?
> >(I thought that all of Dwarf2 was safe, or at least, not dangerous.)
> 
> The definition of a "64-bit safe DWARF description" is intended to be
> provided in Section 7.4, as proposed by 000331.1. There is a placeholder
> there in the current draft1.
> 
> >Why are we talking about environments?  (There is no mention of environments
> >in the Dwarf2 standard.)  What is an environment in the context of a standard
> >debugging format?  Certainly Dwarf2 can be interpreted in whatever environment
> >one chooses.  And why should we care?
> 
> It would help if I quoted myself accurately. The actual phrasiology is
> 
>         "In a 64-bit safe DWARF description, this field..."
> 
> So the word "environment" never occurs, so your concerns about its meaning
> are unfounded.
> 
> >Proposal 991102.1, which has been adopted, describes modifications to
> >support 64-bit architectures.
> 
> Yes, sorta. But as you observed during the multiple exchanges between
> Dave Anderson and myself, that description was from far from clear in calling
> out all of the implications of its few well chosen words.
> 
> Actually, DWARF2 already has everything needed to "support 64-bit
> architectures", as was noted in some of the discussion leading up to 991102.1.
> What 991102.1 does is provide an alternative DWARF representation that can
> "support" DWARF *descriptions* in which there are one or more sections whose
> size exceeds 2**32 bytes. Since DWARF2 does does not allow such a description
> which can conceivably be required, it is not completely "safe" for use on
> 64-bit architectures.
> 
> >Proposal 000331.1, which has NOT been adopted, uses this terminology.
> >Proposals which have not been adopted should not be incorporated
> >into the draft.
> 
> I plead a bit guilty on this count, but I don't feel all that guilty. First,
> I think it critical that we all understand all of the places that are impacted
> by 991102.1 -- I sure didn't. So I did stray a tad ahead of the formal
> consideration of 000331.1. Second, if after formal consideration the 000331.1
> wording is abandoned or changed, I will happily bring the subsequent draft
> into conformance. Third, this is still a "working" document -- not an end-
> point which, if we all dropped dead this evening, could be adopted by the
> world as is as a done deal. Finally, I already had explicit agreement from
> Dave to adopt 000331.1 (3 Apr version) and no contrary thoughts from anyone
> else, so I did not feel like I was acting fast and loose with the document.
> 
> >I hope that this is just some local (or IA64) jargon.  I do not see that
> >there is a concept here that needs to be incorporated in the Dwarf standard.
> >Whatever value it may have in the discussion of proposal 000331.1, material
> >from an unapproved proposal shouldn't be in the draft.
> 
> No, it has nothing to do with IA64 or any local jargon. And it is not part
> of the discussion of 000331.1, it is part of the proposal proper; that is,
> it is a proposed technical phrase for DWARF itself if you will. I have no
> special attachment to that phrase and am certainly open to alternatives to
> consider as part of the discussion of 000331.1.
> 
> Ron
> ================== RFC 822 Headers ==================
> Date: Wed, 12 Apr 2000 13:28:36 -0400
> Message-Id: <00041213283669@gemevn.zko.dec.com>
> From: brender@gemevn.zko.dec.com (Ron 603-884-2088)
> To: eager@eagercon.com, BRENDER@gemevn.zko.dec.com
> Subject: Re: 64-bit safe environment
> X-VMS-To: SMTP%"eager@eagercon.com"
> X-VMS-Cc: BRENDER


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077