<?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: Find The Offset Of An Element In A Structure In C- offsetof()</title>
	<atom:link href="http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html</link>
	<description>Making Your Code Faster, Stronger, Safer…</description>
	<lastBuildDate>Thu, 18 Feb 2010 05:11:26 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Shantanu Goel</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1849</link>
		<dc:creator>Shantanu Goel</dc:creator>
		<pubDate>Mon, 11 May 2009 04:27:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1849</guid>
		<description>Zombie: I agree with you on the struct declaration part. I should have been more careful while writing the declaration.
But an &quot;unsigned long&quot; is as bad as an &quot;unsigned int&quot;. There is no better option amongst these two. As you can see though, the final solution proposed, which is the crux of the article, does indeed use size_t.
And that particular statement that you refer to, was written just to show what not to do when you are going for portability. At no point of time, I &quot;suggested&quot; that this code be used. It was always clear that the first two forms are used by people already but they are not portable. I disagree when you say that someone should be taught only what is the right thing to do. I believe it is also equally important to tell them what&#039;s wrong and that is exactly because &quot;Human brain has limited capacity&quot;. So, even if you tell them all the things that are right, they might get confused when they face something that is wrong and can&#039;t decide on their own which side it lies on. Probably I could have explained it a bit more why it isn&#039;t portable, yes. 
Moreover, I did not mention about the struct internal padding, alignment, etc because it was not geared towards a user who was a complete novice to it. It was geared towards someone who was already in the know/using one of the first two approaches and to tell him that there is a better way.
But I&#039;m glad that we have a learned programmer like you who keeps us in check, points out our innumerous flaws and eggs us on to write better. Thanks a lot for your contribution.</description>
		<content:encoded><![CDATA[<p>Zombie: I agree with you on the struct declaration part. I should have been more careful while writing the declaration.<br />
But an &#8220;unsigned long&#8221; is as bad as an &#8220;unsigned int&#8221;. There is no better option amongst these two. As you can see though, the final solution proposed, which is the crux of the article, does indeed use size_t.<br />
And that particular statement that you refer to, was written just to show what not to do when you are going for portability. At no point of time, I &#8220;suggested&#8221; that this code be used. It was always clear that the first two forms are used by people already but they are not portable. I disagree when you say that someone should be taught only what is the right thing to do. I believe it is also equally important to tell them what&#8217;s wrong and that is exactly because &#8220;Human brain has limited capacity&#8221;. So, even if you tell them all the things that are right, they might get confused when they face something that is wrong and can&#8217;t decide on their own which side it lies on. Probably I could have explained it a bit more why it isn&#8217;t portable, yes.<br />
Moreover, I did not mention about the struct internal padding, alignment, etc because it was not geared towards a user who was a complete novice to it. It was geared towards someone who was already in the know/using one of the first two approaches and to tell him that there is a better way.<br />
But I&#8217;m glad that we have a learned programmer like you who keeps us in check, points out our innumerous flaws and eggs us on to write better. Thanks a lot for your contribution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Santiago</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1821</link>
		<dc:creator>Santiago</dc:creator>
		<pubDate>Sun, 10 May 2009 08:11:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1821</guid>
		<description>Zombie: yep, you are right of course. I sometimes forget that &#039;void *&#039; cannot be used for pointer arithmetic because I always try to avoid using it altogether unless completely needed (being a disciplined programmer involves things like this ;-)

So in this first implementation instead of using directly a pointer to char I prefer to use the uintptr_t as you suggest above (it is defined for C99, but the stdint.h header can even be easily written for non-C99 compilers), and a ptrdiff_t type for storing the offsets.

Cheers</description>
		<content:encoded><![CDATA[<p>Zombie: yep, you are right of course. I sometimes forget that &#8216;void *&#8217; cannot be used for pointer arithmetic because I always try to avoid using it altogether unless completely needed (being a disciplined programmer involves things like this <img src='http://www.safercode.com/blog/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>So in this first implementation instead of using directly a pointer to char I prefer to use the uintptr_t as you suggest above (it is defined for C99, but the stdint.h header can even be easily written for non-C99 compilers), and a ptrdiff_t type for storing the offsets.</p>
<p>Cheers</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zombie No. 5</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1794</link>
		<dc:creator>Zombie No. 5</dc:creator>
		<pubDate>Sat, 09 May 2009 15:35:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1794</guid>
		<description>Shantanu Goel: First, you code doesn&#039;t make sense. Apparently you meant &quot;struct example {...};&quot; not &quot;struct {...} example;&quot; or maybe you meant &quot;typedef struct {...} example&quot; but then you&#039;re first example is wrong again.

What a C programmer needs is discipline,  discipline and discipline. Therefore a sentence like &quot;The above snippet will work, but not always&quot; is unworthy. It will NOT always work, period. Since there are completely portable and efficient ways to achieve what you want, there&#039;s absolutely no point to suggest use of such nonsense code. You don&#039;t teach people things by showing them how to do something wrong but how to do it right. The human brain has only limited capacity.

What is this int nonsense anyway? Any half-decent C programmer would at least have used &quot;unsigned long&quot;. A more educated progammer would have used &quot;size_t&quot; or even &quot;uintptr_t&quot;. And a good developer just uses offsetof() because it&#039;s part of the standard.

This article would have been much more useful, if you had actually told the reader something about struct internal padding, alignment, order of elements etc. Otherwise, those readers for who any of this is news anyway, might wonder why you just don&#039;t use sizeof(example.b) as offset. The point is, it isn&#039;t just because that requires knowledge of the order of members, there are other reasons as well.

Santiago: You must be using GCC or some other forgiving C compiler because 
((void *)x - (void *)y) as you suggest is not &#039;C&#039; since pointer arithmetic is not legal because &quot;void&quot; has no size. A correct variant is casting to &quot;(char *)&quot;.</description>
		<content:encoded><![CDATA[<p>Shantanu Goel: First, you code doesn&#8217;t make sense. Apparently you meant &#8220;struct example {&#8230;};&#8221; not &#8220;struct {&#8230;} example;&#8221; or maybe you meant &#8220;typedef struct {&#8230;} example&#8221; but then you&#8217;re first example is wrong again.</p>
<p>What a C programmer needs is discipline,  discipline and discipline. Therefore a sentence like &#8220;The above snippet will work, but not always&#8221; is unworthy. It will NOT always work, period. Since there are completely portable and efficient ways to achieve what you want, there&#8217;s absolutely no point to suggest use of such nonsense code. You don&#8217;t teach people things by showing them how to do something wrong but how to do it right. The human brain has only limited capacity.</p>
<p>What is this int nonsense anyway? Any half-decent C programmer would at least have used &#8220;unsigned long&#8221;. A more educated progammer would have used &#8220;size_t&#8221; or even &#8220;uintptr_t&#8221;. And a good developer just uses offsetof() because it&#8217;s part of the standard.</p>
<p>This article would have been much more useful, if you had actually told the reader something about struct internal padding, alignment, order of elements etc. Otherwise, those readers for who any of this is news anyway, might wonder why you just don&#8217;t use sizeof(example.b) as offset. The point is, it isn&#8217;t just because that requires knowledge of the order of members, there are other reasons as well.</p>
<p>Santiago: You must be using GCC or some other forgiving C compiler because<br />
((void *)x &#8211; (void *)y) as you suggest is not &#8216;C&#8217; since pointer arithmetic is not legal because &#8220;void&#8221; has no size. A correct variant is casting to &#8220;(char *)&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Santiago</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1790</link>
		<dc:creator>Santiago</dc:creator>
		<pubDate>Sat, 09 May 2009 12:23:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1790</guid>
		<description>I was aware of the &#039;offsetof&#039; macro, but for some gdb scripts I was forced to use the first implementation. However, it is a little cumbersome because you are forced to declare an instance of the struct type, for example a dummy global variable just to be easily accessible from gdb. Obviously, that can be a problem and is not very elegant.

So I find the second implementation really elegant and useful, because it doesn&#039;t need declaring an instance of the variable. I&#039;ll probably change those gdb scripts, thanks!

PS: IMHO the first implementation is more problematic than required, when doing pointer arithmetic is more adequate to use a pointer data type than integer types. Just operate with temp variables of type &#039;void *&#039;, and finally assign the result to an unsigned int. Casting first the addresses to unsigned int is really dangerous, in many cases the integer types are narrower than the address types.

Cheers</description>
		<content:encoded><![CDATA[<p>I was aware of the &#8216;offsetof&#8217; macro, but for some gdb scripts I was forced to use the first implementation. However, it is a little cumbersome because you are forced to declare an instance of the struct type, for example a dummy global variable just to be easily accessible from gdb. Obviously, that can be a problem and is not very elegant.</p>
<p>So I find the second implementation really elegant and useful, because it doesn&#8217;t need declaring an instance of the variable. I&#8217;ll probably change those gdb scripts, thanks!</p>
<p>PS: IMHO the first implementation is more problematic than required, when doing pointer arithmetic is more adequate to use a pointer data type than integer types. Just operate with temp variables of type &#8216;void *&#8217;, and finally assign the result to an unsigned int. Casting first the addresses to unsigned int is really dangerous, in many cases the integer types are narrower than the address types.</p>
<p>Cheers</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shantanu Goel</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1768</link>
		<dc:creator>Shantanu Goel</dc:creator>
		<pubDate>Fri, 08 May 2009 22:23:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1768</guid>
		<description>@Zombie: Care to tell what exactly is the issue with the statement?</description>
		<content:encoded><![CDATA[<p>@Zombie: Care to tell what exactly is the issue with the statement?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zombie No. 5</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1759</link>
		<dc:creator>Zombie No. 5</dc:creator>
		<pubDate>Fri, 08 May 2009 16:33:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1759</guid>
		<description>Seriously guys...is this blog a complete joke or what? You&#039;re casting address to an unsigned int to calculate the difference between two addresses.

&quot;Making Your Code Faster, Stronger, Safer...&quot;

How about learning some basic knowledge of C first?</description>
		<content:encoded><![CDATA[<p>Seriously guys&#8230;is this blog a complete joke or what? You&#8217;re casting address to an unsigned int to calculate the difference between two addresses.</p>
<p>&#8220;Making Your Code Faster, Stronger, Safer&#8230;&#8221;</p>
<p>How about learning some basic knowledge of C first?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shantanu Goel</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1684</link>
		<dc:creator>Shantanu Goel</dc:creator>
		<pubDate>Wed, 06 May 2009 13:59:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1684</guid>
		<description>0 in itself is not a valid lvalue. But when you typecast it to the structure pointer type and then dereference an element from it, it becomes a valid lvalue and &amp; operator can be used for it.</description>
		<content:encoded><![CDATA[<p>0 in itself is not a valid lvalue. But when you typecast it to the structure pointer type and then dereference an element from it, it becomes a valid lvalue and &#038; operator can be used for it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: markandey</title>
		<link>http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1657</link>
		<dc:creator>markandey</dc:creator>
		<pubDate>Tue, 05 May 2009 16:46:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/2009/05/05/find-element-offset-structure-c-offsetof.html#comment-1657</guid>
		<description>does &amp; operator work on a constant value?</description>
		<content:encoded><![CDATA[<p>does &amp; operator work on a constant value?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
