<?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: C Structures, Pointers and Itanium and ALPHA VMS in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844864#M10310</link>
    <description>&amp;gt;  FtamApiParType *FTAM_api_data;&lt;BR /&gt;&amp;gt;  defines a scalar, not an array.&lt;BR /&gt;&lt;BR /&gt;Don't worry about it.  C pointer names and&lt;BR /&gt;array names are still pretty much&lt;BR /&gt;interchangeable (or should be), even on IA64.&lt;BR /&gt;&lt;BR /&gt;Personally, I'd probably add some printf()&lt;BR /&gt;statements to the code and display some of&lt;BR /&gt;the addresses involved to see if anyone is&lt;BR /&gt;making any sense.  When the debugger stops&lt;BR /&gt;making sense, it's time to go elsewhere for&lt;BR /&gt;useful information.&lt;BR /&gt;&lt;BR /&gt;Of course, I always tend to prefer the simple&lt;BR /&gt;to the sophisticated.  (And downright crude&lt;BR /&gt;is even better than simple, I claim.)</description>
    <pubDate>Wed, 16 Aug 2006 23:46:51 GMT</pubDate>
    <dc:creator>Steven Schweda</dc:creator>
    <dc:date>2006-08-16T23:46:51Z</dc:date>
    <item>
      <title>C Structures, Pointers and Itanium and ALPHA VMS</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844862#M10308</link>
      <description>Hi again,&lt;BR /&gt;&lt;BR /&gt;I have some complicated code which works on VMS ALPHA &lt;BR /&gt;(DEC C V6.0-001 on OpenVMS Alpha V7.1-2)&lt;BR /&gt;but not yet on VMS Itanium (HP C V7.1-011 on OpenVMS IA64 V8.2-1).&lt;BR /&gt;&lt;BR /&gt;I posted the original question a few weeks ago and I still have not fixed the code, &lt;BR /&gt;but I have narrowed the problems down to reproducable code.&lt;BR /&gt;&lt;BR /&gt;The full source of the test program is about 750 lines in one source file with comments &lt;BR /&gt;and a lot of declarations to get the above to work..... &lt;BR /&gt;next task is to reduce the test program to isolate the issue/problem.....)&lt;BR /&gt;&lt;BR /&gt;The code uses a lot of structs, typedefs and pointer arthimetic.&lt;BR /&gt;&lt;BR /&gt;The main problem I have having is as follows in code snippets around the following typedef:&lt;BR /&gt;&lt;BR /&gt;1  typedef struct FtamApiParDef {&lt;BR /&gt;2        int     iFtamPort;&lt;BR /&gt;3        int     iApiStatus;&lt;BR /&gt;4        int     iFtamStatus;&lt;BR /&gt;5        int     iFtamCommand;&lt;BR /&gt;6        osifpbType  *pResultpb;&lt;BR /&gt;7        osifpbType  *pOsifpb[MaxParameterBlockNumbers];&lt;BR /&gt;8        struct  osifpb *pOsifpbtest[MaxParameterBlockNumbers];  &lt;BR /&gt;9        osif_buffer_listType *pBufferList[MaxOsifBuffers];&lt;BR /&gt;10       RecordInfoType  RecordInfo;&lt;BR /&gt;11       char    scratch[32];&lt;BR /&gt;12  } FtamApiParType;&lt;BR /&gt;&lt;BR /&gt;Notes:&lt;BR /&gt;(Line 8 is added by myself to try and debug this code)&lt;BR /&gt;Lines 7 and 8 above are equivilent as osifpbType is typedef's as struct osifpb, and the struct &lt;BR /&gt;osifpb is defined in the standard header sys$library:osif.h&lt;BR /&gt;thus giving an array of pointers to structures&lt;BR /&gt;MaxParameterBlockNumbers is defined as follows:&lt;BR /&gt;&lt;BR /&gt;enum    ParameterBlockNumbers {&lt;BR /&gt;        BeginGroupParameterBlock,&lt;BR /&gt;        SelectParameterBlock,&lt;BR /&gt;        OpenParameterBlock,&lt;BR /&gt;        EndGroupParameterBlock,&lt;BR /&gt;        MaxParameterBlockNumbers };&lt;BR /&gt;&lt;BR /&gt;The above typedefs are then used to define a pointer variable as &lt;BR /&gt;follows to use the defined structure:&lt;BR /&gt;&lt;BR /&gt;FtamApiParType *FTAM_api_data;&lt;BR /&gt;&lt;BR /&gt;When the program runs in Debug on VMS Alpha I get what I require when looking at  &lt;BR /&gt;FTAM_api_data[0].pResultpb&lt;BR /&gt;FTAM_api_data[0].pOsifpb[0]&lt;BR /&gt;ie they both return addresses (or an array of addresses) that are then &lt;BR /&gt;pointers to the osifpb structures defined. &lt;BR /&gt;&lt;BR /&gt;On VMS Itanium I do not get the same behaviour&lt;BR /&gt;FTAM_api_data[0].pResultpb returns a pointer address as expected.&lt;BR /&gt;BUT FTAM_api_data[0].pOsifpb[0] returns the something like the following:&lt;BR /&gt;&lt;BR /&gt;DBG&amp;gt; ex FTAM_api_data[0].pOsifpbtest&lt;BR /&gt;TEST\main\%LINE 9449\FTAM_api_data[0].pOsifpbtest[0:3]&lt;BR /&gt;    [0]:        48925241413831804751116003009695900761194800108916740805498008442293941802393281179557430083179543281820765249658043&lt;BR /&gt;96239402714093723528293514634452579354948479781822283484391278&lt;BR /&gt;    [1]:        11391295449303417641463690206803358337188791508999825642792975633007926354741975939729583934689765628851197019605441&lt;BR /&gt;94150576999898469897055419775297068840579241463407474&lt;BR /&gt;    [2]:        26522426515127107597570145052865516248133013744372468541359937826655633642203118511777333763171373002350323413511370&lt;BR /&gt;1725047314515912415705486148432146022231141&lt;BR /&gt;    [3]:        61752336367795028718118893571350528505009165369841429734043632230385284969124753288406258828871354931849807997959130&lt;BR /&gt;845276479263769559493634418685023&lt;BR /&gt;&lt;BR /&gt;Also on VMS Itanium when values are set to the structure items below pOsifpb and pOsifpbtest they corrupt the &lt;BR /&gt;values stored in pOsifpb and pOsifpbtest.&lt;BR /&gt;&lt;BR /&gt;On Alpha VMS I get the following, whih I think is what I am expecting for pointers:&lt;BR /&gt;DBG&amp;gt; ex FTAM_api_data[0].pOsifpbtest&lt;BR /&gt;TEST\main\%LINE 9449\FTAM_api_data[0].pOsifpbtest[0:3]&lt;BR /&gt;    [0]:   0000000000&lt;BR /&gt;    [1]:   0000000000&lt;BR /&gt;    [2]:   0000000000&lt;BR /&gt;    [3]:   0000000000&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Can anyone shed any light on what I am seeing here and why it works on the old compiler on &lt;BR /&gt;Alpha VMS but not on the new C complier on Itanium?&lt;BR /&gt;&lt;BR /&gt;Is the pointer arthmetic correct or are the definitions incorrect.&lt;BR /&gt;&lt;BR /&gt;Where is all the extra data coming from in the debugger on Itanium, ie not pointer addresses?&lt;BR /&gt;&lt;BR /&gt;Many thanks&lt;BR /&gt;JC&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 16 Aug 2006 16:29:21 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844862#M10308</guid>
      <dc:creator>CA1296764</dc:creator>
      <dc:date>2006-08-16T16:29:21Z</dc:date>
    </item>
    <item>
      <title>Re: C Structures, Pointers and Itanium and ALPHA VMS</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844863#M10309</link>
      <description>JC_UK,&lt;BR /&gt;&lt;BR /&gt;Before we get wrapped up in this, please ensure that you are working with UNOPTIMIZED code on both systems.&lt;BR /&gt;&lt;BR /&gt;Let me preface the following by observing that I have been working since 0430 EDT here in New York.&lt;BR /&gt;&lt;BR /&gt;At first glance, it would appear that FTAM_api_data is NOT an array. The following line (extracted from your posting):&lt;BR /&gt;&lt;BR /&gt;FtamApiParType *FTAM_api_data;&lt;BR /&gt;&lt;BR /&gt;defines a scalar, not an array. I don't have the C/C++ syntax description handy (and I will accept correction from somebody who DOES have the manual handy), but at first impression this looks like a marginal, if not incorrect syntax.&lt;BR /&gt;&lt;BR /&gt;If I am correct, you have fallen victim to the syndrome of marginally legal code (which VAX C users well remember). In these cases, the code accidentally works for a while, until the compiler, optimizer, run-time library, or operating system decide to enforce the rules more literally.&lt;BR /&gt;&lt;BR /&gt;However, as I said, just a flash reading of the code.&lt;BR /&gt;&lt;BR /&gt;- Bob Gezelter, &lt;A href="http://www.rlgsc.com" target="_blank"&gt;http://www.rlgsc.com&lt;/A&gt;</description>
      <pubDate>Wed, 16 Aug 2006 18:30:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844863#M10309</guid>
      <dc:creator>Robert Gezelter</dc:creator>
      <dc:date>2006-08-16T18:30:52Z</dc:date>
    </item>
    <item>
      <title>Re: C Structures, Pointers and Itanium and ALPHA VMS</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844864#M10310</link>
      <description>&amp;gt;  FtamApiParType *FTAM_api_data;&lt;BR /&gt;&amp;gt;  defines a scalar, not an array.&lt;BR /&gt;&lt;BR /&gt;Don't worry about it.  C pointer names and&lt;BR /&gt;array names are still pretty much&lt;BR /&gt;interchangeable (or should be), even on IA64.&lt;BR /&gt;&lt;BR /&gt;Personally, I'd probably add some printf()&lt;BR /&gt;statements to the code and display some of&lt;BR /&gt;the addresses involved to see if anyone is&lt;BR /&gt;making any sense.  When the debugger stops&lt;BR /&gt;making sense, it's time to go elsewhere for&lt;BR /&gt;useful information.&lt;BR /&gt;&lt;BR /&gt;Of course, I always tend to prefer the simple&lt;BR /&gt;to the sophisticated.  (And downright crude&lt;BR /&gt;is even better than simple, I claim.)</description>
      <pubDate>Wed, 16 Aug 2006 23:46:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c-structures-pointers-and-itanium-and-alpha-vms/m-p/3844864#M10310</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2006-08-16T23:46:51Z</dc:date>
    </item>
  </channel>
</rss>

