<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=WordSection1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#365F91'>One candidate for </span><tt><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#365F91'>CANNOT_CONTINUE would be a
data corruption in MPI memory or some data structure inconsistency due to a bug.
This could have zero effect or could corrupt application results or system
state. It would be exceedingly difficult for MPI to do anything meaningful here
and continued operation is potentially very dangerous. As such, I would
consider this to be a bad enough error to return CANNOT_CONTINUE. <o:p></o:p></span></tt></p>

<p class=MsoNormal><tt><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#365F91'><o:p> </o:p></span></tt></p>

<p class=MsoNormal><tt><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#365F91'>I think the point of this proposal is not that CANNOT_CONTINUE
is going to be a common error but to lay the groundwork for a more useful error
reporting scheme. Today we’re quite sure that CANNOT_CONTINUE will be the
worst thing that an MPI implementation will want to return but we’re not
really sure about what the other errors will look like. For example, RANK_DEAD
and LINK_DEAD sound like plausible error messages but we won’t know until
individual implementations have had a chance to experiment them. This proposal allows
such experimentation to happen within the same basic error reporting framework.<o:p></o:p></span></tt></p>

<p class=MsoNormal><tt><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#365F91'><o:p> </o:p></span></tt></p>

<p class=MsoNormal><tt><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#365F91'>Having said that, I’m not completely convinced that we
need to include this in the spec yet or whether this can be more like a
community agreement until we understand the problem better.</span></tt><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#365F91'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Greg Bronevetsky<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Lawrence Livermore National Lab<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(925) 424-5756<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>bronevetsky@llnl.gov<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>http://greg.bronevetsky.com <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mpi3-ft-bounces@lists.mpi-forum.org
[mailto:mpi3-ft-bounces@lists.mpi-forum.org] <b>On Behalf Of </b>Richard
Treumann<br>
<b>Sent:</b> Wednesday, September 22, 2010 11:17 AM<br>
<b>To:</b> MPI 3.0 Fault Tolerance and Dynamic Process Control working Group<br>
<b>Subject:</b> Re: [Mpi3-ft] Defining the state of MPI after an error<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Darius </span><br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>I can imagine a
few errors that I know will be harmless to MPI state. I can make sure nobody
can do any harm by passing an invalid communicator to MPI_COMM_SIZE.</span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>I cannot think
of a detectable error that would return and leave that thread of that process
so totally broken that nothing in MPI will work from then on. In a collective,
there may be processes in which the thread that called the CC never returns and
that tread of the process is no longer usable because it is hung.  Other
threads using other communicators in the process with a hung thread may work
perfectly.</span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Except for the
very few cases where I know there was no damage (like a bad comm on
MPI_COMM_SIZE) the situation, 99.99% of the time, will be that everything still
works but sometimes the outcome is a surprise to the user.  Say you
 do:</span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>1 MPI_Barrier
(on world)</span> <br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>2 MPI_Barrier
(on world):</span> <br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>3 other stuff </span><br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>4 MPI_Barrier
(on world)</span> <br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>5 if (my rank
is even)</span> <br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>6    
 sendrecv(with odd neighbor)</span> <br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>7  else </span><br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>8    
sendrecv(with even neighbor)</span> <br>
<br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>but get back an
error at  all even numbered ranks from the line 1 barrier call. The line 2
MPI_Barrier may still "work" but the line 2 barrier at even numbered
ranks will match the line 1 barrier at odd ranks. Even ranks will begin
"other stuff" and odd ranks will sit in the line 2 barrier until even
ranks  finish "other stuff" and reach the line 4 barrier. The
odd ranks now get through their line 2 barrier and begin other stuff.</span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>If "other
stuff" involves communication among  the even ranks and communication
among the odd ranks. that will work too. The even ranks will all send/recv
among themselves later the odd ranks will all send/recv among themselves.</span>
<br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>The even ranks will
reach line 6 and hang there because the odd tasks are still stuck at line 4.
 </span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>In this entire
example, libmpi has continued working "correctly" but the behavior
you get from correct behavior is not what you planned.   </span><br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>The situation
of MPI state being totally trashed by an error that returns a return code
barely exists.  The case where it is subtly discombobulated is the norm.</span>
<br>
<br>
<br>
<br>
<br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Dick Treumann
 -  MPI Team           <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
</span><br>
<br>
<o:p></o:p></p>

<table class=MsoNormalTable border=0 cellpadding=0 width="100%"
 style='width:100.0%'>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
  color:#5F5F5F'>From:</span> <o:p></o:p></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Darius
  Buntinas <buntinas@mcs.anl.gov></span> <o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
  color:#5F5F5F'>To:</span> <o:p></o:p></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>"MPI
  3.0 Fault Tolerance and Dynamic Process Control working Group"
  <mpi3-ft@lists.mpi-forum.org></span> <o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
  color:#5F5F5F'>Date:</span> <o:p></o:p></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>09/22/2010
  12:24 PM</span> <o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
  color:#5F5F5F'>Subject:</span> <o:p></o:p></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Re:
  [Mpi3-ft] Defining the state of MPI after an error</span> <o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
  color:#5F5F5F'>Sent by:</span> <o:p></o:p></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>mpi3-ft-bounces@lists.mpi-forum.org</span><o:p></o:p></p>
  </td>
 </tr>
