Am Fri, 11 Apr 2014 22:52:23 -0400 schrieb "Steven Schveighoffer" <[email protected]>:
> On Fri, 11 Apr 2014 18:01:29 -0400, Marco Leise <[email protected]> wrote: > > >> But in a D-created struct, the data would be an array, instead of a > >> ptr+length. > >> > >> -Steve > > > > If I understand you right, you mean a variation of this: > > > > struct Packet { ubyte[] payload; } > > > > But indirections don't fly with serialized network packets. > > Indirections were in the struct that was the subject of that article. Here > it is: > > typedef struct ssl3_record_st > { > int type; /* type of record */ > unsigned int length; /* How many bytes available */ > unsigned int off; /* read/write offset into 'buf' */ > unsigned char *data; /* pointer to the record data */ > unsigned char *input; /* where the decode bytes are */ > unsigned char *comp; /* only used with decompression - > malloc()ed */ > unsigned long epoch; /* epoch number, needed by DTLS1 */ > unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */ > } SSL3_RECORD; > > No way that's a directly serialized network packet. > > -Steve If "data" and "length" are the pointer and size of the raw network packet, yes. I.e. it will turn into: ssl3_record_st.data[] = socket.receiveRawPacket(); ... which is safe. But when you said "D created struct" I assumed you referred to the network packet itself as a struct, which means that the length field would come directly from the client and doesn't need to match the physical length of the packet. With Kagamin's reply I now understand it better. -- Marco
