<?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: Unsafe Functions In C And Their Safer Replacements: Strings Part II</title>
	<atom:link href="http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.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: mcoon</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-249</link>
		<dc:creator>mcoon</dc:creator>
		<pubDate>Tue, 03 Mar 2009 17:09:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-249</guid>
		<description>See the C++ STL string template object. 

#include ;
#include ;

using namespace std;

int main(int argc, char *argv[]){
  string s(&quot;This is a basic string.&quot;);
  cout &lt;&lt; s &lt;&lt; endl;
}</description>
		<content:encoded><![CDATA[<p>See the C++ STL string template object. </p>
<p>#include ;<br />
#include ;</p>
<p>using namespace std;</p>
<p>int main(int argc, char *argv[]){<br />
  string s(&#8220;This is a basic string.&#8221;);<br />
  cout &lt;&lt; s &lt;&lt; endl;<br />
}</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bug1</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-247</link>
		<dc:creator>bug1</dc:creator>
		<pubDate>Tue, 03 Mar 2009 13:04:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-247</guid>
		<description>Programmers should use dmalloc (or another memory checker, maybe valgrind) to check against memory leaks and fencepost problems (exceeding the end of allocated memory), that should highlight most cases of &quot;unsafe&quot; string use (not format attacks).

Introducing functions that allow programmers to remain ignorant of how their code works might be convenient in the short term, but in the long term the best way to write safe code is understand the language.

C&#039;s strength is that its low level, its not one of these dumbed down flash in the pan convenience languages.</description>
		<content:encoded><![CDATA[<p>Programmers should use dmalloc (or another memory checker, maybe valgrind) to check against memory leaks and fencepost problems (exceeding the end of allocated memory), that should highlight most cases of &#8220;unsafe&#8221; string use (not format attacks).</p>
<p>Introducing functions that allow programmers to remain ignorant of how their code works might be convenient in the short term, but in the long term the best way to write safe code is understand the language.</p>
<p>C&#8217;s strength is that its low level, its not one of these dumbed down flash in the pan convenience languages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DoctorPepper</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-246</link>
		<dc:creator>DoctorPepper</dc:creator>
		<pubDate>Tue, 03 Mar 2009 11:22:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-246</guid>
		<description>Never mind, I answered my own question.  The strlcpy and strlcat functions are supposed to be safer versions of strncpy and strncat as well as strcpy and strcat.

Man, don&#039;t you hate it when you reply too early in the morning?</description>
		<content:encoded><![CDATA[<p>Never mind, I answered my own question.  The strlcpy and strlcat functions are supposed to be safer versions of strncpy and strncat as well as strcpy and strcat.</p>
<p>Man, don&#8217;t you hate it when you reply too early in the morning?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dummy00001</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-245</link>
		<dc:creator>Dummy00001</dc:creator>
		<pubDate>Tue, 03 Mar 2009 10:31:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-245</guid>
		<description>&gt; Solaris and BSD accepted these functions while GNU/Linux refuses to do so till date.

Little of Googling never hurts. And definitely might have helped to resolve your confusion and avoid silly remark. GNU refused the function for two very simple reasons: (1) there is no stable interfaces/not a POSIX and (2) redundant.

As was pointed many many times, strlcpy() is 100% redundant, as the same effect can be achieved by snprintf(dest,dest_capacity,&quot;%s&quot;,src).

What&#039;s more, snprintf() has very important extra bonus: snprintf(dest,dest_capacity,&quot;%.*s&quot;,src_len,src) which allows to work also on non-zero terminated input.</description>
		<content:encoded><![CDATA[<p>&gt; Solaris and BSD accepted these functions while GNU/Linux refuses to do so till date.</p>
<p>Little of Googling never hurts. And definitely might have helped to resolve your confusion and avoid silly remark. GNU refused the function for two very simple reasons: (1) there is no stable interfaces/not a POSIX and (2) redundant.</p>
<p>As was pointed many many times, strlcpy() is 100% redundant, as the same effect can be achieved by snprintf(dest,dest_capacity,&#8221;%s&#8221;,src).</p>
<p>What&#8217;s more, snprintf() has very important extra bonus: snprintf(dest,dest_capacity,&#8221;%.*s&#8221;,src_len,src) which allows to work also on non-zero terminated input.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maglama</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-244</link>
		<dc:creator>Maglama</dc:creator>
		<pubDate>Tue, 03 Mar 2009 10:28:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-244</guid>
		<description>* EDIT that&#039;s supposed to read &quot;We could move the historical functions to an {less-than}unsafe_c.h{greater-than} but the blog stripped it as HTML-like</description>
		<content:encoded><![CDATA[<p>* EDIT that&#8217;s supposed to read &#8220;We could move the historical functions to an {less-than}unsafe_c.h{greater-than} but the blog stripped it as HTML-like</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maglama</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-243</link>
		<dc:creator>Maglama</dc:creator>
		<pubDate>Tue, 03 Mar 2009 10:27:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-243</guid>
		<description>Why don&#039;t we just fully depreciate the unsafe functions? Seriously.

We could move the historical functions to an , allowing old code to be trivially recompiled if we REALLY don&#039;t want to fix it. Everyone else can use heap storage calculated to fit.</description>
		<content:encoded><![CDATA[<p>Why don&#8217;t we just fully depreciate the unsafe functions? Seriously.</p>
<p>We could move the historical functions to an , allowing old code to be trivially recompiled if we REALLY don&#8217;t want to fix it. Everyone else can use heap storage calculated to fit.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DoctorPepper</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-242</link>
		<dc:creator>DoctorPepper</dc:creator>
		<pubDate>Tue, 03 Mar 2009 10:20:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-242</guid>
		<description>What about the strncpy and strncat functions that have been in gcc for quite some time now? They have similar function declarations to the strlcpy and strlcat functions you specified:

char *strncpy(char *dest, const char *src, size_t n);
char *strncat(char *dest, const char *src, size_t n);

Granted, they don&#039;t return the number of bytes copied in a size_t, but they will only copy &#039;n&#039; number of bytes.</description>
		<content:encoded><![CDATA[<p>What about the strncpy and strncat functions that have been in gcc for quite some time now? They have similar function declarations to the strlcpy and strlcat functions you specified:</p>
<p>char *strncpy(char *dest, const char *src, size_t n);<br />
char *strncat(char *dest, const char *src, size_t n);</p>
<p>Granted, they don&#8217;t return the number of bytes copied in a size_t, but they will only copy &#8216;n&#8217; number of bytes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CdeMills</title>
		<link>http://www.safercode.com/blog/2008/12/02/unsafe-functions-in-c-and-their-safer-replacements-strings-part-ii.html#comment-241</link>
		<dc:creator>CdeMills</dc:creator>
		<pubDate>Tue, 03 Mar 2009 09:47:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.safercode.com/blog/?p=25#comment-241</guid>
		<description>I agree with the criticisms. To me, a &#039;string&#039; should really be something opaque instead of a vector of chars. Strings have properties : they can contains standard ASCII characters or use some encoding or be in wide, multi-bytes characters; their storage can be static, local or resulting from a &#039;malloc&#039; call; and so on. Each item introduces specific issues and pitfalls. Your approach is targeted some issues, based on a few assumptions. If the basic assumptions are not satisfied, behaviour is unspecified.</description>
		<content:encoded><![CDATA[<p>I agree with the criticisms. To me, a &#8217;string&#8217; should really be something opaque instead of a vector of chars. Strings have properties : they can contains standard ASCII characters or use some encoding or be in wide, multi-bytes characters; their storage can be static, local or resulting from a &#8216;malloc&#8217; call; and so on. Each item introduces specific issues and pitfalls. Your approach is targeted some issues, based on a few assumptions. If the basic assumptions are not satisfied, behaviour is unspecified.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
