AARDVARK

  Aardvark is the X/Open bug eater.  It is used to collect written
  comments on specific review documents.  Review comments or `bugs'
  should be phrased wherever possible in terms of specific wording
  changes.  Bugs submitted in this way can then be more easily
  discussed at relevant working group meetings, or voted on by email.

  Aardvark automatically processes and collates bugs from
  appropriately formatted email messages.  This allows all bugs
  from many sources relating to a single document to be collated
  and presented in page order in a single Change Request Report.

  To use Aardvark follow this procedure:

  Send your issues by electronic mail to the appropriate group
  in the following format :

Subject: BUG in <document_name>

@ page <no.> line <no.> section <no.> objection|comment|editorial [comment]

Problem:
Explain why here.
Be sure to add sufficient explanation for someone not
familiar with the problem to be able to make a decision.

Action:
Be specific.  For example:

Change  "leftmost character"
to      "first character in the string"

(You can normally trust the editor to take care of formatting issues in such
changes, including use of the correct font et cetera, unless there is
something out of the ordinary)

  NOTE that page and line numbers must not include spaces: 1-2,3,5-6
  is valid, but 1-2 3 5-6 is interpreted as 1-2.

  PLease DO NOT USE TABS, nor indent your text unnecessarily.

  Multiple comments on one document should be submitted in a single
  message.  Simply separate each comment by a blank line, then
  start again from the `@ page ...' line.  The `@' character
  must be at the beginning of a new line and be followed by a space.

  In the special case where you wish to raise a single issue
  which has similar ramifications at many places in the
  document, but which can be discussed together, it is helpful
  if you state the first instance with @ page and list later
  instances in the bug report without an @ symbol, for example:

@ page 344 line 62 section printf objection Also scanf

Problem:
Terms used in printf, scanf, and similar interface specs are not
consistent.  In various places the terms "conversion letter",
"conversion specifier", and "conversion character" are used
interchangeably.  I believe the correct term is "conversion
character", as defined on page 344, line 59.

Action:
Here and also at
page 344 line 52 section printf objection
page 344 line 53 section printf objection
page 346 line 92 section printf objection
page 381 line 40-41 section scanf objection
page 382 line 43 section scanf objection

Change "specifier" or "conversion specifier(s)" or
"conversion letter" to "conversion character(s)"

  If all goes well, Aardvark sends you a message
  confirming the number of bugs it was able to process from your
  message.

  Malformed "@" lines are rejected; if this happens,
  Aardvark tries to send you email telling you which lines it
  could not process.


The following are examples of invalid aardvark:

@ page 373 line many section objection line "many" is not valid
@ page 0 line 0 section objection section not specified
@ page 606 line all section objection line "all" not valid

Please include line numbers and a section reference (either
numeric or interface name).



Bug Categorization


 There may be cases where the originator feels unable to provide
 text, for example where a clarification is requested.  In such
 cases there are two possibilities:
   - write down one of the possible alternatives.  This at least
   serves to illustrate your concern.
   - contact someone else, in advance, who may be able to suggest
   some wording.
 Wording can be improved at the resolution meeting, but there
 will not be time to create new wording, and no possibility
 of subsequent off-line text generation.  To emphasize:
 CHANGE REQUESTS WITHOUT EXPLICIT EDITING INSTRUCTIONS WILL
 BE REJECTED.


1. Objections

You should only classify an issue as an "objection" if you would vote
against approval of the submission if that issue is not resolved.  Any
objection which is not supported by rationale, or which does not provide a
responsive proposal for resolution, will be deemed invalid, and reclassified
as a "comment".

2. Comments

If you wish to raise an issue where you believe that a better solution is
available, but the issue would not, on its own, cause you to vote against
approval of the submission if the issue were not resolved, you should
classify it as a "comment".

3. Editorials

Issues marked as editorial will not be discussed, they are included in this
mechanism as a simple way to bring such matters to the sponsors attention.
(If you see someone else classifying an issue as editorial, and you believe
it DOES need discussion or clarification, you should resubmit the point
yourself, with a different classification.)


Note that it could be helpful for you to include a company identifier and 
sequence number (eg X/Open 25) in the optional "comment" field within
square brackets ([]) at the end of the @page line for later cross 
referencing, as Aardvark consolidates the input from all sources into a 
single numbered list. 


-------------------------- end of file -----------------------------------