From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7f2513845b4ef39f X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: More C Date: 2000/02/02 Message-ID: <38982a12@eeyore.callnetuk.com>#1/1 X-Deja-AN: 580776202 References: <3896134b@eeyore.callnetuk.com> X-Original-NNTP-Posting-Host: da129d171.dialup.callnetuk.com X-Trace: 2 Feb 2000 12:58:58 GMT, da129d171.dialup.callnetuk.com X-MSMail-Priority: Normal X-Priority: 3 Newsgroups: comp.lang.ada X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: 2000-02-02T00:00:00+00:00 List-Id: Jan's comments broadly accepted. It surely demonstrates one aspect of the deficiencies of C as a software engineering language, that the programmer has, in general, no control over how types are represented, and that it is common for C compilers to vary from one another (and the ANSI standard) in this matter. In this respect, it is necessary to think of interfacing Ada source code not to C source code, but to C object code (i.e. C source as compiled by a particular version of a particular compiler, with a particular set of flags in force). To the rescue, to a certain extent, comes the ability of most C compilers to output an assembly listing (or other listing) that shows the representations (and addresses) chosen for types and objects. -- Nick Roberts http://www.adapower.com/lab/adaos "Jan Kroken" wrote in message news:vhioga1r2j8.fsf@grotte.ifi.uio.no... > ... > What if the [C] compiler decides to optimize access to the record, > so the real memory structure becomes as follows? > > for SDL_Color use > record > Red at 0 range 0..7; > Green at 32 range 32..39; > Blue at 64 range 64..71; > end record; > for SDL_Color'Size use 128; > ...