<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for ScapeCode</title>
	<atom:link href="http://scapecode.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://scapecode.com</link>
	<description>Anime, tentacles, and software development.</description>
	<lastBuildDate>Thu, 08 Oct 2009 06:05:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>Comment on A Simple C++ Quiz by Washu</title>
		<link>http://scapecode.com/2009/10/a-simple-c-quiz/comment-page-1/#comment-2</link>
		<dc:creator>Washu</dc:creator>
		<pubDate>Thu, 08 Oct 2009 06:05:04 +0000</pubDate>
		<guid isPermaLink="false">http://scapecode.com/?p=107#comment-2</guid>
		<description>&lt;p&gt;1.1 – No, it is undefined behavior as the only allowable range for pointers derived from &lt;code&gt;p&lt;/code&gt; is &lt;code&gt;[p, p + 10]&lt;/code&gt;.&lt;/code&gt; &lt;/p&gt;

&lt;p&gt;1.2 – Since the behavior is undefined, this is meaningless&lt;/p&gt;

&lt;p&gt;1.3 – Comparison between other pointers derived from &lt;code&gt;p&lt;/code&gt;. Decrement and subtraction by any value that would keep &lt;code&gt;k&lt;/code&gt; within &lt;code&gt;[p, p + 10]&lt;/code&gt;. Subtraction between &lt;code&gt;k&lt;/code&gt; and any other pointer derived from &lt;code&gt;p&lt;/code&gt; to obtain a &lt;code&gt;ptrdiff_t.&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;2. Undefined behavior. Due to &lt;code&gt;a&lt;/code&gt; being a scalar type, and the lack of sequence points present, along with the fact that function parameters are evaluated in an unspecified order (but are guaranteed to be evaluated prior to the function call), &lt;code&gt;a&lt;/code&gt; will be modified more than once between sequence points. This results in undefined behavior per the standard.&lt;/p&gt;

&lt;p&gt;3. the &lt;code&gt;, operator&lt;/code&gt; will evaluate its arguments from left to right, returning the result of the rightmost expression. As such the parameters passed to &lt;code&gt;f&lt;/code&gt; are: &lt;code&gt;c&lt;/code&gt;, &lt;code&gt;d&lt;/code&gt;, &lt;code&gt;e&lt;/code&gt;, and &lt;code&gt;i&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;4. There is a potential for the first or second new to be called, and then the alternate new to throw an exception, causing a leak. Also, there may be construction order dependencies between &lt;code&gt;A&lt;/code&gt; and &lt;code&gt;B&lt;/code&gt;, and due to the implementation defined order in which function parameters are evaluated, that dependency could be violated. There is the potential for leakage from &lt;code&gt;f&lt;/code&gt;, although that’s a non-issue since we appear to be transferring ownership of the pointer to &lt;code&gt;f&lt;/code&gt;.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>1.1 – No, it is undefined behavior as the only allowable range for pointers derived from <code>p</code> is <code>[p, p + 10]</code>. </p>
<p>1.2 – Since the behavior is undefined, this is meaningless</p>
<p>1.3 – Comparison between other pointers derived from <code>p</code>. Decrement and subtraction by any value that would keep <code>k</code> within <code>[p, p + 10]</code>. Subtraction between <code>k</code> and any other pointer derived from <code>p</code> to obtain a <code>ptrdiff_t.</code></p>
<p>2. Undefined behavior. Due to <code>a</code> being a scalar type, and the lack of sequence points present, along with the fact that function parameters are evaluated in an unspecified order (but are guaranteed to be evaluated prior to the function call), <code>a</code> will be modified more than once between sequence points. This results in undefined behavior per the standard.</p>
<p>3. the <code>, operator</code> will evaluate its arguments from left to right, returning the result of the rightmost expression. As such the parameters passed to <code>f</code> are: <code>c</code>, <code>d</code>, <code>e</code>, and <code>i</code>.</p>
<p>4. There is a potential for the first or second new to be called, and then the alternate new to throw an exception, causing a leak. Also, there may be construction order dependencies between <code>A</code> and <code>B</code>, and due to the implementation defined order in which function parameters are evaluated, that dependency could be violated. There is the potential for leakage from <code>f</code>, although that’s a non-issue since we appear to be transferring ownership of the pointer to <code>f</code>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
