ISO/ IEC JTC1/SC22/WG14 N973

                  Minutes for ISO/JTC1/SC22/WG14 and INCITS J11
                         Document WG14/N973, J11/02-001

                                15-19 April 2002
                          Curacao, Netherlands Antilles

1. Opening activities

1.1 Opening Comments

  Randy Marques, our host, extended a warm welcome to Curacao (and cautioned
  us about the tropical sun).  Instructions were given for gaining web, news,
  and email access.

1.2 Introduction of Participants/Roll Call

  United States (J11)
    John Benito, Farance Inc. (Convener)
    Douglas Walls, Sun (HOD)
    John Parks, Intel
    Clark Nelson, Intel (non-voting)
    Fred Tydeman, Tydeman Consulting
    Randy Meyers, Silverhill Systems
    Raymond Mak, IBM
    Jeff Muller, Oracle
    David Keaton, Self
    Barry Hedquist, Perennial
    PJ Plauger, Dinkumware
    Tana Plauger, Dinkumware (non-voting)
    Tom Plum, Plum-Hall
  Canada
    Raymond Mak, IBM (HOD)
    Walter Banks, ByteCraft
  UK
    Francis Glassborow, Self (HOD)
  Denmark
    Allan Frederiksen, Nokia
    Jan Kristoffersen, RAMTEX (HOD)
  Netherlands
    Randy Marques, Atos Origin
    Willem Wakker, ACE (HOD)
  Germany
    Nobuyoshi Mori (Nobu), SAP (HOD)
  Norway
    Keld Simonsen, RAP (HOD)

1.3  Selection of Meeting Chair

  John Benito, Chair
  John Parks, Secretary

1.4  Procedures for this Meeting

  Everyone was encouraged to participate (and participate in straw votes),
  regardless of voting status.  For formal votes, we would vote as 
  countries.

1.5  Approval of Previous Minutes (N960)

  Approved without objection.  Will get new document number and be made
  public.

1.6  Review of Action Items and Resolutions

  The following action items are now CLOSED

  o  Gwyn: Rationale words for 6.2.6.1 trap representations
  o  Tydeman: Rationale words for 6.3.1.6 complex types
  o  Tydeman: Rationale words for 6.3.1.7 real and complex
  o  Jones: Rationale words for 6.9.2 External object definitions -
     tentative definition
  o  Jones: Rationale words for 6.11.(1,2,3,4,7,8,9) Future directions -
     array parameters removed
  o  Tydeman: Rationale words for 7.12 Need list of new math (as of C99) 
     functions
  o  Benito/Thomas: Rationale words for 7.12 Redo Jim Thomas's words on 
     math, e.g., 'this draft', 'that draft'
  o  Tydeman: Rationale words for 7.12.14 FP compare
  o  Tydeman: Signaling NaN paper
  o  Benito: explain blue line in DRs; add (and explain) more states of
     DRs in DR log
  o  Benito: DR 273 __STDC_ISO_10646__
  o  Kristoffersen: new example for annex D (IOHW)
  o  Wakker: prepare disposition of comments document
  o  Benito: determine what to do about registering C locale

  The following action items are still OPEN

  o  Benito: C99 Time issues and WG15
  o  Mak: Sequence points paper in TR format (Tydeman, Seymour, Seebach,
     Meyers will review/help)
     Needs review comments, will distribute paper after meeting.
  o  Meyers: write paper based upon DR 219
  o  Meyers: review DR 230
  o  Meyers: Rationale words for 6.3.2.1 rvalue array type
     Randy wasn't sure.
  o  Gwyn: Rationale words for 7.1 General library overview on const
  o  Gwyn: Rationale words for 7.18.1.5 Greatest-width integer types
  o  Meyers: DR 230 paper
  o  Gwyn: DR 274 alternate wording
  o  Benito/Plauger: DR 224 response on INFINITE

1.7  Approval of Agenda (N967)

  Simonsen: requests time (30 min) to discuss C locale, Tues AM, first thing
  Walls: requests to change US TAG meeting to Wed afternoon
  Tydeman: signaling NaN paper, do that in liaison section
  Glassborow: requests time to talk about UK-hosted meeting

1.8  Distribution of New Documents

  None.

1.9  Information on Next Meetings

  1) October, 2002 -- Santa Cruz, CA

    hosts: Perennial and Dinkumware
    dates: 10/14 (for C) 10/20 (for C++)
    hotel: West Coast Santa Cruz Hotel (former Dream Inn)
      make reservations directly with hotel
      don't have to stay at Inn, there are B&Bs, etc. nearby
      room rate is good, all rooms have ocean view
      $125/night single or double, $135 triple, $145 quad
      rate will stretch to one or the other weekend
  
  2) April, 2003 -- Oxford, UK

    host: UK
    dates 3/31 (for C), 4/7 for C++)
    hotel: Holiday Inn (just outside ring road)
      entirely rebuilt, excellent conference center, 
        good internet connections
      $145/room (110 pounds) at current exchange rate, includes tax and
        full breakfast
      trying to negotiate lower room rates
      Travelodge next door, 70 pounds/night, no breakfast
    ACCU Spring conference will be there also
      looking for presenter(s)
    sponsorship: ACCU and 2 private sponsors (including Francis Glassborow)
      co-sponsor would be very welcome, free spot at the conference
      Plum: large companies that do business in UK may want to consider
    bus service, train service, easy to get to/from London and Oxford

  3) October, 2003 -- Kona, Hawaii

    host: Plum-Hall
    preliminary dates: 10/15-10/21 (for C), 10/20 (for C++), 2 days overlap
      the Iron Man Triathlon hotel blackout period makes it difficult to
        begin on 10/13
      Wakker: 2 mid-week travel days may be objectionable
      could consider shorter meeting

  4) April 2004 -- Norway (possibly Oslo)
  5) October 2004 -- searching for North American host

1.10 Identification of national bodies

  Canada
  Denmark
  Germany
  Netherlands
  Norway
  United Kingdom
  USA

1.11 Identification of J11 voting members

  11 voting members present, a quorum.

2. Rationale Editors report (Benito)

  Benito doesn't have new doc for this meeting
  with help from Jones and Tydeman, got everything into doc that was supposed
    to go into doc (from Redmond meeting)
  problems with index, Microsoft Word issues, removed index style, Benito 
    now producing another one
  that's ONLY issue left with Rationale
  Benito will give doc number and post to web once the index problems are 
    resolved

  Plum
    why not get rid of index?
  Benito
    rumors are that somebody wants to publish it with all of C99 and first
      set of defect reports
  Tydeman
    would it be worthwhile to publish to website without index?

  [AI] Benito: will post to website without index
  [AI] Glassborow: volunteer to take care of index

