Hi, What I have in mind would also require editing all calls to send_msg_iservice() which is essentially what Gert is objecting to. So ignore me -- a separate send_msg_iservice_ex may be the best option.
Selva On Tue, Jun 25, 2019 at 5:00 PM Selva Nair <selva.n...@gmail.com> wrote: > > Hi, > > On Tue, Jun 25, 2019 at 4:38 PM Lev Stipakov <lstipa...@gmail.com> wrote: > > > > Hi, > > > >> > >> The way interactive service structures are coded should not require > >> this at all, does it? The size and message type are already in the > >> header, so why do we need to pass it? > > > > > > But we need to know the response size in send_msg_iservice() since > > we pass it to ReadFile(). So far we assumed that response is always > > ask_message_t > > and we could do sizeof(*ack). With new response type this assumption > > doesn't hold so > > as Gert suggested I added another version which accepts arbitrary response > > type and size. > > My point is that, this is not in the spirit of the rest of iservice code. See > HandleMessage in interactive.c where the data is and then interpreted > using the header type and size. > > For what max-size to pass to ReadFile, we know it from the size in the header > element of the struct. > > Selva > > > > > > bool > > send_msg_iservice(HANDLE pipe, const void *data, size_t size, > > ack_message_t *ack, const char *context) > > { > > return send_msg_iservice_ex(pipe, data, size, ack, sizeof(*ack), > > context); > > } > > > > bool > > send_msg_iservice_ex(HANDLE pipe, const void *data, size_t size, > > void *response, size_t response_size, const char > > *context) > > { > > > > Will send V2 tomorrow with this and CreateFileW changes. > > > > > > -- > > -Lev _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel