Reading a C record from socket - chicken / egg problem - now complete

Reading a C record from socket - chicken / egg problem - now complete

[Wojtek Narczynski]

Hello,

(sorry for my previous "post", hand slipped...)

I want to read a record like this:

   typedef struct {
      unsigned char version;
      unsigned char type;
      unsigned char requestIdB1;
      unsigned char requestIdB0;
      unsigned char contentLengthB1;
      unsigned char contentLengthB0;
      unsigned char paddingLength;
      unsigned char reserved;
      unsigned char contentData[contentLength];
      unsigned char paddingData[paddingLength];
   } FCGI_Record;

from socket. The 'type' field indicates different record type, so I
could declare different record types in Ada, but when I know 'type'
the record is already in memory. How should I approach this: 1. use
Unchecked_Conversion to convert to appropriate type? 2. Copy data into
a new record of appropriate type? 3. Just live with the structure C
imposes?


Another question is: can I declare non-contiguous enumeration
subtypes, or only range x..y? I've been unable to figure out how to
declare non-contiguous subtype, so I guess this isn't allowable, but
why? How am I supposed to write a strong typing program if I am not
able to declare a type that clearly "exists" (in math sense)? For
example:

-- Doestn't work

type Animal is ( Pig, Dog, Fish );
subtype Nice_Animal is Animal ( Pig, Dog );
subtype Home_Animail is Animal ( Dog, Fish );
subtype Eatable_Animal is Animal ( Pig, Fish );

In reality I wanted to declare subtypes of request type that don't
span a contiguous range.


Thanks for your patience & regards,
Wojtek Narczynski


P.S. Another question, slightly offtopic, is there any server where I
could get posting access to this group? Currently I use Google Groups.

Re: Reading a C record from socket - chicken / egg problem - now complete

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> Another question is: can I declare non-contiguous enumeration
> subtypes, or only range x..y?

Only ranges.

>... I've been unable to figure out how to
> declare non-contiguous subtype, so I guess this isn't allowable, but
> why?

Perhaps perceived compiler complexity?  Consider, for example, an array
indexed by such a subtype.

Also, the constraint-checking code could be rather slow for such a
subtype.  I don't find that to be a good argument, since too-slow checks
can always be suppressed.  But the original designers of Ada 83 tried to
avoid any kind of "costly" checking code.

I have often wanted this feature, too.  Not to index arrays,
but to use in case statements, for example.

- Bob

Re: Reading a C record from socket - chicken / egg problem - now complete

[Simon Wright]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> I want to read a record like this:
> 
>    typedef struct {
>       unsigned char version;
>       unsigned char type;
>       unsigned char requestIdB1;
>       unsigned char requestIdB0;
>       unsigned char contentLengthB1;
>       unsigned char contentLengthB0;
>       unsigned char paddingLength;
>       unsigned char reserved;
>       unsigned char contentData[contentLength];
>       unsigned char paddingData[paddingLength];
>    } FCGI_Record;
> 
> from socket. The 'type' field indicates different record type, so I
> could declare different record types in Ada, but when I know 'type'
> the record is already in memory. How should I approach this: 1. use
> Unchecked_Conversion to convert to appropriate type? 2. Copy data into
> a new record of appropriate type? 3. Just live with the structure C
> imposes?

Declare a structure corresponding to the fields version .. reserved
inclusive (use Interfaces.C.unsigned_char). and read it from the socket.

Calculate the actual contentLength and paddingLength.

Use a declare block:

  declare
    type content is array (1 .. contentLength) of Interfaces.C.unsigned_char;
    type padding is array (1 .. paddingLength) of Interfaces.C.unsigned_char;
    type remainder is record
      c : content;
      p : padding;
    end record;
    r : remainder;
  begin
    -- read r from the socket and process it
  end;

I know this means doing 2 reads but that's the minimum.

Re: Reading a C record from socket - chicken / egg problem - now complete

[SteveD]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0211230443.4b476252@posting.google.com...
> Hello,
>
> (sorry for my previous "post", hand slipped...)
>
> I want to read a record like this:
>
>    typedef struct {
>       unsigned char version;
>       unsigned char type;
>       unsigned char requestIdB1;
>       unsigned char requestIdB0;
>       unsigned char contentLengthB1;
>       unsigned char contentLengthB0;
>       unsigned char paddingLength;
>       unsigned char reserved;
>       unsigned char contentData[contentLength];
>       unsigned char paddingData[paddingLength];
>    } FCGI_Record;
>
> from socket. The 'type' field indicates different record type, so I
> could declare different record types in Ada, but when I know 'type'
> the record is already in memory. How should I approach this: 1. use
> Unchecked_Conversion to convert to appropriate type? 2. Copy data into
> a new record of appropriate type? 3. Just live with the structure C
> imposes?

If you're using streaming sockets the data appears as a stream of bytes.  In
this case there is no reason you must read the entire record with one recv.
Use one recv to learn the record type and the second recv to read the record
content.

