<?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 on: ISO/IEC 9899:1999 (E) § 6.7.5.3.7</title>
	<atom:link href="http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/</link>
	<description>a lowercase manifesto</description>
	<lastBuildDate>Mon, 12 Sep 2011 11:31:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Julian Stecklina</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-365</link>
		<dc:creator>Julian Stecklina</dc:creator>
		<pubDate>Fri, 21 Sep 2007 21:37:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-365</guid>
		<description>Another &quot;misfeature&quot; in the Core language is this:

int main()
{
 int i = 0;
 {
   int i = i + 1;
   printf(&quot;%d\n&quot;, i);
 }
 return 0;
}

Does another language have such broken scoping rules?</description>
		<content:encoded><![CDATA[<p>Another &#8220;misfeature&#8221; in the Core language is this:</p>
<p>int main()<br />
{<br />
 int i = 0;<br />
 {<br />
   int i = i + 1;<br />
   printf(&#8220;%d\n&#8221;, i);<br />
 }<br />
 return 0;<br />
}</p>
<p>Does another language have such broken scoping rules?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: behdad</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-351</link>
		<dc:creator>behdad</dc:creator>
		<pubDate>Tue, 11 Sep 2007 02:19:03 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-351</guid>
		<description>Indeed, the &quot;pass by reference&quot; trick:

http://mces.blogspot.com/2005/08/pass-by-reference-in-c.html

I got to find this by trying to figure out how setjmp() is implemented as a function...

If you need to pass it that bad, stuff the array in a struct.  It&#039;s typically a very bad idea to typedef an array, and the only useful case I&#039;ve seen of it this very jmp_buf and va_list kind of types...</description>
		<content:encoded><![CDATA[<p>Indeed, the &#8220;pass by reference&#8221; trick:</p>
<p><a href="http://mces.blogspot.com/2005/08/pass-by-reference-in-c.html" rel="nofollow">http://mces.blogspot.com/2005/08/pass-by-reference-in-c.html</a></p>
<p>I got to find this by trying to figure out how setjmp() is implemented as a function&#8230;</p>
<p>If you need to pass it that bad, stuff the array in a struct.  It&#8217;s typically a very bad idea to typedef an array, and the only useful case I&#8217;ve seen of it this very jmp_buf and va_list kind of types&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Swfblag &#187; Blog Archive &#187; Thank you</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-310</link>
		<dc:creator>Swfblag &#187; Blog Archive &#187; Thank you</dc:creator>
		<pubDate>Fri, 24 Aug 2007 23:42:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-310</guid>
		<description>[...] Ryan for dvalue. And for knowing all this stuff about C. [...]</description>
		<content:encoded><![CDATA[<p>[...] Ryan for dvalue. And for knowing all this stuff about C. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: desrt</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-290</link>
		<dc:creator>desrt</dc:creator>
		<pubDate>Thu, 23 Aug 2007 17:36:20 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-290</guid>
		<description>evil *x is int (*x)[1].

int (*x)[1] is a pointer to an array (ie: the pointer points at the first element of the array).

int **x is a pointer to a pointer to an array (ie: the pointer points at a pointer that points at the first element of the array).</description>
		<content:encoded><![CDATA[<p>evil *x is int (*x)[1].</p>
<p>int (*x)[1] is a pointer to an array (ie: the pointer points at the first element of the array).</p>
<p>int **x is a pointer to a pointer to an array (ie: the pointer points at a pointer that points at the first element of the array).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Walter</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-289</link>
		<dc:creator>Steven Walter</dc:creator>
		<pubDate>Thu, 23 Aug 2007 17:33:29 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-289</guid>
		<description>I&#039;m not convinced that the &quot;obvious&quot; solution is wrong.  &quot;the code is very clearly in error (since x is already a pointer).&quot;  There&#039;s nothing wrong with using the address-of operator on a pointer.  It seems to me that the type would even work out, because takes_evil_ptr would expect evil *, i.e. int **, no?</description>
		<content:encoded><![CDATA[<p>I&#8217;m not convinced that the &#8220;obvious&#8221; solution is wrong.  &#8220;the code is very clearly in error (since x is already a pointer).&#8221;  There&#8217;s nothing wrong with using the address-of operator on a pointer.  It seems to me that the type would even work out, because takes_evil_ptr would expect evil *, i.e. int **, no?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Henstridge</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-288</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Thu, 23 Aug 2007 03:04:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-288</guid>
		<description>Sean: the typedef Ryan is complaining about was not defined by him: va_list is defined by the C standard, but its type is not.  Further more, it actually is defined differently on different platforms.  It could be a pointer, array or something else.

If the aim is to copy a va_list and you&#039;re using glib, G_VA_COPY() is the best option.</description>
		<content:encoded><![CDATA[<p>Sean: the typedef Ryan is complaining about was not defined by him: va_list is defined by the C standard, but its type is not.  Further more, it actually is defined differently on different platforms.  It could be a pointer, array or something else.</p>
<p>If the aim is to copy a va_list and you&#8217;re using glib, G_VA_COPY() is the best option.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-287</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Thu, 23 Aug 2007 01:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-287</guid>
		<description>This isn&#039;t a bug in C or a misfeature, really.  It&#039;s (to put bluntly) you misusing typedefs.  Typedefs do not define new types.  They merely provide an alias.  For the most part (not entirely, of course) the two following lines of C code are equivalent:

typedef foo bar;

#define bar foo</description>
		<content:encoded><![CDATA[<p>This isn&#8217;t a bug in C or a misfeature, really.  It&#8217;s (to put bluntly) you misusing typedefs.  Typedefs do not define new types.  They merely provide an alias.  For the most part (not entirely, of course) the two following lines of C code are equivalent:</p>
<p>typedef foo bar;</p>
<p>#define bar foo</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-286</link>
		<dc:creator>Peter</dc:creator>
		<pubDate>Thu, 23 Aug 2007 01:10:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-286</guid>
		<description>Not sure if you&#039;re wanting to use C++ for this, but std::vector and friends make this so amazingly simpler. :P</description>
		<content:encoded><![CDATA[<p>Not sure if you&#8217;re wanting to use C++ for this, but std::vector and friends make this so amazingly simpler. :P</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Buck</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-285</link>
		<dc:creator>Joe Buck</dc:creator>
		<pubDate>Wed, 22 Aug 2007 23:21:54 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-285</guid>
		<description>The original blog posting is right; the non-orthogonal handling of arrays is a wart. They had their reasons; passing general arrays by value would have required some heavyweight mechanism, and there are advantages to being able to convert an array to a pointer to its first element, but it means you can&#039;t treat an array like other types.

You can embed an array in a struct:


typedef struct {
     int data[4];
} four_ints;
</description>
		<content:encoded><![CDATA[<p>The original blog posting is right; the non-orthogonal handling of arrays is a wart. They had their reasons; passing general arrays by value would have required some heavyweight mechanism, and there are advantages to being able to convert an array to a pointer to its first element, but it means you can&#8217;t treat an array like other types.</p>
<p>You can embed an array in a struct:</p>
<p>typedef struct {<br />
     int data[4];<br />
} four_ints;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pedro Côrte-Real</title>
		<link>http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/comment-page-1/#comment-284</link>
		<dc:creator>Pedro Côrte-Real</dc:creator>
		<pubDate>Wed, 22 Aug 2007 23:15:52 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/#comment-284</guid>
		<description>The reason you can&#039;t pass arrays as values is that since parameters size has to be fixed (va_args being the notable exception) you&#039;d have to call the function with an array with a fixed size. Your function definition would have to be something like:

foo(int bar[10])

and you&#039;d always have to pass an array of size 10. Passing structures by value works exactly because structures have a fixed size. They can contain arrays but only fixed sized ones.

The only reason this works with va_args is that the variable part is always the last arguments and its up to the function to know when to stop reading the stack by reading the arguments. That&#039;s why you can&#039;t have va_args functions that take 0 or more arguments since you need at least one to know if there&#039;s any more (printf is a good example of this).

You could argue that you should be able to pass fixed sized arrays as arguments but you can easily trick the compiler into letting you. Just define a structure with only the array in it and you can then use C&#039;s weak typing to pass an actual array instead of the structure. You might need some ugly casting to shut up the compiler though.</description>
		<content:encoded><![CDATA[<p>The reason you can&#8217;t pass arrays as values is that since parameters size has to be fixed (va_args being the notable exception) you&#8217;d have to call the function with an array with a fixed size. Your function definition would have to be something like:</p>
<p>foo(int bar[10])</p>
<p>and you&#8217;d always have to pass an array of size 10. Passing structures by value works exactly because structures have a fixed size. They can contain arrays but only fixed sized ones.</p>
<p>The only reason this works with va_args is that the variable part is always the last arguments and its up to the function to know when to stop reading the stack by reading the arguments. That&#8217;s why you can&#8217;t have va_args functions that take 0 or more arguments since you need at least one to know if there&#8217;s any more (printf is a good example of this).</p>
<p>You could argue that you should be able to pass fixed sized arrays as arguments but you can easily trick the compiler into letting you. Just define a structure with only the array in it and you can then use C&#8217;s weak typing to pass an actual array instead of the structure. You might need some ugly casting to shut up the compiler though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  blogs.gnome.org/desrt/2007/08/22/isoiec-98991999-e-%c2%a7-67537/feed/ ) in 1.19231 seconds, on Feb 11th, 2012 at 4:05 am UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 11th, 2012 at 5:05 am UTC -->
