<div dir="ltr">Does libfabric assume C99?  MSVC is not a C99 compiler and never will be, according to every source I've ever seen (e.g. <a href="http://stackoverflow.com/questions/9610747/which-c99-features-are-available-in-the-ms-visual-studio-compiler">http://stackoverflow.com/questions/9610747/which-c99-features-are-available-in-the-ms-visual-studio-compiler</a>, which links to MSFT docs that I cannot access).<div><br></div><div>Of course, Intel and others support a C99 compiler for Windows, but if Windows support implies supporting the platform's default compiler, then we need to worry about what MSVC supports.  Perhaps there is some automatic hook for Intel compilers in Visual Studio that mitigates the ISO shortcomings of MSVC.  Clang may also be an option (<a href="http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/">http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/</a>).</div><div><br></div><div>Given the choice between limiting libfabric to a subset of C99 and not supporting Windows, I vote for C99 100 times out of 100.</div><div><br></div><div>Best,<br><br>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 10:57 AM, Jeff Squyres (jsquyres) <span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Jan 8, 2016, at 1:15 PM, Hefty, Sean <<a href="mailto:sean.hefty@intel.com">sean.hefty@intel.com</a>> wrote:<br>
><br>
> As a discussion item for the next ofiwg, the topic has come up (again) about supporting other operating systems, specifically Windows and Solaris.<br>
<br>
</span>I would imagine that supporting Solaris with the configury/build/sockets providers wouldn't be too difficult...?<br>
<br>
I don't know much about Windows to comment on it.<br>
<span class=""><br>
> At least two development teams have asked about support outside of Linux.  The desire is to code only to libfabric, with it dealing with differences in the underlying interfaces.  This is partially driven by the socket provider support inside libfabric, which allows for applications to remove their support for sockets.<br>
><br>
> This in turn is driving the need for the sockets provider to focus on performance and scalability, rather than just functionality, which was the original goal.<br>
<br>
</span>Is it worth forking the sockets provider -- one for "simple" correctness (and not performance), and another optimized provider for sockets?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
ofiwg mailing list<br>
<a href="mailto:ofiwg@lists.openfabrics.org">ofiwg@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofiwg" rel="noreferrer" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>