>
> Another question is: can I declare non-contiguous enumeration
> subtypes, or only range x..y? I've been unable to figure out how to
> declare non-contiguous subtype, so I guess this isn't allowable, but
> why? How am I supposed to write a strong typing program if I am not
> able to declare a type that clearly "exists" (in math sense)? For
> example:
>
> -- Doestn't work
>
> type Animal is ( Pig, Dog, Fish );
> subtype Nice_Animal is Animal ( Pig, Dog );
> subtype Home_Animail is Animal ( Dog, Fish );
> subtype Eatable_Animal is Animal ( Pig, Fish );
>
> In reality I wanted to declare subtypes of request type that don't
> span a contiguous range.
>

While the enumeration values must be a contiguous range, there
representations do not.  The following example illustrates this.  You'll
notice that Unchecked_Conversion is used to get the underlying
representation of the enumeration ('Pos) doesn't work for this.

with Interfaces;
 use Interfaces;
with Ada.Text_Io;
with Ada.Unchecked_Conversion;

procedure Enum_Reps is

  package Integer_8_Io is
    new Ada.Text_Io.Integer_Io( Integer_8 );

  type Request_Type is ( req_type1, req_type2, req_type3 );
  for Request_Type use ( req_type1 => 3, req_type2 => 14, req_type3 => 25 );
  for Request_Type'Size use 8;

  function Conv is
    new Ada.Unchecked_Conversion( Integer_8, Request_Type );

 type_code  : Integer_8;
 enum_value : Request_Type;

begin
  loop
    Ada.Text_Io.Put( "Enter code (3,14,25) > " );
    Integer_8_Io.Get( type_code );
    Ada.Text_Io.Skip_Line;
    exit when type_code /= 3 and type_Code /= 14 and type_code /= 25;
    enum_value := Conv( type_code );
    Ada.Text_Io.Put_Line( "Enum is: " & Request_Type'Image( enum_value ) );
  end loop;
end Enum_Reps;

I hope this helps,
SteveD

Re: Reading a C record from socket - chicken / egg problem - now complete

[Craig Carey]

On 23 Nov 2002 04:43:33 -0800, wojtek@power.com.pl (Wojtek Narczynski)
wrote:

...
>Another question is: can I declare non-contiguous enumeration
>subtypes, or only range x .. y? I've been unable to figure out how to

The question could be a question about having Ada 95 improved so that
it implements sets that are like ranges except less ordered.

   for X in X1 .. X5 | X10 .. X12 loop
      Ada.Text_IO.Put_Line (...'Image (K));
   end loop;


>declare non-contiguous subtype, so I guess this isn't allowable, but
>why? How am I supposed to write a strong typing program if I am not
>able to declare a type that clearly "exists" (in math sense)? For
>example:
>
>-- Doesn't work
>
>type Animal is ( Pig, Dog, Fish );
>subtype Nice_Animal is Animal ( Pig, Dog );
>subtype Home_Animail is Animal ( Dog, Fish );
>subtype Eatable_Animal is Animal ( Pig, Fish );
>
>In reality I wanted to declare subtypes of request type that don't
>span a contiguous range.


See the bottom of the message for a fragment of the 1-Nov-2002 proposal
of Mr Jeffrey Carter that was posted to the Ada-Comment mailing list
and that proposed that sets (arrays of Booleans) be added to Ada 95.

Also at the bottom I quote a message of Robert I. Eachus that comments
on adding sets (arrays of Booleans or bits), to Ada 95.

Mr Carter wrote to Ada-Comment and asked for a package to be added.
This Usenet proposal seems to require that the language be extended,
and some of the commentators adverse to Mr Carters proposal considered
that the Ada language could be extended.

At this moment there seems to be no current ARG record showing that
the discussion I write on had occurred -- i.e. these URLs do not mention
the  "Re: [Ada-Comment] Update to AI-302: Discrete set"  thread topic:

AI Summary page:   http://www.ada-auth.org/AI-SUMMARY.HTML

AI-302: data structures (adding linked lists or etc.):

   http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00302.TXT

PS. Maybe a set feature would get its own AI number. Mr Brukhardt would
know if an AI on sets is going to appear.

I recently had to replace Booleans with real numbers in an attempt to
get a numerical optimizer to run faster (that largely failed). Putting
programming first and maths after that, sets ought be able to be
not-ordered vectors over any type. Disordering an array wasn't said to
clearly implied by implementation considerations.

----

>P.S. Another question, slightly offtopic, is there any server where I
>could get posting access to this group? Currently I use Google Groups.

If the ISP maybe provides access.
Anyway, there is a search engine for opn public (port 119)
Usenet servers, here:

   http://www.newzbot.com/


---  Additional Material  ---

At 2002-November-01 16:27 -0700 Friday, Jeffrey Carter wrote:
|
|    Date: Fri, 01 Nov 2002 16:27:19 -0700
|    From: Jeffrey Carter <jrcarter@acm.org>
|    To:  ada-comment@ada-auth.org
|    List-Subscribe: <mailto:listserv@ada-auth.org?body=join%20ada-comment>
|    Subject: [Ada-Comment] Update to AI-302: Discrete set
|    Reply-To: "Ada-Comment List" <ada-comment@ada-auth.org>
|
| !wording
|
| A.X.11 Discrete Set Handling
|
| The language-defined package Ada.Data_Structures.Set_Discrete provides a
| generic package each of whose instances yields a limited private type
| Handle and a set of operations. An object of a particular Set_Discrete
| Handle type represents a set over a universe defined by the generic
| discrete formal type Element.
|
| Static Semantics
|
| The library package Ada.Data_Structures.Set_Discrete has the following
| declaration:
|
|   generic
|      type Element is (<>);
|   package Ada.Data_Structures.Set_Discrete is
...
|      function "+" (Left : Handle; Right : Handle) return Handle;
|      function Union (Left : Handle; Right : Handle) return Handle
|         renames "+";
|




Here is another comment that was added to the thread on sets.
The thread died on 11 November 2002. I am guessing it might never show
up in the AI's. Which could mean that many readers of comp.lang.ada
would missed it.

Also contributors to the thread seemed generally to more for the idea
than against it. To hint at that possibility, here is a messages near
the end of the communications that contribute to the AIs. I don't
know what is happening. Mr Carter perhaps can write more on the topic.


At 2002-November-10 19:42 -0500 Sunday, Robert I. Eachus wrote:

   Date: Sun, 10 Nov 2002 19:42:23 -0500
   From: "Robert I. Eachus" <rieachus@attbi.com>
   To: Ada-Comment List <ada-comment@ada-auth.org>
   Subject: Re: [Ada-Comment] Update to AI-302: Discrete set

> There has been a lot of water over the dam in the last few days on this 
>subject, but let's not lose the baby with the bath water.  There is an 
>operation on bit arrays which is very common, and some types of software 
>do quite a lot.  That is exactly the First/Min operation discussed here. 
> You need to find the first set bit in a one or two dimensional bit 
>array, and do it fast.  Some instruction set architectures have a find 
>first bit instruction or a test and set instruction that can 
>significantly improve these operations.
>
>For example, in the LALR parser generator on Multics, this operation was 
>needed in the optimization of the state tables.  A two dimensional array 
>of from and to states was created, and optimizations were done such as 
>removing all unreachable states.  (Not as silly as it seems, earlier 
>optimizations would combine identical states and bypass "empty" 
>productions with no asociated actions.)
>
>Initially the array was stored one bit per byte, and the performance was 
>reasonable.  But then the size of the tables outgrew a single one 
>megabyte Multics segment.  Adding multisegment support slowed things 
>down seriously.  Using native Multics instructions to pack and unpack 
>bits was even slower.  So Pat Prange and I rewrote the bit search code 
>to use the translate and test character manipulating instruction.  This 
>instruction looks each byte up in a table, stops when it finds the first 
>non-zero table entry, and returns the offset in the array and table 
>entry.  Of course, we created a table that had the first bit offset for 
>the corresponding byte, and it was trivial (one more instruction) to 
>generate the actual index of the first set bit.  This code improved the 
>throughput for this pass by a factor of ten over the original 
>implementation.  Not just the bit searches, but the performance of the 
>entire pass, in part because it allowed us to use less memory.  (You can 
>do something similar on x86 with REPZ SCAS, but the termination 
>conditions are messier to sort out.)
>
>Another frequently needed operation on bit vectors is the population 
>count.  The AMD Athlon Processor Code Optimization Guide spends several 
>pages, starting at page 136, on how to do an efficient population count 
>either of 32-bit words or of 64-bit MMX values.  (The same code will 
>work on a Pentium 4, but I don't know if the 32-bit code is the most 
>efficient there due to its relatively slow integer shifts.  I just 
>happen to have an Athlon XP that I use for number and bit crunching.) 
>See 
>http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf 
>
>
>So for me, a standard package that added these operations for bit 
>vectors would be a big win.  Other than that the syntactic sugar that 
>converts a bit vector into a set is a total waste of time, at least for 
>me.  Serious bit vector operations require these two operations, and it 
>is a pain to have to use low-level programming to do them right.
>
>
>________________________________________________________
>
>You have received this message because you subscribed to the ADA-COMMENT
>mailing list. To leave the ADA-COMMENT list, send an email with
>'leave ada-comment' in the body to listserv@ada-auth.org. For help
>on the other commands available, send 'help ada-comment' to the same address.
>Problems? Send mail to agent@ada-auth.org.
>
>

Re: Reading a C record from socket - chicken / egg problem

[Wojtek Narczynski]

> Declare a structure corresponding to the fields version .. reserved
> inclusive (use Interfaces.C.unsigned_char). and read it from the socket.
> 
> Calculate the actual contentLength and paddingLength.
> 
> Use a declare block:
> 
>   declare
>     type content is array (1 .. contentLength) of Interfaces.C.unsigned_char;
>     type padding is array (1 .. paddingLength) of Interfaces.C.unsigned_char;
>     type remainder is record
>       c : content;
>       p : padding;
>     end record;
>     r : remainder;
>   begin
>     -- read r from the socket and process it
>   end;
> 
> I know this means doing 2 reads but that's the minimum.

Looks like this is not enough, because content should be read to heap
while padding should be read to stack. This adds another read.

I must take a good look at how this all is done in the original C
code...

Regards,
Wojtek