3. TR Status Report (ISO/IEC WDTR 18037.2, WG14 N968, Wakker)

  this is the latest version of the TR
  most important changes: fixed-point arithmetic and section that details
    exact changes to the C99 Standard
  need more comments on doc (it's been too quiet)  
  hope to have decision on next ballot by the end of this meeting

  Plum: C++ liaison issues
    historical perspective: we didn't define a compatibility header to 
      facilitate the use of complex in both languages; that issue is still
      being hotly discussed on the C++ side
    if we try to define THE compatibility header in this case, however, 
      we've got no chance to make it compatible with local conventions (which
      are suited to local needs)
    an existent proof would be nice but neither committee should define the
      header

  Glassborow
    until you do existence proof, you don't know it's possible
    who should do it is difficult problem
    we shouldn't avoid issue
    a template-like syntax might help

  Wakker
    philosophy was to create basic types, implementations can provide
      mappings to more locally palatable names
    Annex G is informative, not normative, it only suggests how implementors
      might provide compatibility C/C++

  Meyers
    very little work by C and C++ committees would have gone a LONG way
      toward making life easier for implementors and users

  Plum
    would be good to show example of a compatibility header in the document
      (including values)
    C0X implementation has efficiency edge on C++ because it has REAL fixed
      point values, probably not a big deal

  Glassborow
    when either language makes future changes, if you had a compatibility
      header you would have something to regression test against

  Plum
    before the decision about whether header is normative or informative is
      made, we need header

  Plauger
    there are regrettable incompatibilities between C/C++ complex but that
      case is overstated, Dinkumware has existence proof of headers that 
      reconcile library complex differences
    Dinkumware will soon begin work on fixed-point libraries, not terribly
      worried about incompatibilities

  Benito -- next ballot on this is technical
    next step is to move on to draft status
    at end of week -- are we ready to move this forward?
    if we do NOT move this to draft status after this meeting, that will
      REALLY push this out
    if we get this out from this meeting, we can move on

4. Liaison activities

4.1 J11 (Meyers)

  nothing much to report
  NCITS has become INCITS (International NCITS)

  Tana Plauger
    this may be difficult for small companies since they can be 
      over-dominated on international committees

  Plum
    small corporations are probably already under-represented in all countries
    US domiciled corporations can go to individual US TAGs
    natural conflict -- should US standards committees always push US point
       of view OR be seen as participating in international efforts

4.2 WG14 (Benito)

  convenership open, Benito will volunteer again if there are no objections
    or volunteers
  plenary in August in Finland, Benito will attend
  new work item vote failed (item 5, discussed later)

4.3 J16/WG21 (Plum)

  C/C++ compatibility issue is flaring up again
  there are process issues and technical issues, Plum wants to address
    process issues and leave technical to Meyers
  Plum suggested in Redmond that to improve things, we should work within
    ISO procedures, not try to create new special arrangements
  proposal: let's encourage as many companies as possible to participate
    in both committees (and as liaisons)
  WG21 designated 7 liaisons from WG21->WG14 (that was also done for
    WG14->WG21 and those names were listed in the WG21 minutes)

  Tana Plauger
    if you are designated as a liaison are you automatically part of the
      other group?
  Plum
    no, you must have some interest and expertise in the other language

  liaisons
    Dinkumware and Intel want to be added as liaisons
    Perennial is already on the list
    Benito is now off the liaison list

4.4 WG15 (POSIX) (Simonsen)

  new revision
  IEEE and OpenGroup have voted affirmatively (the ISO vote must do so
    also before this can become FDIS)

4.5 WG20 (I18N) (Simonsen)

  there was a proposal to disband this group, it was resolved/defeated in 
    SC22 though the vote was close

  Benito
    is there another disband proposal on the table?
  Simonsen
    no knowledge of that

  there are a number of standards being considered
    1) updated repertoire of 10646 (Unicode), ballot ended 4/14
    2) TR 14652, ballot ends middle of May
    3) API standard, about to be disbanded, not progressing
       changed from language independent spec to spec that it bound to C,
       maybe it should be dealt with in C Committee?
    4) tech report on design of programming languages
       WG14 has used character descriptions
       about to go out to ballot (next few weeks)

  Plum
    SC22 plenary talked about politics
    SC2 has close working relationship with Unicode Consortium
    strong feeling at ISO that we want just one place (committee) where
      identifiers are defined
    inconsistency -- Java uses Unicode, C++ and C point to different versions
      of WG20 document which are inconsistent with Unicode
    there is the "checks and balances" argument -- SC22 is court of last 
      resort for small companies and countries
    would like to see document that explains why particular characters that
      aren't in Unicode really need to be considered
    it would be good if we stopped pointing to WG20 documents

  Simonsen
    the history is that Unicode picked up WG20 character list work
    WG20 and Unicode Technical Committee cooperate (UTC is WG20 liaison)
    Unicode is soldier of big American firms, other cultures need clout

  Nobu (who is also on Unicode committee)
    small differences, lists are synchronized, Unicode is not just American
      corporations, they support WG20's work

  Glassborow
    standards are about portability
    our expertise is in language design, not character sets, we should confine
      ourselves to language design

  Nobu
    C# may soon become ISO language, 16 bit characters, we should strive
      for compatibility there

4.6 WG11 (Wakker)

  the language independent arithmetic ballot succeeded
  Frank Farance taking lead in revising data types

4.7 Other Liaison Activities

4.7.1 Tydeman: signaling NaN paper

  the paper is up on the website
  he has had feedback from Nick Maclaren and a trial implementation
  will remove problem section and repost, will eventually be rewritten

  [AI] Tydeman: give Simonsen revised document, Benito and Keaton will
    also review

4.7.2 Changes to WG21 Liaisons
 
  remove Benito
  add Dinkumware and Intel
  need leader
    Plum is convener and so cannot, may drop convenership in October and
      then might consider it
    Francis Glassborow will do it, if only for a short time

