<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>No Content, No Fuss: C2K5 thoughts</title>
    <link>http://anil.recoil.org/blog/articles/2005/06/04/c2k5-thoughts</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>Anil Madhavapeddy</description>
    <item>
      <title>C2K5 thoughts</title>
      <description>&lt;p&gt;
Finally had some time to get back from the OpenBSD hackathon and take stock of what I worked on.  It was pretty interesting one this year, as I went without having much idea of what to work on (unlike last year, when I had a mad backlog to catch up on).   Some stuff I did during the week included:
&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Clean up the &lt;a href="http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/usr.bin/ssh/atomicio.c"&gt;atomicio&lt;/a&gt; interface used in &lt;a href="http://www.openssh.com"&gt;OpenSSH&lt;/a&gt; and &lt;i&gt;&lt;a href="http://www.openbsd.org/cgi-bin/man.cgi?query=nc"&gt;nc(1)&lt;/a&gt;&lt;/i&gt; to provide simpler semantics.  Error checking from read/write functions are a real headache in C, as the functions return &lt;tt&gt;-1&lt;/tt&gt; on error, which means a signed &lt;tt&gt;ssize_t&lt;/tt&gt; is returned.  However, they accept an unsigned value as the size of the buffer to process, which means they could potentially return a value outside the range of the return value.  This means you have to check if the return is &lt;tt&gt;-1&lt;/tt&gt;, which indicates an error, and otherwise cast to a &lt;tt&gt;size_t&lt;/tt&gt; to correctly get the buffer size back.  With the new atomicio, it always returns a &lt;tt&gt;size_t&lt;/tt&gt;, and returns &lt;tt&gt;0&lt;/tt&gt; to signal an error (with &lt;tt&gt;errno&lt;/tt&gt; containing the error, and &lt;tt&gt;EPIPE&lt;/tt&gt; being set for an &lt;tt&gt;EOF&lt;/tt&gt; condition).&lt;/li&gt;
&lt;li&gt;Start looking at the Bluetooth stack to get L2CAP and RFCOMM support.  We are half-way through un-netgraphing the FreeBSD stack and having a more traditional &lt;tt&gt;netbt&lt;/tt&gt; socket interface (much like &lt;tt&gt;netinet&lt;/tt&gt; or &lt;tt&gt;netinet6&lt;/tt&gt;) to Bluetooth.&lt;/li&gt;
&lt;li&gt;Use &lt;a href="http://cil.sf.net/"&gt;CIL&lt;/a&gt; to implement a few fun kernel source-&gt;source transforms.  &lt;tt&gt;&lt;a href="http://www.openbsd.org/cgi-bin/cvsweb.cgi/ports/devel/cil/files/kerneltrace.ml"&gt;kerneltrace&lt;/a&gt;&lt;/tt&gt; just accepts a regular expression and inserts a &lt;tt&gt;printf&lt;/tt&gt; in the function prologue which outputs the function name and any arguments passed into it.  Had this idea when chatting with &lt;a href="http://www.monkey.org/~marius/"&gt;Marius&lt;/a&gt;, and it turned out to be very useful when trying to figure out dataflow in the Bluetooth stack (just compile with &lt;tt&gt;make CC="/usr/local/bin/cilly --dokerneltrace --trace-regexp='ubt|ng_blue'"&lt;/tt&gt;).
The second one was even simpler; &lt;tt&gt;&lt;a href="http://www.openbsd.org/cgi-bin/cvsweb.cgi/ports/devel/cil/files/randomvars.ml"&gt;randomvars&lt;/a&gt;&lt;/tt&gt; assigns a non-zero value to every local variable in a function call to help track down uninitialized-local-variable bugs. Heres &lt;a href="http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/usr.bin/mg/search.c.diff?r1=1.15&amp;amp;r2=1.16"&gt;one&lt;/a&gt; Chad Loder found in &lt;i&gt;&lt;a href="http://www.openbsd.org/cgi-bin/man.cgi?query=mg"&gt;mg(1)&lt;/a&gt;&lt;/i&gt;.&lt;/li&gt;
&lt;li&gt;Other random &lt;a href="http://marc.theaimsgroup.com/?l=openbsd-cvs&amp;amp;m=111689009724884&amp;amp;w=2"&gt;signed/unsigned cleanups&lt;/a&gt; in OpenSSH.  Boring but important I guess...&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;All in all, the hackathon re-motivated me to continue work on the OCaml-based daemons that &lt;a href="http://recoil.org/~djs/"&gt;Dave&lt;/a&gt; and I have been hacking on.  I don't want to be fixing random buffer or integer overflows  in an OpenBSD hackathon 5 years from now; we need to move on to more high-level issues.&lt;/p&gt;</description>
      <pubDate>Sat, 04 Jun 2005 16:14:18 +0100</pubDate>
      <guid isPermaLink="false">urn:uuid:bda198f9-42f3-42c8-8742-4ad90f30c8fd</guid>
      <author>avsm</author>
      <link>http://anil.recoil.org/blog/articles/2005/06/04/c2k5-thoughts</link>
      <category>hacking</category>
      <category>openbsd</category>
    </item>
  </channel>
</rss>
