[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Digital UNIX Object File/Symbol Table Notes Conference |
|
| Moderator: | SMURF::LOWELL |
|
| Created: | Mon Nov 25 1996 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 71 |
| Total number of notes: | 314 |
69.0. ".comment section extensions and 'mcs' utility" by AOSG::LOWELL () Wed Apr 16 1997 11:49
<<< SMURF::DISK$NOTES:[NOTES$LIBRARY]UNIX_OBJSYM.NOTE;1 >>>
-< Digital UNIX Object File/Symbol Table Notes Conference >-
================================================================================
Note 18.7 ISSUE 9: Inadequate extensibility 7 of 21
NETRIX::"[email protected]" "Michelle Neisser" 6 lines 31-DEC-1996 13:12
--------------------------------------------------------------------------------
A proposal for comment section extensions is available for review at
http://www.zk3.dec.com/~mn/ofst/cmscn.html
[Posted by WWW Notes gateway]
================================================================================
Note 18.8 ISSUE 9: Inadequate extensibility 8 of 21
GEMGRP::BRENDER "Ron Brender" 378 lines 9-JAN-1997 10:36
-< Old Optimization section proposal -- superceded by 33.3 >-
--------------------------------------------------------------------------------
When we discuss the .comment section proposal, I think it would be worthwhile
to compare and contrast it with the structure proposed for DBGOPT information
using the optimization section. The following paper, written by Jeff Nelson
and myself in conjunction with Greg Lueck, attempts to establish the same
kind of flexibility and extensibility properties desired for the .comment
section -- and uses almost the same implementation model. Since the schemes
are so similar, I would like to see if a single common scheme can serve for
both...
Note: like the .comment proposal, the .opt proposal does not specify the
contents of subsection usage.
Optimization Symbols Section
Jeff Nelson
Ron Brender
8 August 1995
ABSTRACT
This document defines the syntax and semantics of the Third Eye
Symbols section known as the "Optimization Symbols" section. This
section, though it has a definition in /usr/include/sym.h, is
currently unused on the Digital Unix platform.
1 MOTIVATION
The Third Eye symbol table embedded within a COFF object file is
unwieldy and difficult to extend without coordination and cooperation
between lots of consumers and producers. This is further compounded
by two factors: first, not all consumers and producers are
necessarily known. Second, the extensions that a producer or consumer
wants are not necessarily compatible with the needs of any other
producer or consumer.
2 PURPOSE
The definition of the Optimization Symbols section is designed to
solve these problems. It gives individual producers and consumers the
ability to communicate information about any aspect of the object file
in any form they choose. This allows for new or modified
descriptions, while keeping the rest of the symbol table unchanged.
New information can be generated at any time without coordinating
between producers and consumers, though eventually a minimal amount of
coordination is required.
In fact, it is recommended that the information in the Optimization
Symbols section eventually be folded back into the mainstream symbol
description. This is so all producers and consumers can take
advantage of the information which up to now has presumably been
private between one or more producers and consumers.
It is assumed that the information in the Optimization Symbols section
does not contradict or fundamentally violate any understanding of the
object that is given in any other part of the symbol table. In other
words, it is not OK to "lie" in the mainstream symbol description and
tell the "truth" in the Optimization Symbols section. It is OK,
however, to modify or enhance the description of the object file.
This is the intended purpose of the section.
Optimization Symbols Section Page 2
DEFINITION 25 September 1995
3 DEFINITION
The Optimization Symbols section contains one or more instances of an
Optimization Procedure Descriptor. The Optimization Procedure
Descriptor is a data structure which is composed of three parts: a
header, a vector of descriptors that describes the data parts, and
finally the data parts. A diagram of the format of the Optimization
Procedure Descriptor is shown below.
Byte
Offset
+=================================================+
00: | Version | \
+-------------------------------------------------+ Header
04: | N | /
+=================================================+
08: | Kind | \
+-------------------------------------------------+ \
0C: | Offset | \
+-------------------------------------------------+ Descriptor 0
10: | Size | /
+-------------------------------------------------+ /
14: | MBZ | /
+=================================================+
18: | Kind | \
+-------------------------------------------------+ \
1C: | Offset | \
+-------------------------------------------------+ Descriptor 1
20: | Size | /
+-------------------------------------------------+ /
24: | MBZ | /
+=================================================+
:
Optimization Symbols Section Page 3
DEFINITION 25 September 1995
:
+=================================================+
| Kind | \
+-------------------------------------------------+ \
| Offset | \
+-------------------------------------------------+ Descriptor N-1
| Size | /
+-------------------------------------------------+ /
| MBZ | /
+=================================================+ <--Base for
| Data Part 0 | computing
+-------------------------------------------------+ Offset
| Data Part 1 |
+-------------------------------------------------+
:
:
+-------------------------------------------------+
| Data Part N-1 |
+=================================================+
3.1 The Header
The definition of the header, in sym.h, is as follows:
=================start definition===============
typedef struct {
unsigned int version; /* version number */
unsigned int n; /* number of descriptor/data pairs
(zero-based) */
} OptHdr, *pOptHdr;
================= end definition ===============
The initial version number is defined in symconst.h:
=================start definition===============
#define optVersion = 1; /* current version number */
================= end definition ===============
The header version number is for future expansion purposes; if the
Optimization Section ever changes semantically or syntactically, the
version number shall change so that consumers can recognize the
difference.
Optimization Symbols Section Page 4
DEFINITION 25 September 1995
The field n is used to record the number of descriptors (and thus, the
number of data parts) within the remainder of the Optimization
Section.
3.2 The Descriptors
The definition of a descriptor, in sym.h, is as follows:
=================start definition===============
typedef struct {
unsigned int kind; /* Kind of optimization data */
unsigned int size; /* Size of optimization data part */
unsigned int offset; /* Starting offset */
unsigned int reserved; /* For future use. All bits Must Be Zero. */
} OptDesc, *pOptDesc;
================= end definition ===============
The definition of descriptor kinds is in symconst.h:
=================start definition===============
#define okSemPC = 1; /* Optimization Kind: semantic event
PC-line table */
/* Producer: GEM compiler backend */
/* Consumer: DECladebug */
================= end definition ===============
The kind field gives meaning to the data part to which the descriptor
refers. The data for each unique kind is interpreted in exactly the
same way.
The size field gives the size of the data part in bytes. (This is the
actual size and does not include any additional bytes which may be
required for alignment padding.)
The offset field gives the starting position of the data part. The
offset is relative to the start of the first data part. The value in
the offset field must be a multiple of 8; this aligns the data parts
so that they all start on a quadword boundary.
Optimization Symbols Section Page 5
DEFINITION 25 September 1995
The following algorithm serves to compute offsets:
Offset of first data part = 0 // because it's the first
Offset of second data part = Offset of First Data Part +
Size of First Data Part +
Padding to align on a quadword boundary
Offset of third data part = Offset of Second Data Part +
Size of Second Data Part +
Padding to align on a quadword boundary
All padding bytes are required to be zero.
The reserved field serves two purposes: it provides for future needs
by allocating unused bits, and it makes the allocation of the
descriptor structure an even quadword, so that all descriptors are
aligned.
It is expected that there is a natural correlation between descriptors
and the data parts: the first descriptor describes the first data
part, the second descriptor describes the second data part, and so on.
However, this cannot be assumed. In addition, it is illegal to assume
an ordering of the descriptors.
It is legal to have more than one descriptor with the same kind field
value; the kind field is not a unique key.
3.3 The Data Parts
The contents and format of the data parts are arranged by private
agreement between the producers and consumers of the particular kind
of data part.
4 RELATIONSHIP WITH OTHER COFF STRUCTURES
The Optimization Symbols section is organized and indexed in much the
same way as the Locals Symbols section:
- The Optimization Symbols section is a single section within
the COFF file.
- The COFF header (HDRR) contains the starting offset and
maximum index into the Optimization symbols section,
cbOptOffset and ioptMax, respectively. The cbOptOffset value
is the file offset of the first byte in the Optimization
Symbol table. This value must always be aligned on a
Optimization Symbols Section Page 6
RELATIONSHIP WITH OTHER COFF STRUCTURES 25 September 1995
quadword (eight byte) boundary. The ioptMax value is the
count of the total number of bytes in the entire Optimization
Symbols section, including OptHdr's, OptDesc's and padding
bytes. Thus, this value is always a multiple of eight bytes.
- Each File Descriptor (FDR) has a pointer and size
contribution to the Optimization Symbols section, named
ioptBase and copt, respectively. The ioptBase value is the
byte offset from the start of the Optimization Symbols
section to this file's optimization symbols. The copt value
is the total number of bytes in the Optimization Symbols
section which are contributed by this file, including
OptHdr's, OptDesc's and padding bytes. This implies that a
file's contribution to the Optimization Symbols section must
be contiguous, even if the procedures in that file are not.
- Each Procedure Descriptor (PDR) has a pointer to the start of
that procedure's contribution to the Optimization Symbols
section, named iopt. This offset points to the start of a
unique and complete Optimization Procedure Descriptor. Thus,
there is at most one Optimization Procedure Descriptor per
routine. A procedure's Optimization Procedure Descriptor can
be found using this formula:
HDRR.cbOptOffset + FDR.ioptBase + PDR.iopt
5 PROCESSING
Tools which produce COFF object files must produce either an empty
Optimization Symbols section or a valid Optimization Symbols section.
An image with no Optimization Symbols section has HDRR.cbOptOffset and
HDRR.ioptMax values of zero. A file with no contribution to an
Optimization Symbols section has a FDR.copt value of zero. A routine
with no contribution to the Optimization Symbols section has a
PDR.iopt value of zero.
Tools which consume COFF object files must be capable of skipping the
entire Optimization Symbols section, or those parts of it which it
does not understand.
Tools which both read and write COFF object files must consume a valid
Optimization Symbols section (if one exists in an input file) and
produce an equivalent, valid Optimization Symbols section in its
output file. This means one of the following:
- The tool does not know how to process anything in the
Optimization Symbols section. The tool must write an exact
copy of any Optimization Symbols section it reads in. In
other words, it must allow the Optimization Symbols section
to pass through unchanged.
Optimization Symbols Section Page 7
PROCESSING 25 September 1995
- The tool recognizes some kinds of data parts. This tool must
copy, unchanged, the data parts (and descriptors) that it
does not understand. The tool must read (and if necessary,
transform) the data parts (and descriptors) that it does
understand and write the equivalent data parts (and
descriptors).
6 COORDINATION
It is the responsibility of every producer to obtain a unique kind
value for each distinct kind of data it wishes to place in the
Optimization Symbols section. Obtaining a unique kind value ensures
that there won't be two producers using the same kind value to mean
different things. Obtaining a unique kind value is accomplished by
adding a new constant definition to the include file (currently
/usr/include/symconst.h) which defines the format of the Optimization
Symbols section.
This document registers one unique kind value: okSemPC, for semantic
event PC-line correlation data.
Information in the Optimization Symbols section, though arranged by
private agreement between producers and consumers, is meant to be
shared among all consumers and producers when it makes sense to do so.
Producers and consumers are jointly responsible for ensuring that the
data parts they write and read, respectively, are also recognized and
processed by other tools if those tools could have an impact on the
information in the data part. For example, if a compiler generates a
different kind of PC-line correlation table which is used by a
debugger, and an instruction-modifying tool makes changes (insertions
and deletions) to the instruction stream, the compiler and debugger
should both lobby the modifying tool to keep the different PC-line
correlation table up to date.
================================================================================
Note 18.9 ISSUE 9: Inadequate extensibility 9 of 21
NETRIX::"[email protected]" "Michelle" 81 lines 14-JAN-1997 17:35
-< meeting followup (or: a dangerous brainstorm!) >-
--------------------------------------------------------------------------------
Randy and I have been brainstorming on how to handle some of the
issues brought up in yesterday's meeting concerning comment section
extensions. Randy's idea was to try and handle some of the
complexities and semantics without changing the basic structure
of the section. This approach is an alternative to segmenting the
tag range beyond the system/user split. Recall that the main problem is
how to process subsections whose tag values are not recognized by a consumer.
The idea is to introduce two new tag types, CM_TAGDESC and CM_TOOLINFO.
The first will serve to identify attributes of subsections, based on
tag value. This information will indicate to consumers the semantics of how
to process those subsections without necessarily recognizing the tag
value. The second will identify, again by tag value, subsections which
are important, or crucial, to different tools. Tool version numbers
will be used to highlight problem areas.
The CM_TAGDESC subsection will store the following information for one
or more tags: tag value being described (numeric value), along with a
set of flags. The flags which may be set are
1) input-only -- the linker should not write out this subsection
2) local-strip -- strip this subsection if a file is being locally
stripped
3) strip -- strip this subsection if a file is being stripped
4) multiples -- multiple subsections with this tag value are permitted
5) concatenate -- data belonging to multiple subsections with this
tag value can be concatenated under a single header
The "multiples" and "concatenate" flags should be interpreted together:
if both are set, "concatenate" is ignored; if both are cleared and distinct
subsections exist, an error results.
Tag values are not required to have descriptors. The default behavior will be
input-only FALSE
local-strip FALSE
strip FALSE
multiples TRUE
concatenate FALSE
Another assumption is that duplicates (multiple copies of the same data
using the same tag value) will always be removed.
The CM_TOOLINFO subsection will contain information about which subsections
must be understood by different consumers. Each tool will be identified
by name and be followed by one or more (tagval, versionid) pairs. Each
pair will identify a subsection type and a version number of the particular
tool. If the "versionid" is lower (older) than the tool's version
number, understanding the specified subsection is not crucial to the tool's
functionality. The tool may proceed to process the object, at some potential
loss of information or lesser level of functionality. If the recorded
"versionid" exceeds the tool's version, the tool cannot process the object
and should quit with an appropriate message. Any tag value a tool does not
recognize but which is not recorded in the TOOLINFO subsection may be safely
ignored.
For instance, assume we have the TOOLINFO entry
ld : (10,2)
This signifies that the linker v.1 or lower (assuming integral versions
for simplicity) must understand how to process the subsection corresponding
to tag value 10. Otherwise it will fail in attempting to process the object.
On the other hand, the linker v.2 or higher can process the object. This
mechanism accounts for the possibility that v.2 is more robust than
previous versions, and can handle the object in an acceptable manner even
if it ignores the subsection.
The "versionid" will actually be a string rather than a numeric value.
This flexibility will each tool to use whatever criteria it wishes to
determine compatibility with the threshold version identified in the entry.
Finally, note that both these new tag types will be no-multiples/concatenate
in terms of their own attributes. Conflicting tag descriptions or tool
information will result in error messages.
I think this addresses the majority of issues raised in the discussion.
The formally revised proposal will follow shortly, along with the few
uncontroversial modifications suggested.
[Posted by WWW Notes gateway]
================================================================================
Note 18.10 ISSUE 9: Inadequate extensibility 10 of 21
TLE::LUCIA "http://asaab.zko.dec.com/~lucia/biography.html" 28 lines
14-JAN-1997 18:06
-< Interesting idea... Specific example might help >-
--------------------------------------------------------------------------------
Michelle,
Do I read this say:
{
cm_tag == CM_TAGDESC
cm_len == 4
cm_val == 100
}
...
+100 : 3 [tag 1]
+104 : 3 [flags for tag 1]
+108 : 4 [tag 2]
+112 : 16 [flags for tag 2]
means that CM_COMPACT_RLC (value 3) has flags input-only and local-strip
(assuming a bit mask using the numbering you proposed in .-1) and CM_NULL has
concatenate
??
(assume input-only == 0x01, local-strip=0x02, strip = 0x04, multiples = 0x08,
concatenates = 0x10...)
Tim
================================================================================
Note 18.11 ISSUE 9: Inadequate extensibility 11 of 21
NETRIX::"[email protected]" "Michelle" 16 lines 15-JAN-1997 08:34
-< reply to .10 >-
--------------------------------------------------------------------------------
Tim,
Your example is nearly correct. The cm_len field would not be 4,
since you've got 16 bytes of data as shown. Also, the +100 for the
data start is a little misleading because it's a sectional offset, not
self-relative. But, other than those details, that's the right idea.
One other comment is that I don't expect CM_NULL would realistically
get a descriptor. It could, and your flags choice for it would be
correct, but in practice it would be unnecessary since it's a tag which
requires tools to recognize it and process it specially. This mechanism
would more likely be advantageous for user tags or new system tags that
the tool set might not fully support yet.
-Michelle
[Posted by WWW Notes gateway]
================================================================================
Note 18.12 ISSUE 9: Inadequate extensibility 12 of 21
ADA9X::BRETT 7 lines 15-JAN-1997 09:24
--------------------------------------------------------------------------------
Two other behaviours might be
remove duplicates if identical byte stream
remove all but one occurrence regardless of contents
/Bevin
================================================================================
Note 18.13 ISSUE 9: Inadequate extensibility 13 of 21
AOSG::LOWELL 27 lines 15-JAN-1997 10:30
--------------------------------------------------------------------------------
re. .10
I'm not sure I'd label CM_COMPACT_RLC input-only or local-strip. Although,
it definitely would have the strip flag set.
I'm assuming that the known system tags in Steel will not need TAGDESC
entries, but we will document what the descriptors would look like if we
did generate them. That will make it clear how they're managed by ld, mcs
and strip.
re. .12
> remove duplicates if identical byte stream
Since we're suggesting always removing duplicate entries, this is the
same as
multiples TRUE
concatenate FALSE
> remove all but one occurrence regardless of contents
We toyed with this one but weren't sure of its usefulness.
If we do add a flag for this, I'd recommend revising it
slightly to make the behavior predictable.
remove all but the first occurence regardless of contents
================================================================================
Note 18.14 ISSUE 9: Inadequate extensibility 14 of 21
TLE::LUCIA "http://asaab.zko.dec.com/~lucia/biography.html" 3 lines
15-JAN-1997 15:49
--------------------------------------------------------------------------------
My example was of course purely hypothetical... Semantics were not a
consideration. And I was counting in words, not bytes. We can of course
ASSERT(cm_len % 16 == 0).
================================================================================
Note 18.15 ISSUE 9: Inadequate extensibility 15 of 21
ADA9X::BRETT 9 lines 16-JAN-1997 08:09
--------------------------------------------------------------------------------
Making it predictable is sensible.
I would amend it to
remove all but the least (in byte-dictionary-order) of the occurences
so that the order things appear on the command line doesn't matter
/Bevin
================================================================================
Note 18.16 ISSUE 9: Inadequate extensibility 16 of 21
FLYBA::BRENDER "Ron Brender" 99 lines 16-JAN-1997 16:03
-< Good beginning, some comments and suggestions >-
--------------------------------------------------------------------------------
Overall I think I like this approach. It appears to be both reasonably simple
yet flexible enough for expansion as future needs arise. More specifically:
Re: CM_TAGDESC...
Seems like we ought to require that this tag precede any occurence of the
tag described. If we wanted to be more rigorous/predictable we could further
require either
- all CM_TAGDESC blocks (that are present) must immediately follow the
CM_CMSTAMP item, or
- a CM_TAGDESC block must immediately precede the first (possibly only)
tag item that it describes.
Neither of these more restrictive rules really feels compelling, however.
But the first rule does seem warranted (otherwise, tools may end up having
to make two passes over the index blocks before they can start any processing
of any of them...)
Re: CM_TOOLINFO
>The CM_TOOLINFO subsection will contain information about which subsections
>must be understood by different consumers. Each tool will be identified
>by name and be followed by one or more (tagval, versionid) pairs. Each
>pair will identify a subsection type and a version number of the particular
>tool. If the "versionid" is lower (older) than the tool's version
>number, understanding the specified subsection is not crucial to the tool's
>functionality. The tool may proceed to process the object, at some potential
>loss of information or lesser level of functionality. If the recorded
>"versionid" exceeds the tool's version, the tool cannot process the object
>and should quit with an appropriate message. Any tag value a tool does not
>recognize but which is not recorded in the TOOLINFO subsection may be safely
>ignored.
I'm a little unconfortable here. I can think of these possibilities:
- Tool understands all tags that are present, so all is well
- Tool encounters some tag that it does not understand: in the absence
of TOOLINFO qualification it ignores that tag info (totally!)
- Tool encounters some tag with a TOOLINFO qualifier version that is
less than or equal to the tool's version. Seems like this ought to
mean that the tool is expected to understand the info. If so, then
all is well. If not, this is a *bug* (the programmers for the producer
and consumer have messed up) and deserves a "please submit a QAR"
message. But then what? Either
- the tool should quit, or
- the tool should ignore the data and proceed
Quit seems safer...
- Tool encounters some tag with a TOOLINFO qualifier version that is
greater than the tool's version. Seems like there are three desirable
behaviors, depending...
. The tool can quietly ignore the data and proceed -- since this
behaviour would result if no TOOLINFO qualifier existed, this
seems not too valuable a choice
. The tool can produce a message to the effect that "There is
information for me here that I don't understand. I will ignore
it and proceed. However, you can get better behavior by obtaining
a later version of me, namely V.n"
. The tool can produce a message to the effect that "There is
information for me here that I am required to handle but cannot.
You must get/use a newer version of me in order to proceed."
This last behavior is almost the same as upping the version
on the object module as a whole (remember we said we wanted to
start using such version numbers in the way intended). It
differs in that it is specific to a particular tool. (Eg, a
compiler can say it is OK for the linker to use the file, but
the debugger must be at least a certain version level.) This
seems a useful and desirable improvement in version number
specificity!
The choice between these last two can only be made by the producer,
since an old and venerable consumer might presumably predate even
specification of the data. To allow this, we could either beef up the
encoding of the TOOLINFO data, for example
ld : (10, 2, opt) => lds prior to V2 should warn and ignore
ld : (10, 2, req) => lds prior to V2 must punt
or possibly have two kinds of TOOLINFO, such as TOOLINFOOPT and
TOOLINFOREQ. Of these two alternative, I prefer the first.
An entertaining variation is to allow both, as in
LD : (10, 2, req) (10, 3, opt)
meaning ld V1 linkers better punt, but ld V2 linkers can warn/ignore/
proceed (and, of course, ld V3 linkers will understand and handle).
Me thinks this is probably overkill?
- *Am I missing any other plausible behaviors?*
Such are my 2� at the moment...
================================================================================
Note 18.17 ISSUE 9: Inadequate extensibility 17 of 21
NETRIX::"[email protected]" "Michelle" 50 lines 17-JAN-1997 15:21
-< Update >-
--------------------------------------------------------------------------------
I have updated the proposal published earlier. It's at the same location:
http://www.zk3.dec.com/~mn/ofst/cmscn.html
This remains a work in progress because there are still numerous issues
on the table.
We've adopted a "choose" flag in addition to the others mentioned
previously. This flag signifies that one subsection should be chosen
as a keeper among several input subsections with the same tag.
However, there are differing ideas out there about the selection
criteria, so that's left open for now.
A bigger change is that most likely the TOOLVERSION section (TOOLINFO
renamed) should only need a single entry per tool, rather than one
per tool per subsection. The idea is that either a tool can proceed or
it can't. Therefore only the highest version number among several
potential entries is significant. Presumably a tool that can proceed
will then look to the tag descriptor section for how to handle
unfamiliar tag values.
I haven't specified whether a TOOLVERSION entry is required for every
consumer. Thoughts?
re. 16
There should be only one CM_TAGDESC, with as many entries (describing
however many tags) as necessary. But the ordering seems like a reasonable
restriction.
My instinct is that a tool not recognizing some tags but without a
version restriction should read the CM_TAGDESC info on how to proceed
rather than ignoring (define "totally ignoring"!) the data. The whole
point of that mechanism was to give more information about unknown
tags so the data can be sensibly processed. And one major purpose of
the extended comment section is being able to store a variety of
data without causing problems for everybody. I don't want to lose
sight of that in the version discussion.
As for the error message, I think it would probably be best for a tool
to state which version is required to process the object, then quit.
But maybe different responses would be appropriate for different tools.
Finally, Randy has also been mulling over the idea that this versioning
mechanism may overlap with what we want for the entire object file.
But that discussion is for another day, I think.
I'm off to eastern Europe for a week. If the rest of you want to
solve all these problems while I'm on vacation, that's OK by me! :)
[Posted by WWW Notes gateway]
================================================================================
Note 18.18 ISSUE 9: Inadequate extensibility 18 of 21
AOSG::LOWELL 9 lines 12-FEB-1997 15:14
-< Update for online approval >-
--------------------------------------------------------------------------------
The next update of the comment section proposal is ready for review.
I'm considering this the online approval period. Starting now and
running through 2/21/97.
Michelle's taken out all of the tool version references and there
are some changes to the tag descriptor flags.
http://www.zk3.dec.com/~mn/ofst/cmscn.html
================================================================================
Note 18.19 ISSUE 9: Inadequate extensibility 19 of 21
GEMGRP::BRENDER "Ron Brender" 28 lines 13-FEB-1997 17:17
-< Some comment re February draft >-
--------------------------------------------------------------------------------
A few comments/suggestions -- mostly regarding the API:
1) Overall looks very good
2) My recollection is that we agreed to rename CM_NULL to the more suggestive
CM_END.
3) Re st_cm_add #1: Seems like there should be an additional parameter,
st_cmhdr_t *cmhdr, which receives the handle for the newly created
subsection.
4) Re st_cm_add #2: Should make clear that a new section is added even if
there is already a section with the same tag.
5) Re st_cm_print #1: Doesn't this routine need a parameter to specify the
output unit/channel/inode where the output is to be written.
6) Re st_cm_print #2, st_cm_append, st_cm_replace, st_cm_delete: These all
seem unclear as to what should happen if there is more than one
subsection with the same tag. Perhaps it would be better to replace the
unsigned int tag parameter with a st_cmhdr_t *cmhdr parameter. Then
any iteration for dealing with multiples can be left in the hands of
the caller.
Assuming the API is not an official part of the ECO, I'll vote YES. But if
the API is included, then I'll wait to see how 2) thru 6) above are resolved.
Ron
================================================================================
Note 18.20 ISSUE 9: Inadequate extensibility 20 of 21
SMURF::LOWELL 15 lines 14-FEB-1997 10:35
--------------------------------------------------------------------------------
Ron,
Thanks for the comments on the API's. I'm sure Michelle will
address each point. In the meantime, I thought I should verify
that the API's *are not* included in the ECO. The same goes for
the new mcs tool. The new tags and tag-descriptors are the main
points of interest in this proposal.
Also, I think your vote should still be contingent on point 2
"CM_END" since that's unrelated to the API's. We'll make that
correction right away.
-Randy
================================================================================
Note 18.21 ISSUE 9: Inadequate extensibility 21 of 21
AOSG::LOWELL 6 lines 21-FEB-1997 09:51
-< approved >-
--------------------------------------------------------------------------------
The .comment extension proposal has been approved.
OF/STWG ECO-ID = 11
More extensibility proposals are pending so the note
will remain as an open issue.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 69.1 | moved | AOSG::LOWELL | | Wed Apr 16 1997 11:52 | 4 |
| For bookkeeping purposes, I've moved this "inadequate extensibility"
subtopic to its own basenote.
The comment section support has been approved and mostly implemented.
|
| 69.2 | closed | SMURF::LOWELL | | Mon May 12 1997 16:03 | 3 |
|
The .comment section proposed changes have been implemented in Steel BL11
and GEM BL36. This issue is now closed.
|