4.7.3 Other Liaison Issues

  Simonsen
    SC22 plenary in August, will discuss char set issues (including Unicode)
    will we prepare input for that meeting?  
  Benito
    add agenda time to discuss WG14 input to SC22 plenary tomorrow morning
      after C locale conversation
    Benito will attend plenary to represent WG14

  Simonsen
    there are 3 J11 ballots pending (DIS C#, DIS TLI, TR TLI), they end in 
      middle of July, there is a ballot resolution meeting end of September 
      in Hawaii
  Walls
    there were very few comments on C# (doc edited by Rex Jaeschke) and the
      review period is now over
  Plum
    US TAG part of J11 gets the opportunity to comment on language docs 
      that come through, it is strongly encouraged to form an opinion, only
      several of the committee members might have any interest or knowledge
      of the subject matter, C++ refused to take a stance and instead voted
      to abstain
  Benito
    that process is clearly broken

------------------------- lunch (sponsored by ACE) -------------------------

5. SC22 N3356 (Benito)

  the ballot for this new work item failed
  in Redmond we had 6 countries interested in this, only 3 voted for it and
    we need 5 to continue this work
  what does it mean for a country to say that a work item should be pursued
    but they don't want to participate?
  Canada and the Netherlands think they probably should have voted for this
  hopefully, we can straighten out the vote this week
  let's talk about this work item this week anyway

  Glassborow
    doesn't understand the UK vote and nobody consulted him
    doesn't want UK to be left out of it

  Wakker
    the corrected Dutch vote will be issued in the next day or two

6. Defect report status (Benito)

  Benito made all of the changes that were requested of him
  described terms (closed, closed published, closed with date, review, open)

  Simonsen
    questions methodology

  there was consensus agreement that Benito followed agreed upon process
  defect reports are on the web, not in mailing

7. ISO/IEC WDTR 18037 Editors report (Wakker)

  type names have changed
  new type conversion rules (2.1.4)
  r, q, h for constants and formatted I/O (capital for unsigned versions)
    for fract, accum, short variants
  open issue: wide string versions, are they necessary?
  asked committee for feedback on whether the format of section 2.2 
    (detailed changes to the C Standard) is reasonable
  are there machines where sizes of accum/fract don't map to size of 
    integers?  yes.

  Keaton
    in past meetings it was agreed that there are some machines that simply 
      can't be supported by this model, that's OK since this will work for 
      a large class of machines

  asked committee to please read and review
    annex G on C++ compatibility
    annex F on functionality not included in this TR

8. Additional character types (N969)(Nobu)

  the paper is mostly a summary of the WG14 reflector discussion on the
    SAP proposal to add a UTF-16 character type to C/C++

  Plauger
    many of the proposed solutions are horrible, including anything that 
      wires UTF-16 into the C Standard, it only has currency now because 
      Java chose it
    biggest lapse we made in C89 was to provide little/no guidance on wide 
      character mapping
    proposes adding char16_t and char32_t
    solves user problem that we don't know what wchar_t is going to give us
    likes idea of generalizing string literals as mechanism for static 
      initialization
    would like us to define where users can change wide char representations
      within their code

  Plum
    the conjecture that UTF-16 was chosen because of Java is not right, it's
      really the sweet spot for databases and codes that large corporations 
      are trying to standardize on (convenience versus efficiency tradeoff),
      8-bit is too short, 32-bit takes too much space
    we've got constituencies asking us for 16-bit
    the original request was for a type whose size was evident from its
      name and whose representation was the approved ISO-blessed Unicode
    UTF-8 and UTF-16 are stateful encodings, UTF-32 is not  
    we're really extending our pioneering work that allows users to prepend
      'L' on string

    certain operations can only be defined on "strings" not individual chars
    we can't eliminate individual char processing methods but we want to
      restrict its use as much as possible (hopefully, just to library)

  Simonsen
    there is a business need for us to support UTF-16
    UTF-32 is a tainted term, a Unicode-only term, UCS-4 is more politically
      correct
    wants to get rid of 'L' at end of strings because they're ugly
    agrees with Plum that we should start looking at "strings" as basic unit
      of operation

  Benito
    paper was meant to be high-level summary, no divisive

  Mak
    there is no need for UTF-32 (though there is need UTF-16)
    C model is that wchar_t is fixed width encoding
    proposal is for 16-bit, variable width encoding (for efficiency)
    optimum length seems to be 16 bits
    if we want to be more general, let's define a 16-bit type that can map 
      to more than just UTF-16
    we should decouple wchar_t and the new data type to prevent user problems
      mixing objects with those types

  Plum
    programmers that need UTF-16 strings need them now (and have needed 
      them for several years) and have responded to that need by 
	1) writing text-to-text preprocessors, and
	2) hacking gcc internally
    compiler solution would eliminate the need for these workarounds
    our TR charter included investigation for ongoing library work, not
      to define new APIs (charter: data type, initializer, APIs)
    if we add a 32-bit type, we may encourage programmers to use it as their
      fundamental type and that's not what the Unicode Consortium is 
      recommending (they are recommending UTF-16)

  Nobu
    agrees that we don't need UTF-8 (redundant)
    if majority think UTF-32 is unnecessary (or undesirable) he will go
      along with that
    endianness is not in proposal

  Glassborow
    data types that include state information are complicated to handle
      (UTF-32 would be required to get rid of state info)

  Plauger
    if this was a good idea somebody would have implemented it
    doesn't like principle of somebody convincing committee to do something
      so we can see if it's a good idea...

  Simonsen
    UTF-16 is not just Unicode, it's an ISO standard
    we should not do quick fix, we'll have to live with this for years

  Meyers
    C committee was wise to leave char set stuff out of language
    there seems to be strong need to 16-bit equivalent to char and it would
      probably be wise to make it generic

  Plum
    quality-of-implementation question: C++ will need to overload on array
      of UTF-16

    it is hopeless to try for "stateless" code points
    UTF-32 entity is a "code point" (character) 
    implementations must deal with combining code points (ordering and 
        adjacency matter) so they cannot be entirely "stateless"
    Unicode defines "canonical sequence" of code points so they can be 
      manipulated

    it is not necessary for code points to encode endianness
    everything that we are discussing deals with array of 16-bit int type,
      it is an int type, there is only one endianness, it's the type that is
      supported on this platform, it is thus not an issue on this platform,
      just for interchanging data across platforms (on web), within same 
      machine family, use native endianness
    endianness is data interchange problem (library vendor)

    there is existing practice 
    the installed bases of .NET and XML and Java are existing practice, 
      they represent a sizeable market

    we are not withdrawing support for traditional C char/library methods
      (traditional POSIX narrow/wide char model), this proposal simply adds
      support for a new market

    we are standardising another character in front of string literals, if
      another community needs another encoding standardised they should 
      consider the door open to add yet another letter

  Nobu
    other 16-bit encodings (the ones he knows about) are just historical,
      they have been replaced by Unicode

  Walls
    vendors have standardised on char and wchar_t
    we have customers begging us for 16-bit Unicode, we tried to convince
      them otherwise, they wouldn't go away, we said that we'd work with
      them on the Standards committee 
    there is more pressure for this for C than for C++

  Simonsen
    Unicode has something like 10 normalization forms, to canonically
      represent a string (10646 has just one)

  Plum
    the real problem is getting from initializer double-quotes to array of 
      16-bit ints, that's what cannot be done without a preprocessor

  Simonsen
    idea: instead of a new char type, offer them a string type

  Plauger
    let's NOT wire UTF-16 into C, let's make it possible but not necessary
    if the market forces make it happen, so be it
    does NOT accept premise that we've finally gotten characters right