</table>

<p class=MsoNormal><o:p> </o:p></p>

<div class=MsoNormal align=center style='text-align:center'>

<hr size=2 width="100%" noshade style='color:#ACA899' align=center>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt>OK, I (think I) see what you guys are saying, so maybe we should look at it
this way.  The CANNOT_CONTINUE proposal should not define the operation of
the MPI implementation after errors other than CANNOT_CONTINUE.  Instead,
it defines that after the implementation gives a CANNOT_CONTINUE error, the app
knows that the implementation is fatally wedged, and that the user should
definately not expect correct operation after this.  I.e., we're not
labeling other errors as "recoverable," we're just marking
CANNOT_CONTINUE as "unrecoverable."</tt><br>
<br>
<tt>Note that an implementation can still be standard compliant even if it
never returns a CANNOT_CONTINUE error even when it is fatally wedged (because
operation after any other error is still undefined).</tt><br>
<br>
<tt>This just defines a way for the implementation to let the user know that it
has given up.  So that if the implementation provides best-effort
functionality after an error, and the user has "read the disclaimer"
and is comfortable with proceeding, this is a way to differentiate between an
error as a result of a failure that hosed everything, and one that may allow
things to continue.</tt><br>
<br>
<tt>We still would like to define what happens to a bcast after a process in
the communicator fails.  But we leave that for future proposals.</tt><br>
<br>
<tt>Does this make sense?</tt><br>
<tt>-d</tt><br>
<br>
<tt>On Sep 22, 2010, at 8:43 AM, Terry Dontje wrote:</tt><br>
<br>
<tt>> Richard Treumann wrote:</tt><br>
<tt>>> </tt><br>
<tt>>> This proposal is not a minor change. </tt><br>
<tt>>> </tt><br>
<tt>>> Please do not make this hole in the standard and assume you can
later add language to standardize everything that comes through the hole. </tt><br>
<tt>>> </tt><br>
<tt>>> If the standard is to introduce the notion of a recoverable error
it must be as part of a full description of what "recovery" means.
  </tt><br>
<tt>>> </tt><br>
<tt>>> I think is is dangerous and ultimately useless to have
implementors mark a failure as "recoverable" when the post error
state of the distributed MPI has gone from "fully standards compliant"
to "mostly standards compliant, read my user doc read my legal disclaimer,
cross your fingers". </tt><br>
<tt>>> </tt><br>
<tt>>> See comment below for why I do not think the new hole is needed to
allow people to do implementation specific recoverability. </tt><br>
<tt>>> </tt><br>
<tt>>> There is not even anything to prevent on implementation from
deciding to add a function MPXX_WHAT_STILL_WORKS(err_code, answer) and
documenting 5 or 5000 enumerated values for "answer" ranging from
NOTHING through TAKE_A_CHANCE_IF_YOU_LIKE to  EVERYTHING. </tt><br>
<tt>>> </tt><br>
<tt>>> IBM would probably return TAKE_A_CHANCE_IF_YOU_LIKE because I
cannot imagine how we would promise exactly what will work and what will not
but in practice most things will still work as expected. </tt><br>
<tt>>> </tt><br>
<tt>> I think I agree with Dick on the above.  Another way of putting
the disagreement is that Josh's proposal is too general in that not all
errorcodes can be completely marked as MPI state is broken or not.  When
Sun implemented fault tolerant client/server we came up with a new error class
that when returned gave the user the understanding that a condition occurred on
a communicator that has rendered the communicator useless and one should clean
it up before continuing on.  The point is there was a concrete
understanding of the error and what could be done to recover.  As opposed
to a general class that say's everything is borked or not which essential
doesn't give you much because you'll end up eventually having to define a more
specific class of error IMO.</tt><br>
<tt>> </tt><br>
<tt>> --td</tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> Dick Treumann  -  MPI Team        
  </tt><br>
