<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Problem with memcpy in Operating System - Tru64 Unix</title>
    <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145859#M4191</link>
    <description>&amp;gt; Please let me know if any further&lt;BR /&gt;&amp;gt; information is requried.&lt;BR /&gt;&lt;BR /&gt;How about a failing test program?  My psychic&lt;BR /&gt;powers are too weak to tell me what's wrong&lt;BR /&gt;with your code if I can't see the code, how&lt;BR /&gt;you built it, or how you ran it.  One guess:&lt;BR /&gt;&lt;BR /&gt;"man memcpy":&lt;BR /&gt;&lt;BR /&gt;[...]&lt;BR /&gt;  The memcpy() function copies n bytes from the string pointed to by the s2&lt;BR /&gt;  parameter into the location pointed to by the s1 parameter. When copying&lt;BR /&gt;  overlapping strings, the behavior of this function is unreliable.&lt;BR /&gt;[...]&lt;BR /&gt;&lt;BR /&gt;Does "unreliable" sound like what you're&lt;BR /&gt;seeing?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; We are running Tru64 UNIX 5.1 OS [...]&lt;BR /&gt;&lt;BR /&gt;Actual output from, say, "sizer -v" would be&lt;BR /&gt;more trustworthy than anything you say.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; [...] GNU make [...]&lt;BR /&gt;&lt;BR /&gt;That's probably the _least_ important thing&lt;BR /&gt;about how the program was compiled or linked.</description>
    <pubDate>Thu, 11 Dec 2008 05:01:32 GMT</pubDate>
    <dc:creator>Steven Schweda</dc:creator>
    <dc:date>2008-12-11T05:01:32Z</dc:date>
    <item>
      <title>Problem with memcpy</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145858#M4190</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;I am facing a very strange problem with memcpy function in our C code under our build environment.&lt;BR /&gt;&lt;BR /&gt;Just to give a brief history, our build system got crashed a while ago (2 months) and now we setup a new build system with same software installed of aprox. of same version as prior to crash.&lt;BR /&gt;&lt;BR /&gt;Now when we build the image, image build is successfull with no errors but image is behaving abnormally. When I tried to run the debug image it is running successfully. Then I tried to put Trace-logs within the code to find where the image is failing and i figured out: memcpy is copying 1 less character from source to destination.&lt;BR /&gt;&lt;BR /&gt;Could you please help me at what should i try to look at to fix this problem.&lt;BR /&gt;&lt;BR /&gt;We are running Tru64 UNIX 5.1 OS and making use of GNU make to build the image. Major code is written in C.&lt;BR /&gt;&lt;BR /&gt;Please let me know if any further information is requried.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;ajaydec</description>
      <pubDate>Thu, 11 Dec 2008 04:01:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145858#M4190</guid>
      <dc:creator />
      <dc:date>2008-12-11T04:01:32Z</dc:date>
    </item>
    <item>
      <title>Re: Problem with memcpy</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145859#M4191</link>
      <description>&amp;gt; Please let me know if any further&lt;BR /&gt;&amp;gt; information is requried.&lt;BR /&gt;&lt;BR /&gt;How about a failing test program?  My psychic&lt;BR /&gt;powers are too weak to tell me what's wrong&lt;BR /&gt;with your code if I can't see the code, how&lt;BR /&gt;you built it, or how you ran it.  One guess:&lt;BR /&gt;&lt;BR /&gt;"man memcpy":&lt;BR /&gt;&lt;BR /&gt;[...]&lt;BR /&gt;  The memcpy() function copies n bytes from the string pointed to by the s2&lt;BR /&gt;  parameter into the location pointed to by the s1 parameter. When copying&lt;BR /&gt;  overlapping strings, the behavior of this function is unreliable.&lt;BR /&gt;[...]&lt;BR /&gt;&lt;BR /&gt;Does "unreliable" sound like what you're&lt;BR /&gt;seeing?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; We are running Tru64 UNIX 5.1 OS [...]&lt;BR /&gt;&lt;BR /&gt;Actual output from, say, "sizer -v" would be&lt;BR /&gt;more trustworthy than anything you say.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; [...] GNU make [...]&lt;BR /&gt;&lt;BR /&gt;That's probably the _least_ important thing&lt;BR /&gt;about how the program was compiled or linked.</description>
      <pubDate>Thu, 11 Dec 2008 05:01:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145859#M4191</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2008-12-11T05:01:32Z</dc:date>
    </item>
    <item>
      <title>Re: Problem with memcpy</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145860#M4192</link>
      <description>Thanks a lot for your time and efforts.&lt;BR /&gt;&lt;BR /&gt;Problem got resolved after i upgrade my C compiler to the latest version.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;ajaydec</description>
      <pubDate>Wed, 04 Mar 2009 09:01:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-memcpy/m-p/5145860#M4192</guid>
      <dc:creator />
      <dc:date>2009-03-04T09:01:52Z</dc:date>
    </item>
  </channel>
</rss>