------------------------- break -------------------------

  Nelson
    UTF-16 is not a valid wchar_t encoding, UTF-32 is not valid either
      because it is not really stateless

  Plauger
    "grapheme clusters"
    SC22 passed a resolution a decade ago that said that language groups do
      not need to treat combining characters

  Plum
    there are combining characters in spoken languages, so even if your 
      char set does not use them, the language itself might (addressing
      Nelson's point about UTF-32 not being stateless either)

  Plauger
    the problem with processing UTF-16 as chars is embedded nulls

  Nobu
    problem with wchar_t is that it is historically implementation-dependent

    can we summarize the conversation in such a way that we can move the 
      document forward?  Do we perhaps agree that
      1) UTF-8 is not necessary
      2) we should create UTF-16 data type
      3) we should create UTF-32 data type

  Simonsen
    UTF-32 is not necessary
    a more generalized approach would be better, one that includes information
      about which encoding, etc.
    doesn't want to call out specific standard

  Meyers
    you can consider UTF-8 as multibyte type, store in char
    why isn't UTF-8 desirable?

  Mak
    UTF-8 is not being asked for
    UTF-32 is not required either
    we should focus on just what's missing in the C standard - the
      translation of UTF-16 literals (which isn't now possible)

  Plum
    let's take straw votes and then move on from there
    there won't unanimity in any case
    proposal: we should consider 2.1 with "some" string literal prefix and
      not including UTF-32 (2.2)

  Plauger
    what would make Sun happy?

  Nelson
    is it important to have wide-string literals and UTF-16 in the same
      translation unit?  

  Nobu
    no, there are technical problems with that

  Plauger
    do we really need more than 2 char encodings?  
    wouldn't customers be happy if the platform just made wchar_t 16-bit?

  Walls
    no, customer does not want that
    they ship their own library

  Simonsen
    iconv can solve problem ad hoc

  Plauger
    there are any number of ad hoc solutions, the question is what's the 
      nicest thing to do to the C Standard

  Nobu
    what would be the minimal approach to make customer happy?
      1) compound literals 
      2) new minimum approach
      3) 1 or 2 new data types

  Plum
    argues for 2.1 proposal since C++ doesn't have compound literals
    compound literals happen at the wrong phase of translation

  David Keaton
    compound literal approach spreads character set translation across 
      multiple phases of translation (they wouldn't be entirely lexical)

  proposal that we take a straw vote on the concepts, not the specifics
    of the approaches described in the paper - are you in favor of 
    pursuing an approach along the lines of...

  Walls
    suggests that we all reread the paper
    straw vote first thing tomorrow morning

  Mak
    let's separate 2.4a/2.4b so that we can separate out the 32-bit type

========================= adjourn for day =========================

Tuesday, April 16, 2002

continuation of discussion about N969 and the possible addition of 
  new character types to the C language

-------------------------------------------------------------------

  Plum
    2.1 is what the Unicode Technical Committee originally requested, 2.2 is
      an extension of that (thinking that UTF-32 might be needed someday),
      the rest are afterthoughts
    everything after 2.3 tells the Unicode Technical Committee that we don't
      want to do what they're asking for (i.e. create a data type that is
      exactly UTF-16), they are just alternative ways to say "no"

  Simonsen
    there are other requests than just this one from the Unicode Technical
      Committee
    the Norwegian member body may/will propose that we have more 
      portable/generic literals

  Benito
    let's not complicate vote
    let's deal with votes on this paper then move forward
    there is no other paper on the agenda about longer char types

  Walls
    some of the other proposals are being asked for (2.4 in particular)
      selectable by compile-time option (for some character set other than
      UTF-16)

  Plum
    what's the marketplace demanding (other than UTF-16)

  Walls
    "other" character sets

  Nobu
    2.1 is the minimum approach
    the Unicode Technical Committee would be happy with it

  Plauger
    this isn't simple issue of handling a request from another body, this is
      a long-standing and controversial issue
    now that UTF-16 has been raised, it is absolutely appropriate to raise
      other alternatives at this time
    it is important to address the issue about switching between wide char 
      encodings
    this vote is just preliminary step towards addressing these issues

  Glassborow
    these proposals raise compatibility issues with C++
    doesn't like typedef to introduce new data types - if we want new data 
      types we should introduce data types
    we shouldn't do anything without consulting WG21

  Mak
    UCS2 can already be handled in implementations by defining wchar_t 
      (since it's fixed-width) to be 16 bits
    you can't do that for UTF-16 since it's variable-width

  Plum
    proper C++ solution would be to allow specification of underlying type
      of enum (like you can do in C#)

  Glassborow
    problem with all these solutions is that they are creating arithmetic types
      for object that are not arithmetic

  ------------------------------------------------
  [straw vote] on additional character types (N969)
  ------------------------------------------------

  1) who is in favor of something along the lines of 2.1?
     in favor 10
     opposed  7
     abstain  4

  2) who is in favor of something along the lines of 2.2 (as an 
     addition to 2.1)
     in favor 0
     opposed  12
     abstain  8

  3) who is in favor of something along the lines of 2.3?
     in favor 0
     opposed  12
     abstain  8

  4) who is in favor of something along the lines of 2.4 for char16_t?
     in favor 6
     opposed  2
     abstain  13

  5) who is in favor of something along the lines of 2.4 for char32_t?
     in favor 2
     opposed  7
     abstain  12

  6) who is in favor of something along the lines of 2.5 for 16-bit?
     in favor 3
     opposed  1
     abstain  17

  7) who is in favor of something along the lines of  2.5 for 32-bit?
     in favor 1
     opposed  6
     abstain  14

  8) who is in favor of something along the lines of 2.6?
     in favor 0
     opposed  11
     abstain  10

  9) who is in favor of something along the lines of 2.7?
     in favor 0
     opposed  12
     abstain  9

  10) none of the above (do something different)
     in favor 6
     opposed (I want one of the above) 6
     abstain  9

  Benito
    the committee has already said it wants to do something about this
      (from Redmond meeting) and it has already been communicated to Unicode
      technical committee

  Nobu
    a lot of people seem to favor a different approach
    wish those people who had spoken up earlier

  Benito
    calls for Simonsen to get paper in post-Curacao mailing that might
      outline a different approach
    to move forward, we need these other approaches spelled out

  Plauger
    put myself in category of "asleep at the wheel" busy providing stop-gap
      solutions at Dinkumware

  Benito
    deadlines for mailings are generous and can be flexible
    the deadline is usually 4 weeks after the meeting but that can be extended

9.0 Registering C Locale (Benito)

  Benito was asked to register C locale (London 1999 meeting) and he sent
    doc to SC22
  there was a ballot, ballot comments, Benito tried to answer them
  we need to finish resolving comments
  doc N3236 (at SC22 website)
  SC22 decided that WG15 should answer 2 of the questions (that hasn't 
    happened)
 
  Simonsen
    believes that we are responsible for answering all of them

  Benito
    in Redmond, there was discussion about whether we want to register this
      locale at all
    do we want to register the locale?
    if we do, let's resolve the comments and it's done

  Plauger
    in favor of registering it
    it fills in some of the gaps from our original C locale description

  Mak
    does registering locale mean POSIX implementations or ALL implementations
      must conform?
    it would be difficult for EBCDIC to conform

  Plauger
    C implementations that don't conform to POSIX need not conform to this
      C locale requirement
    this would only apply slightly more pressure to conform

  Plum
    specifically applies only to POSIX conforming implementations
    needs to be documented as such or there will be confusion

  Benito
    says that at the top of the document
    [AI] Benito: verify that the C locale specification says that it 
      applies only to POSIX conforming implementations

  -----------------------------------------------------------------------
  [straw vote] should we continue with this registration of the C locale?
  -----------------------------------------------------------------------

    in favor 17
    opposed 1
    abstain 2

  [AI] Benito: circulate his preliminary answers to ballot concerns to a
    few people (Wakker, Plauger, Simonsen, Hedquist), will put in post-Curacao
    mailing, will forward to SC22