<tt>>> IBM Systems & Technology Group</tt><br>
<tt>>> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601</tt><br>
<tt>>> Tele (845) 433-7846         Fax (845) 433-8363</tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> mpi3-ft-bounces@lists.mpi-forum.org wrote on 09/21/2010 04:54:08
PM:</tt><br>
<tt>>> </tt><br>
<tt>>> > [image removed] </tt><br>
<tt>>> > </tt><br>
<tt>>> > Re: [Mpi3-ft] Defining the state of MPI after an error </tt><br>
<tt>>> > </tt><br>
<tt>>> > Bronis R. de Supinski </tt><br>
<tt>>> > </tt><br>
<tt>>> > to: </tt><br>
<tt>>> > </tt><br>
<tt>>> > MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group </tt><br>
<tt>>> > </tt><br>
<tt>>> > 09/21/2010 04:59 PM </tt><br>
<tt>>> > </tt><br>
<tt>>> > Sent by: </tt><br>
<tt>>> > </tt><br>
<tt>>> > mpi3-ft-bounces@lists.mpi-forum.org </tt><br>
<tt>>> > </tt><br>
<tt>>> > Please respond to "Bronis R. de Supinski",
"MPI 3.0 Fault Tolerance </tt><br>
<tt>>> > and Dynamic Process Control working Group" </tt><br>
<tt>>> > </tt><br>
<tt>>> > </tt><br>
<tt>>> > Dick:</tt><br>
<tt>>> > </tt><br>
<tt>>> > Re:</tt><br>
<tt>>> > > The current MPI standard does not say the MPI
implementation is totally </tt><br>
<tt>>> > > broken once there is an error.  Saying MPI state is
undefined after an </tt><br>
<tt>>> > > error simply says that the detailed semantic of the MPI
standard can no </tt><br>
<tt>>> > > longer be promised. In other words, after an error you
leave behind the </tt><br>
<tt>>> > > security of a portable standard semantic.  You are
operating at your own </tt><br>
<tt>>> > > risk. You do not need to read more than that into it.</tt><br>
<tt>>> > </tt><br>
<tt>>> > Perhaps my problem with this position is that I come from the</tt><br>
<tt>>> > background of language definitions for compilers. When you</tt><br>
<tt>>> > read "undefined" in the OpenMP specification then
you are</tt><br>
<tt>>> > being told that things are broken and the implementation does</tt><br>
<tt>>> > need to do anything or even tell you what they actually do
(and</tt><br>
<tt>>> > I believe the same is true for the C and C++ standards). An</tt><br>
<tt>>> > alternative is "implementation defined", which
requires the</tt><br>
<tt>>> > implementer to document what they actually do. Without that,</tt><br>
<tt>>> > you cannot even rely on actions with a specific
implementation</tt><br>
<tt>>> > (unless you believe "My tests so far have not failed so
I am OK").</tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> When a standard says behavior is "undefined" in some
situation, it cannot mean behavior is "broken". It cannot mean the
implementor is prohibited from making it still work. It cannot mean the
implementor is prohibited from making certain things work and documenting them.
Any statement like this in a standard would be definition of behavior and the
behavior would no longer be "undefined".   </tt><br>
<tt>>> </tt><br>
<tt>>> The only thing a standard can logically mean by
"undefined" is that the STANDARD no longer mandates the definition. </tt><br>
<tt>>> </tt><br>
<tt>>> Bronis says: </tt><br>
<tt>>> </tt><br>
<tt>>> > </tt><br>
<tt>>> > I strongly feel "undefined" should be reserved for
situations that</tt><br>
<tt>>> > mean "your program is irrevocably broken and the
implementer does</tt><br>
<tt>>> > not need to worry about what happens to it after encountering
them." </tt><br>
<tt>>> </tt><br>
<tt>>> I would say this as: </tt><br>
<tt>>> </tt><br>
<tt>>> I strongly feel "undefined" should be reserved for
situations that mean "The standard no longer guarantees your program is
not irrevocably broken. The implementer is not required by the standard to
worry about what happens to it after encountering them. An Implementation is
free to provide any "better" behavior that may be of value but users
cannot assume another implementation provides similar behavior so cannot assume
standards defined portability." </tt><br>
<tt>>> </tt><br>
<tt>>> I do not see how the use if the word "undefined" in a
standard can be interpreted as a prohibition of any behavior an implementation
might offer. </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>>  </tt><br>
<tt>>> </tt><br>
<tt>>> _______________________________________________</tt><br>
<tt>>> mpi3-ft mailing list</tt><br>
<tt>>> </tt><br>
<tt>>> mpi3-ft@lists.mpi-forum.org</tt><br>
<tt>>> </tt></span><a
href="http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><span
style='font-size:10.0pt'>http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</span></tt></a><span
style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt>>> </tt><br>
<tt>>>   </tt><br>
<tt>>> </tt><br>
<tt>> </tt><br>
<tt>> </tt><br>
<tt>> -- </tt><br>
<tt>> <Mail Attachment.gif></tt><br>
<tt>> Terry D. Dontje | Principal Software Engineer</tt><br>
<tt>> Developer Tools Engineering | +1.781.442.2631</tt><br>
<tt>> Oracle - Performance Technologies</tt><br>
<tt>> 95 Network Drive, Burlington, MA 01803</tt><br>
<tt>> Email terry.dontje@oracle.com</tt><br>
<tt>> </tt><br>
<tt>> _______________________________________________</tt><br>
<tt>> mpi3-ft mailing list</tt><br>
<tt>> mpi3-ft@lists.mpi-forum.org</tt><br>
<tt>> </tt></span><a
href="http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><span
style='font-size:10.0pt'>http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</span></tt></a><span
style='font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<br>
<tt>_______________________________________________</tt><br>
<tt>mpi3-ft mailing list</tt><br>
<tt>mpi3-ft@lists.mpi-forum.org</tt><br>
</span><a href="http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><span
style='font-size:10.0pt'>http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</span></tt></a><span
style='font-size:10.0pt;font-family:"Courier New"'><br>
<br>
</span><o:p></o:p></p>

</div>

</div>

</body>

</html>