Re: [libmicrohttpd] Repeated calls to MHD_AccessHandlerCallback

[Martin Bonner]

Excellent.  (That was what I had thought from a quick read of the code, 
but I wasn't sure a) if I was right; b) if it was an accident of the
current implementation, rather than something I could rely on.)

Thanks for the rapid response.

Violate const?  Um, never _deliberately_.

-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Christian Grothoff
Gesendet: Donnerstag, 5. November 2015 16:49
An: address@hidden
Betreff: Re: [libmicrohttpd] Repeated calls to MHD_AccessHandlerCallback

Hi!

Yes, 'conCls' is guaranteed to be NULL on the first call (per request) and
whatever you left in it henceforth.  Also, 'url', 'method' and 'version'
will always point to the same location in memory for the duration of the
request, and unless your application violates 'const' they won't change.


Happy hacking!

Christian

On 11/05/2015 04:27 PM, Martin Bonner wrote:
> I have a question about the con_cls argument to MHD_AccessHandlerCallback.  
> 
> Is it safe to assume that if *conCls is non-null, then the connection, 
> url, method, and version arguments will be unchanged from when *conCls 
> _was_ null?
> 
> In other words, would a callback like the following be OK:
> 
> int AccessHandlerCallback( void *cls, MHD_Connection* connection, 
>         const char* url, const char* method, const char* version, 
>         const char* uploadData, size_t* uploadDatasize, void **conCls) 
> {
>     Session* session = (Session*)conCls;
>     if (!session)
>       *conCls = session = MakeSession( connection, url, method );
>     return  HandleRequest(session, uploadData, uploadDatasize); }
> 
> .. given that MakeSession stores its argument in the returned Session object.
> (Yes, in reality, MakeSession is a C++ constructor, and HandleRequest 
> is a member function, but the principle is the same.)
> 
> Actually, there are two levels of guarantee.  One is that the pointers and
> the values they point at are unchanged.   The second is that the strings
> are always the same (but not necessarily at the same address) - in 
> which case I need to take a copy of the strings.
> 
>