10. Character set ad hoc at the SC22 plenary (Benito)

  Benito plans to attend plenary
  is there anything that WG14 wants him to talk about there?

  Simonsen
    should we support 10646 Unicode?  yes.
    should we have some means of support for UTF-16?  yes.
    should continue to support other char sets?

  Plum
    we've got a sub-optimal way of working now, SC2 and Unicode are not
      going away no matter what SC22 does, wherever possible our standards
      should point to Unicode and merely point out where they are wrong
    right now we have 2 moving targets, theirs and ours

  Nobu
    hopes everybody will give better support to Unicode standards, that is
      what market needs

  Simonsen
    Unicode has a lot of expertise and they should have their say
    SC22 is appropriate counterpart with slightly different focus
    it is good to have forum within ISO that coordinates and cooperates
      with Unicode Technical Committee
    ISO does API work and strings work that is not done in Unicode
    WG20 definitions are "almost same" as Unicode

  Plum
    eventually the C++ annex on identifiers will change (when everything
      settles down); there are 2 possible ways it might change
      1) change C++ to adopt the C approach to upward superset-ability
	 (an implementation can support more identifier chars than the min)
      2) adopt the rule that a character is an identifier character if either
         it appears on the WG20 list OR the Unicode list (union of 2 lists)

  Simonsen
    stability is important, Unicode updates very frequently

  Glassborow
    purpose of standards is portability
    extended identifiers go against that
    is is unfortunate that C is written in language that is so much like
      English
    readability is important but it harms portability

  Plum
    do any vendors/customer bases use extended identifiers?
    moving target is part of the problem
    every few months when Unicode adds a new script implementors cannot
      afford to keep modifying their lexing algorithm 
    we could probably make a list of all non-identifier chars, then 
      implementors could choose to make ALL others chars legal ident chars

  Meyers
    last days of PDP-11, C compiler added support for extended Latin-1 chars
    and that was very popular

  others commented that they know of places that are using extended 
    identifiers

  Simonsen
    both Unicode committee and WG20 came up with positive lists (not negative
      lists like Plum suggested)
    WG20 discussed positive/negative list extensively; they chose positive 
      and he thinks that was the right decision

  Nobu
    well-defined negative lists would allow for better portability

  Benito
    summarizing - Norway is saying
      1) character set independence
      2) less frequent updates

------------------------- break -------------------------

  Benito
    Dutch vote on new work item TR has been officially recorded as "yes"

11.  Break out into defect reports subgroup (12 people, led by Nelson)
     and embedded TR subgroup (9 people, led by Wakker)

========================= adjourn for day =========================

              Thursday, April 18, 2002, Plenary Session

12. Embedded TR discussion review (Wakker)

  UK, Netherlands, and Canada have revised their ballots to say that they
    wish to participate
  that brings the total to 6 who wish to participate
  Norway still has concerns

  the subgroup went through section 2
  discussed John Hauser proposal
  the Annex will say that the approach being suggested is only suggested
    (not mandated), the Hauser approach may prove better

  Annex G (compatibility with C++)
    more input from WG21 is necessary
    current text gives good indication about what could be done in that area

  confidence that the document is complete both textually and technically
  propose that document sent out of WG14 shortly after meeting
  will get minutes from subgroup scribe

  Benito
    how is C++ input getting solicited?

  Wakker
    that was not discussed explicitly
    it is not yet on radar screen at WG21

  Glassborow
    there may be interest in WG21 if it is nurtured
    will push it with WG21

  Plum
    we should rely on our new 8-person liaison group

  Benito
    time for feedback is NOW, not after we push document into draft
    our document is freely available on the website
    it would have been good to have their input ALREADY

  Plum
    in present times of diminished budgets we need to look hard at our new
      work with concern towards what implementors can afford to implement

  next ballot stages
    move TR into official committee draft (PDTR)
    final PDTR
    DTR

  Benito
    if the ballot passes (at SC22) it will become draft technical report

  Simonsen
    PDTR puts SC22 member bodies in control (in some sense), WG14 can only 
      change through formal comment process, changes will be tracked

  Glassborow
    concerned that sending this to SC22 may cause problems working with WG21
      (since changes will then be harder to make since control will be in the
      hands of the national bodies)

  Wakker
    SC22 ballot only means we will track the changes better

  Simonsen
    after this has been sent to ballot we can only change it in response to
      comments
    there is no need to delay what we're doing
    this ballot will tell WG21 to take this seriously

  Plum
    annex G is more important to WG14 than WG21, it is our document
    WG14 needs to work harder on this annex

  Plauger
    there is still ample time for WG21 to get up to speed and give adequate
      feedback on this document

  Plum
    would be nice to have agenda time devoted to technical content of Annex G

  Glassborow
    politically, it would be better to go to WG21 before rather than after 
      ballot

  Simonsen
    we have already done registration vote at SC22, this isn't the first vote
      on this

  -------------
  [formal vote]
  -------------

  To instruct the WG14 convener to submit document WDTR 18037 as amended 
  for SC22 PDTR ballot as quickly as possible after this meeting.

  J11 vote (10 present)
    Benito moves, Tydeman seconds
    in favor 10
    opposed   0
    abstain   0

  WG14 (7 present)
    in favor  6
    opposed   1
    abstain   0

13. Defect report review (Nelson)

13.1 DRs ready to close with no change to the committee recommendation
     (we're recommending that these be moved to "closed")

  224, 235, 238, 239, 240, 241, 242, 244, 246, 247, 248, 249, 254,
  256, 258, 259, 262, 263, 264, 273, 276, 278

  It was noted that the response to DR 258 could be nicer.  Benito 
  commented that all of the responses will be reviewed and made nicer
  where appropriate.

13.2 DRs in the "review" state where we want to make some kind of change

  DR 237
    we agree but will add footnote similar to the first bullet item in the
      response that explains implications
    [AI] Meyers: write footnote

  DR 243
    we question justification for imposing documentation requirement here
    Tydeman has submitted essentially the same proposal to IEEE committee
    we want to hold this until IEEE decides what to do with it
    Wakker suggests that we should add response words that say that
    leave in "review" state    

  DR 250
    we think the Standard is correct (preprocessing directive includes
      non-directive)
    the term "preprocessing directive" should probably be italicized in
      paragraph 2 (6.10)
    the answer to Clive's question is "yes, it's a directive"
    [AI] Meyers: write footnote
    
  DR 252
    we don't want to work on non-prototyped functions
    [AI] Meyers: draft words that capture this intent (possible taken
      from response to DR 255
    full committee decided to "close" with these new words

  DR 253
    we agree with response but want to add to the response words that say
      "the initializations for x and y are different" (they are different 
      because of paragraph 21)
    full committee decided to "close" with these new words

    (aside) the term "designated initializer" is never mentioned in the 
    Standard though it appears in the index and new features section (we use
    the term "designation initializer" in the text)

  DR 255
    change wording to
      The Committee does not wish to further refine the behavior of calls
      not in the scope of prototypes.  In practice, this will not be a
      problem, and the Committee does not wish to define the behavior.
    note the emphasis on "calls"
    full committee decided to "close" with this change
    
  DR 257
    want to add "committee discussion" words that capture our thoughts on 
    each of these suggestions
      1) we agree with him but do not believe that this is a 
         defect in the Standard (or a substantive problem); there is some
         support for changing the example
      2) takes away the "visibility rule" and we don't want to do that;
         this is related to DR 236
      3) we agree with him but do not think a change is warranted at 
         this time
         [rev] we think we should consider this for a future rev of the
         Standard
      4) we think this should be a separate DR (and possibly a new
         footnote)
         [AI] Nelson: file new DR for this alone
    leave in "review" state

  DR 265
    we think the footnote text should be changed to read
      Thus on an implementation where INT_MAX is 0x7FFF and UINT_MAX is
      0xFFFF, the constant 0x8000 is signed and positive within a #if
      expression even though it is unsigned in translation phase 7.
    full committee decided to "close" with this change

  DR 269
    we agree with suggested resolution
    [rev] we think we should consider suggestion 2 (about unsigned types) 
      for a future rev of the Standard
    full committee decided to "close"

  DR 270
    we recommend adding Rationale words similar to
      It would be legal for an implementation to have wchar_t be either int
      or unsigned int and wint_t be either long or unsigned long.  The
      suggested changes would invalidate implementations currently allowed
      by the Standard that made those choices.

    [AI] Tydeman: draft Rationale words that say that wchar_t does not
      necessarily promote to wint_t
    full committee decided to "close"
    
  DR 271
    [rev] we think we should consider this for a future rev of the Standard
    full committee decided to "close"

  DR 277
    subcommittee was divided on whether they think the words can be misread
      the way Clive suggests; they agree that if they make a change, the 
      first suggested rewording is best

     ----------------------------------------
     [straw vote] should we make this change?
     ----------------------------------------
       yes  5
       no   8

    Wakker
      why don't we simply remove the restriction that disallows constants?
    Meyers
      this was an arbitrary language decision, C++ precedent is to disallow
        this
    Plum
      wasn't necessary in C++ since you can intermingle code and decls
        (which C has since adopted)
    Glassborow
      people are reluctant to change standard since it's costly BUT it is
        also costly if the standard isn't unambiguously clear

     full committee decided to "close"

