Yes, I can confirm that this should not happen by design. Happy hacking!
Christian On 02/10/2014 11:48 AM, Martin Velek wrote: > This is only "what if" question. I am using the MDH on an embedded > device and I need to take into consideration all possible input > alternatives. I am using two assertions, NULL != buf, max > 0, they > were never activated. > > If you can provide an assurance that it should not happen, it is not > an intented usecase, that's ok for me (mental peace). I did inspection > of the source code and I think it should not happen. > > Best > Martin > > On Mon, Feb 10, 2014 at 11:19 AM, Christian Grothoff <[email protected]> > wrote: >> Hmm. That's, eh, interesting. MHD should simply not call you >> asking for zero bytes. Got a testcase or a (gdb) call trace >> for me? Or is this a hypothetical question to answer the case >> "what if MHD did do that?"? >> >> Happy hacking! >> >> Christian >> >> On 02/10/2014 10:50 AM, Martin Velek wrote: >>> Hello, >>> >>> I am trying to write a robust MHD_ContentReaderCallback callback. >>> However I cannot imagine how to handle a situation when MHD calls my >>> callback with the provided buffer size equal to 0 (I am running >>> internal select mode). The documentation does not state it as an >>> impossible situation. >>> >>> I can't return 0 because of the internal select mode. >>> I can't return MHD_CONTENT_READER_END_* because I would like to handle >>> the request. >>> >>> >>> Best >>> Martin >>> >
0x48426C7E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
