<?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: Extra Arguments under Workshop Debugger in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837643#M721222</link>
    <description>I don't know what "Workshop" is or what it has&lt;BR /&gt;to do with HP-UX, but your use of memcpy()&lt;BR /&gt;is a little strange.   You're copying 256 kb from&lt;BR /&gt;X to Y, but X is only 10 bytes long.  Y will&lt;BR /&gt;get the value "test1" and the contents of&lt;BR /&gt;memory following Y will get corrupted. It may&lt;BR /&gt;in fact corrupt X itself, because X may follow&lt;BR /&gt;Y in memory.  Depending on the memory&lt;BR /&gt;layout of your OS it may also trash the&lt;BR /&gt;program stack, which could cause the&lt;BR /&gt;error messge you are seeing.&lt;BR /&gt;&lt;BR /&gt;memcpy() is typically used for copying&lt;BR /&gt;arbitrary binary data, not strings. The&lt;BR /&gt;copy would be better implemented using&lt;BR /&gt;strncpy(), which will stop after it hits the&lt;BR /&gt;null byte at the end of X or if there's not&lt;BR /&gt;enough space in Y to receive the contents.&lt;BR /&gt;&lt;BR /&gt;As for __align_cpy_1, it's probably a subroutine&lt;BR /&gt;in libc or perhaps in the kernel.  _memcpy&lt;BR /&gt;is not the same as memcpy(); it's probably&lt;BR /&gt;a subroutine in libc as well.  (System libraries&lt;BR /&gt;like libc usually employ a leading underscore&lt;BR /&gt;on internal subroutine names and internal&lt;BR /&gt;variables, which is why you should avoid&lt;BR /&gt;using a leading underscore in user-defined&lt;BR /&gt;subroutine or variable names.)&lt;BR /&gt;&lt;BR /&gt;At any rate, memcpy() probably calls&lt;BR /&gt;_memcpy and/or __align_cpy_1 and&lt;BR /&gt;automatically supplies the 6 arguments&lt;BR /&gt;as needed.  These may include the 3&lt;BR /&gt;arguments you passed to memcpy(), but&lt;BR /&gt;you cannot depend on any relationship&lt;BR /&gt;between the two sets.&lt;BR /&gt;&lt;BR /&gt;Unless you  you suspect there's a bug&lt;BR /&gt;in your vendor's libc or unless you are&lt;BR /&gt;really interested in its inner workings,&lt;BR /&gt;you probably shouldn't worry about the&lt;BR /&gt;arguments memcpy() passes to its&lt;BR /&gt;subroutines.&lt;BR /&gt;&lt;BR /&gt;HTH</description>
    <pubDate>Fri, 01 Nov 2002 21:37:25 GMT</pubDate>
    <dc:creator>Gregory Fruth</dc:creator>
    <dc:date>2002-11-01T21:37:25Z</dc:date>
    <item>
      <title>Extra Arguments under Workshop Debugger</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837642#M721221</link>
      <description>I'm running WorkShop 6 on a Solaris 8 system.  I have a few questions regarding&lt;BR /&gt;the debugger.  Given the following trival C program&lt;BR /&gt;&lt;BR /&gt;  #include &lt;STDIO.H&gt;&lt;BR /&gt;  #include &lt;STDLIB.H&gt;&lt;BR /&gt;&lt;BR /&gt;  int main() {&lt;BR /&gt; &lt;BR /&gt;  char X[10] = "test1";&lt;BR /&gt;  char Y[10];&lt;BR /&gt;&lt;BR /&gt;  memcpy(Y,X,0x40000);&lt;BR /&gt;  printf("Y=%s\n",Y);&lt;BR /&gt;}&lt;BR /&gt;&lt;BR /&gt;When I run this under the debugger I get a SEGV with the following output:&lt;BR /&gt;&lt;BR /&gt;   main()&lt;BR /&gt;   __align_cpy_1(0xffbefff0, 0xffbefffa, 0x3f9c8, 0x7, 0x3f9c0, 0xffbef9b8)&lt;BR /&gt;&lt;BR /&gt;I have a couple of questions/comments on this:&lt;BR /&gt;&lt;BR /&gt;1) I'm assuming __align_cpy_1 is a subroutine of memcpy (right?).&lt;BR /&gt;2) Where are there 6 arguments to this when memcpy only takes 3?  I'm&lt;BR /&gt;   asking because we have an actual customer problem that, when run under&lt;BR /&gt;   WorkShop, shows the SEGV to occur on _memcpy itself, but there are still&lt;BR /&gt;   6 rather than 3 arguments.  Where are these extra 3 arguments coming&lt;BR /&gt;   from?&lt;BR /&gt;3) From experiments, the 3rd argument, 0x3f9c8, is, as expected, the&lt;BR /&gt;   length.  However, shouldn't it be 0x40000?&lt;BR /&gt;&lt;/STDLIB.H&gt;&lt;/STDIO.H&gt;</description>
      <pubDate>Fri, 01 Nov 2002 19:14:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837642#M721221</guid>
      <dc:creator>kenneth_20</dc:creator>
      <dc:date>2002-11-01T19:14:11Z</dc:date>
    </item>
    <item>
      <title>Re: Extra Arguments under Workshop Debugger</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837643#M721222</link>
      <description>I don't know what "Workshop" is or what it has&lt;BR /&gt;to do with HP-UX, but your use of memcpy()&lt;BR /&gt;is a little strange.   You're copying 256 kb from&lt;BR /&gt;X to Y, but X is only 10 bytes long.  Y will&lt;BR /&gt;get the value "test1" and the contents of&lt;BR /&gt;memory following Y will get corrupted. It may&lt;BR /&gt;in fact corrupt X itself, because X may follow&lt;BR /&gt;Y in memory.  Depending on the memory&lt;BR /&gt;layout of your OS it may also trash the&lt;BR /&gt;program stack, which could cause the&lt;BR /&gt;error messge you are seeing.&lt;BR /&gt;&lt;BR /&gt;memcpy() is typically used for copying&lt;BR /&gt;arbitrary binary data, not strings. The&lt;BR /&gt;copy would be better implemented using&lt;BR /&gt;strncpy(), which will stop after it hits the&lt;BR /&gt;null byte at the end of X or if there's not&lt;BR /&gt;enough space in Y to receive the contents.&lt;BR /&gt;&lt;BR /&gt;As for __align_cpy_1, it's probably a subroutine&lt;BR /&gt;in libc or perhaps in the kernel.  _memcpy&lt;BR /&gt;is not the same as memcpy(); it's probably&lt;BR /&gt;a subroutine in libc as well.  (System libraries&lt;BR /&gt;like libc usually employ a leading underscore&lt;BR /&gt;on internal subroutine names and internal&lt;BR /&gt;variables, which is why you should avoid&lt;BR /&gt;using a leading underscore in user-defined&lt;BR /&gt;subroutine or variable names.)&lt;BR /&gt;&lt;BR /&gt;At any rate, memcpy() probably calls&lt;BR /&gt;_memcpy and/or __align_cpy_1 and&lt;BR /&gt;automatically supplies the 6 arguments&lt;BR /&gt;as needed.  These may include the 3&lt;BR /&gt;arguments you passed to memcpy(), but&lt;BR /&gt;you cannot depend on any relationship&lt;BR /&gt;between the two sets.&lt;BR /&gt;&lt;BR /&gt;Unless you  you suspect there's a bug&lt;BR /&gt;in your vendor's libc or unless you are&lt;BR /&gt;really interested in its inner workings,&lt;BR /&gt;you probably shouldn't worry about the&lt;BR /&gt;arguments memcpy() passes to its&lt;BR /&gt;subroutines.&lt;BR /&gt;&lt;BR /&gt;HTH</description>
      <pubDate>Fri, 01 Nov 2002 21:37:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837643#M721222</guid>
      <dc:creator>Gregory Fruth</dc:creator>
      <dc:date>2002-11-01T21:37:25Z</dc:date>
    </item>
    <item>
      <title>Re: Extra Arguments under Workshop Debugger</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837644#M721223</link>
      <description>Sorry, please ignore this post.&lt;BR /&gt;This was meant for the Solaris&lt;BR /&gt;newsgroup (I'm juggling too many&lt;BR /&gt;platforms lately).</description>
      <pubDate>Mon, 04 Nov 2002 13:28:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/extra-arguments-under-workshop-debugger/m-p/2837644#M721223</guid>
      <dc:creator>kenneth_20</dc:creator>
      <dc:date>2002-11-04T13:28:25Z</dc:date>
    </item>
  </channel>
</rss>