13.3 DRs that were in the "open" state
       
  DR 245 
    we agree with the suggestions, except that 7.21.4.3 is incorrectly listed 
      as 7.21.4.4
    move to "review" state

  DR 275
    we think the macro should be defined as zero in this case (and cannot
      be left undefined)
    move to "review" state

  DR 279
    the original restriction came from Plauger and he now thinks restriction
      should be removed
    we recommend suggestion 2 (removing the restriction)
    move to "review" state

  DR 236
    we did not like the suggested example in the "committee discussion"
    we agreed that the Committee's original intent was to create aliasing
      rules to allow optimizations based on types; unions can create 
      "aliases" that break this
    we agreed that we wanted to fix these rules so that they can remain
      useful to optimizers
    we agreed that we want to move the Standard in the direction of "the
      visibility of the union at the point of the reference" is what matters 

    [AI] Meyers and Nelson: draft changes to the aliasing rules (and the
      definition of "effective type") so that optimizers can continue to
      use these rules to optimize programs

    Mak
      the discussion focused on example 2 (unions) and we also need to
        handle malloc'ed storage 
    Keaton
      no objection to invalidating some programs (with new rules), those
        programs were written in a problematic coding style (passing 
        function arguments that are aliased to one another)
    Plauger
      in favor of new rules, they will provide guidance to real programmers
      trying to write correct, optimizable code

    there should be a quick response that says that we don't like example
    leave in "open" state

    [additional discussion on DR 236 from subcommittee]

    Meyers
      at Digital, we took conservative approach and any union in scope
        stopped optimizations (since we could look at whole compilation unit
        all at once)
    Walls
      at Sun, there are command-line options to control aliasing assumptions
      the compiler is 1-pass and so a union wouldn't prohibit optimization 
        unless union was seen first
    Meyers
      the optimization in example 2 should not be allowed and it is not
	worth fixing the Standard to allow it
      aliasing rules are just heuristic, these optimizations are usually 
	put under control of command-line switches, it is inherently unsafe
	to write code like this
      if we make the suggested change, we would be starting an education
	process to teach people how to fix their programs and write them in
        such a way that they can be optimized fully
    Nelson
      effective type is not a concept that is applied to unions, it is only
	for dynamically allocated memory
      suggestion
	1) apply effective type concept to unions (e.g. assignment to a
           union member has the potential for changing the effective type)
	2) add new bullet to ANSI aliasing rules about "members of a visible
	   union type"
    Meyers
      another suggestion: restrict taking address of union member
    Nelson
      we might draft wording that touches
        1) 6.5p7 if you have 2 types which are members of a visible union
           type
        2) 6.5p6 effective type definition
        3) 6.2.6.1p7 when a value is stored into union member, other members
           become indeterminate
        4) 6.5.2.3p5 

    it was also suggested that we should put examples that we want to work
      and not work in the TR

  DR 219 (related to DR 236)
    we think that the resolution of this DR will make no practical difference
      to compiler writers
    Meyers suggested saying that if the memory being copied is a partial
      object then the effective type is array of char, if it is a full object
      that determines the effective type
    [AI] Meyers: write paper detailing this approach (for next meeting) and
      argue why we should dismiss the suggested approach
    leave in "open" state

