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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,d8ff1403929a72c0
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.66.77.199 with SMTP id u7mr1672926paw.25.1344320756343;
        Mon, 06 Aug 2012 23:25:56 -0700 (PDT)
Path: 
 p10ni57pbh.1!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ctu-peer!ctu-gate!news.nctu.edu.tw!usenet.stanford.edu!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: awdorrin <awdorrin@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Interfacing between Ada and C: records and structs
Date: Tue, 31 Jul 2012 12:44:33 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <38e1e122-b788-4863-88ce-6b1fd5372e43@googlegroups.com>
References: <296e271a-967b-4dfb-8dca-f278ecfae03d@googlegroups.com>
 <a7qi6qFoc3U1@mid.individual.net>
 <5813d3d2-8a9f-4a08-bf09-db3c62847593@googlegroups.com>
 <e01280a4-3d74-47da-860b-c9f7cb0d2739@googlegroups.com>
 <m2vch3loj8.fsf@nidhoggr.home>
NNTP-Posting-Host: 192.91.173.34
Mime-Version: 1.0
X-Trace: posting.google.com 1343764677 26621 127.0.0.1 (31 Jul 2012 19:57:57
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 31 Jul 2012 19:57:57 +0000 (UTC)
In-Reply-To: <m2vch3loj8.fsf@nidhoggr.home>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.91.173.34;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
User-Agent: G2/1.0
X-Received-Bytes: 2117
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-07-31T12:44:33-07:00
List-Id: <comp.lang.ada>

This is code from the POSIX Florist API for Ada. There is a comment in the code that says that the 'Dummy' tagged null record is:
 "to force by-reference parameter mode"

Your test code matches up with similar code I wrote on my system, except being 32-bit I get D as "range 0 .. 31"

The 'rep' files generated by -gnatR3s for the Florist POSIX API gives:
for DUMMY'Size use 32;
for DUMMY'Alignment use 4;
for DUMMY use record
   _TAG at 0 range  0 .. 31;
end record;

for MUTEX'Object_Size use 256;
for MUTEX'Value_Size use 224;
for MUTEX'Alignment use 8;
for MUTEX use record
   MUTEX at  0 range  0 .. 191;
   D     at 24 range  0 .. 31;
end record;


So at least I understand why it isn't 192 bits, but 256.