14. Additional character types TR discussion review

  Nobu    
    how/when do we decide encoding (2.1, 2.4, 2.5)?
    we're now focused on 3 possible solutions (we've rejected UTF8 and UTF32)
    in what direction should we go?
    what shall we say to people who want to write encoding-dependent programs?
    100K people are writing that kind of code at SAP

  Benito
    to proceed, we need to register document, then circulate, then move
      it to PDTR

  Simonsen
    we're in early stages here, we cannot go to PDTR too quickly

  Benito
    Wakker's embedded C proposal took several years to move to PDTR

  Plauger
    is this a normative or informative change?

  Simonsen
    want more generic approach that would also accommodate UTF-16

  Nobu
    there could be a more generic approach using macros

      charU  => 1) char
                2) wchar_t
                3) char16_t
      strcmpU() => strcmp()
      cU("") => 1) ""
                2) L""
                3) u""
  Simonsen
    if we want to proceed along these lines we need a written proposal

  Benito
    [AI] Nobu: put type generic approach description on WG14 website (once
      he cleans the code) and forward to Benito to put in mailing

  Simonsen
    WG20 document 15434 I18N API
    generic API (not bound to Unicode)
    reentrant (thread safe), locale, codeset, repertoire, string
    supports new locale specification (14652), sort of a Posix enhancement
    partially implemented in gnu compiler

  Nobu
    ICU API is already widely used

  Simonsen
    ICU is bound to Unicode
    15434 is also widely used (in gnu compiler)

  Nobu
    15434 has missing pieces (strcmp, etc.)
    the targets of the 2 projects are different
    ICU is already implemented

  Simonsen
    15434 is also implemented (in gnu compiler)
    do we want to be generic or Unicode-bound?
    assume we want to be generic (EBCDIC, etc.)

  Nobu
    generic approach is nicer
    we should continue discussion

  Keaton
    we have clear committee position that we do not want to be character
      set specific (in the committee DR response to allow EBCDIC)

  Plum
    disagrees with assertion that somebody has asked for a Unicode-only
      environment
    the request will not affect char or wchar_t
    they are asking for a new name that would guarantee UTF-16 type
    if people want more generalized 16 bit type that's fine, the proponents
      of those encodings should come to as

  Nelson
    we have already hard-wired support for ISO 10646 into C
    suggestion: we can soft-wire support for UTF-16 by defining a macro that
      says whether or not the extensions are available; implementors would
      NOT be required to have them

  Plum
    this is just a technical report, not a part of the Standard
    as long as the source code can tell at compile-time whether or not 
      UTF-16 is supported, users could be satisfied

  Keaton
    likes soft-wired approach

  Plum
    there are complaints about wchar_t because there are no guarantees about
      either its size or encoding, wchar16_t guarantees at least the size
    supports use of upper and lower case u's to decorate strings

  Meyers
    prefers that typedef not say "utf" in it
    likes u (both upper and lower), we can think of it as "Universal" and
      the Unicode community can think it's "Unicode"

  Keaton
    we could use string creation macros and just blow off the prefix

  Plum
    what about adjacent string concatenation?

  Mak
    suggests "v" for variable-width encoding
    still has reservations about 32-bit, all we need is 16-bit

  Muller
    prefer separate macros for char16 and UTF (guaranteed to be UTF)

  Simonsen
    wants more generic literals

    Norwegian comments (submitted to convener and will be sent with ballot)

    1) good idea to support UTF-16 in C standard
    2) other encodings should be supported in portable, generic way
    3) cultural conventions registry should be included
    4) should be possible to create character constants in different encodings
    5) should be possible to determine whether or not something is really a
       constant or something intended for translation
    6) WG20 should be consulted

    Norwegian comments mailed to WG14 reflector

  Nelson
    comments 3 and 4 suggests that there should be syntax for specifying
      meta information about strings

  Simonsen
    Norwegian comments do not suggest that implementations need to support
      lots of encodings

  Mak
    would implementations be required to support more than one encoding in 
      the same compilation?

  Simonsen
    supporting more than one kind of string at the same time would be useful

  Plum
    by adding string prefix, we would make clear how other encodings could
      also be added as extensions
    C++ library group has been playing with how to extend string literals
      so that they could be user-defined encodings
    in Nobu's mid-preprocessor, it is important to know the context in 
      which the string appears; if initializer, for instance, it must 
      create static array with hex constants

  Nobu
    we MUST support UTF-16!
    SAP and C# people are demanding it

  Tydeman
    could use u followed by number and then pragmas to switch between
      16-bit encodings

  Meyers
    it would be rare for people to need more than one encoding in the same
      compilation unit
    people don't complain about this now, codes that require different
      character sets are simply compiled separately
    not a big deal to support more than one encoding at the same time, it
      could be done with techniques similar to the locale-changing techniques
      we have now (setlocale)
    we could use #pragmas to establish "current" locale

  Plum
    people who are asking for this TR were hoping that it could be done
      quickly, Norway 2-5 suggest much more complex work
    we should consider possibility that if we add char32_t that it is 
      defined to be ISO 10646 encoding
    people cannot use wchar_t for that purpose today because it isn't 
      guaranteed to be 16 bits (and isn't on Microsoft)

  Simonsen
    Norway simply wants better generic support
    should that be a separate TR?

  Meyers
    making this char set independent would not necessarily be that much
      of a burden

  Benito
    if we decide we want to do another TR to address the API issues that 
      would need to wait (we're small group)
    the way this new work item is written, we could write a very small TR to 
      handle char issues and then a much larger TR to handle the API issues

  Meyers
    if we set good direction, implementations need not wait for the 
      standardization process

  Simonsen
    Norway doesn't feel strongly about point 6, taking this to WG20

  Nobu
    I18N API was rejected elsewhere and now it's simply been shifted to WG14

  Wakker
    UTF-16 is the primary issue
    would like to see more flexible mechanism, that's a more difficult task
      and will take more time
    WG14 is not appropriate place to do I18N API work

  Kristoffersen
    favors a more generic approach
    UTF-16 is not stable

  Mak
    we should concentrate on data type and string literals, not API

  Plum
    I thought our charter says that we're not going to define APIs but we
       will look at and point to and describe APIs 

  Benito
    our charter is not worded that way

  Simonsen
    Norway would be fine with quick TR to get UTF-16, then longer more
      complex TR to get generic support

  Meyers
    don't believe that it would be difficult to write the 16-bit support
      in way that would make Unicode happy

  small group was put together to review revised TR
    Plum, Wakker, Plauger, Mak, Meyers, Simonsen, Muller, Nobu

  Simonsen
    let's task small group to respond to Norwegian comments (disposition of
      comments document)

  Wakker
    there were also comments from Japan, when will those be addressed?

  Benito
    we are waiting from reply/clarification from Nota-san

15.1 Future Meetings

  see 1.9 above

15.1.1 Future Meeting Schedule
15.1.2 Future Agenda Items

  generate press release (embedded TR, UTF-16 stuff, etc.)
  Simonsen and Benito volunteered to draft
  Keaton and Wakker volunteered to review
  more volunteers would be welcome

15.1.3 Future Mailings

  post Curacao 5/17
  pre Santa Cruz 9/20
  no paper mailings

16.2 Resolutions

16.2.1 Review of Decisions Reached

  All straw votes are marked [straw vote].

16.2.2 Formal Vote on Resolutions
 
  There was only one formal vote.  The discussion and details are in 
  section 12.

  Resolution: to instruct the WG14 convener to submit document WDTR 18037
  as amended for SC22 PDTR ballot as quickly as possible after this meeting.

    WG14 (7 present)
      in favor  6
      opposed   1
      abstain   0

16.2.3 Review of Action Items

  all action items are marked [AI]
  all items that we should consider in a future revision of the Standard
    are marked [rev]

16.2.4 Thanks to Host

16.3 Other Business

  we should republish when we issue a new Standard (and update the
    Standard number)

17. Adjournment
___________________________________________________________________________

2002-04-16  Embedded C minutes (day 1 of 3)

Attendees:
	Walter Banks, Bytecraft
	Allan Frederiksen, Nokia
	Francis Glassborow, Independent
	Barry Hedquist, Perennial
	David Keaton, Independent
	Jan Kristoffersen, Ramtex
	P.J. Plauger, Dinkumware
	Tana Plauger, Dinkumware
	Tom Plum, Plum Hall
	Willem Wakker, ACE

Topics to cover:
	Status of Document
	Fixed-Point
	Hardware I/O
	Address Spaces
	Annexes
	What to do with document after this meeting.

Key:  *A* means Action item; *D* means Decision.

Status of Document
	Changes from Redmond are highlighted.

Document Issues (fixed-point -- Willem):
	A number of editor's notes need to be addressed.
	Comments from Fred Tydeman (to be mentioned later).
	Introduction:  Jan:  Are all paragraphs necessary?
*D*		General agreement is to leave them in.
	2.1.3 Rounding
		Strike editor's note.
	Changes will be allowed after the coming ballott.
	2.1.4 Type Conversion/Usual Arithmetic Conversions
		Should the text go here or to the rationale?
		Willem feels its difference from usual C is important
		enough to put it here.
		Barry:  TR rules are more flexible than rules for a
		standard w.r.t. main text vs. rationale.
*D*		General agreement to keep text here.
	Changed names of types (fixed --> _Fixed).
*D*		General agreement to keep this.
	2.1.9 Formatted I/O
		What should the conversion specifiers be?
		R,r,Q,q were proposed to avoid three-letter
		specifiers.
		This makes format specifiers different from constant
		specifiers.
		Use of u in format specifiers could break existing
		programs that use %u, so it would have to be %qu and
		not %uq.
*D*		General agreement to use R,r,Q,q instead.
		Current proposal uses f style conversions as opposed
		to e or g.
*D*		General agreement that this is OK.
	2.1.10 viewing a value as a different type
		7.18.5.4 page 32
		What guaranteed-large-enough integer type should be
		used?
		Bill Plauger:  We should just have typedefs for
		integers of the right sizes.  To print them, just cast
		them to intmax_t.
		David:  intfract_t, intaccum_t, etc.
*A*		Willem will come up with a proposal.
		Does anyone need fixed-point to wide string
		conversion?  Probably not.
	2.2
		Page 19 parallels specification of floating-point
		types.
		Should we try to accommodate anything other than 2's
		complement types?
		Nobody could think of a non-2's complement fixed-point
		machine.
		David:  Fixed-point machines are recent, and recent
		machines are 2's complement.
*D*		General agreement to leave it 2's complement and let
		people complain if their ox is gored.

		First note on page 22 is to editor of C standard if
		this TR is eventually adopted into the standard.

		Second note -- pointer types?  Check C standard to
		make sure this is right.

		Page 23 note on type qualifiers.
		This is the point to introduce saturated integers if
		we want them.
*A*		The group agreed in Redmond not to have saturated
		integers, so Willem will remove this note.

		Page 36 conversions.
		Recommended practice in C std. 7.21.3.
		Willem suggests striking editor's note.

		Return value of conversion functions on overflow?
*D*		General agreement to use saturated result.

Document Issues (I/O HW -- Jan):
	John Hauser proposed a new method via e-mail.  He was not able
	to attend this meeting.
		Jan presented John's proposal.
		New concept:  base & index instead of addresses.
		John's proposal requires a memory instantiation for
		the access type because it passes pointers.  10-15%
		slower than macros.  Speed was the reason for the I/O
		HW effort.  Therefore, Jan suggests we not use John's
		proposal.  This would also avoid delaying the
		document.
		Some processors cannot even use a memory instantiation
		because the I/O address is encoded in the instruction.
		Jan likes some aspects of John's proposal and suggests
		we encourage John to put it in a more final form for
		next meeting, addressing Jan's issues, for possible
		substitution instead of the existing wording in the
		annex.
		Meanwhile, work will proceed on the document as it is,
		without delaying it.
	Annex C, p. 64
		Atomic operation -- not documented in normative part.
		Needs to be.
*A*		Jan will add normative words for atomic operation. (Done)

Document Issues (Address Spaces -- Walter):
	Status:  Walter's new document is not folded into the TR yet.
	There are various feelings about whether compatibility with
	existing C++ is required.
	Should #pragmas be used or should new keywords be introduced?
*A*	Walter will send out the latest draft of his proposal for
	the group's review. (Done)
	Walter:  Address space extensions could save hardware.  For
	example, currently extended address space on an 8051 requires
	external hardware.  Compiler address space extensions
	including call, return, etc. could eliminate that hardware.
	There is little need to have operations other than read and
	write for data objects.
	The I/O HW proposal could be used to access regions of strange
	types of memory, but would be missing the ability to use the
	compiler's symbol table management, type system, alignment,
	etc.
	The requirements for adapting C++ to handle address spaces
	have not yet been examined.
	Worst case seen so far:  Walter is working on a C compiler for
	a new processor that has 7 address spaces.
*A*	Willem, Jan, and Walter will flesh out a more detailed
	proposal for later this week. (Done)

Annexes
*A*	David will continue the old action item of documenting the
	proposal that was rejected at Redmond for the rationale.
	Preferred by May 1, when Willem goes on vacation for 3.5
	weeks.
	Fred Tydeman suggested rationale wording indicating that we
	considered BCD and decided not to do it.
*A*	Walter will write this up.
*A*	Tom Plum will talk to John Hauser about collaborating on a C++
	compatibility header for annex G.
*D*	For the time being, annex G will be left as is in anticipation
	of further elaboration.

2002-04-17  Embedded C minutes (day 2 of 3)

Willem distributed a revised TR with Walter's address space updates
included.  We collectively went through the result.
	There was some debate over the inclusion of "register" memory
	spaces in the TR.  Some people had seen several cases where
	this would be needed; others wanted it moved to the annex.
	Walter will consider this further.

	Walter:  Should we suggest naming conventions for memory
	spaces?  Something to think about.

	Should #pragma be used or should another way be found?
*D*	General agreement that #pragma should be used as currently in
	the document.

	Allan noted that we agreed in Copenhagen that -1*-1 could
	yield FRACT_MAX, but this does not yet appear in section 2.
	Division of FRACT_MIN or ACCUM_MIN by -1 has the same
	problem.
*A*	Willem will add this.

	Willem asked an independent observer to review the document.
	One point that resulted was that sometimes one might want to
	multiply 100*0.5r and get an integer 50.  The other was that
	it makes little sense to add and subtract integers with
	fracts.

	Willem hopes to send out the next document revision before May
	1 to make it in time for the next plenary ballot.

2002-04-18  Embedded C minutes (day 3 of 3)

Annex G, C++ compatibility
	Bill:  The example can be done with templates without
	expanding all 1200 possbilities.

---------------------------------------------------------------------------

                    Minutes for J11/U.S. TAG Meeting 
                            April 17, 2002

  Randy Meyers, presiding

  1) Debbie Donovan at INCITS would like the names of people work will work
     on the new TR for characters (Walls)

    Benito 
      there's no advantage in US doing that
      let's just say US TAG and move on
    Walls
      if we had a lead individual that might be enough
    Meyers volunteers to lead 

  2) liaison request (Benito)

    Farance would like to see J11 have a formal liaison with INCITS M1
      (biometrics), he would like to be that liaison 
    [AI] Meyers: will contact Farance and appoint him as our informal liaison

  3) Farance request for additional type (Benito)

    is there any interest in WG14 producing a TR on IEEE 1596.5?
      (Shared Data Formats for Optimized Scalable Coherent Interface)

    The rationale for wanting this work to start was sent by Benito
    after the meeting:

    "This work gives a user standardized datatypes (actually, typedefs) that
    address byte ordering (little, big), alignment (aligned or not), and
    representation (e.g., 2s complement, unsigned).  Some of these types are

	    LittleSignedByte (8-bits)
	    AlignedLittleSignedDoublet (little-endian, 16-bits, aligned)
	    AlignedLittleSignedQuadlet (little-endian, 32-bits, aligned)

    The reason for considering these kind of typedefs is: (1) they permit
    the precise layout, endianness, alignment, and representation on the
    common arithmetic types, (2) this certainty of layout is important for
    network-centric programming, processinging portable file formats, and
    shared-memory applications."

    Keaton
      if that group was in ISO we would eventually be required to bind to
        them in some way
    Meyers
      is there is a vendor that is actually going to do this?

    no support for adding this at this time

  4) Adjournment 4:34 PM