When you say it breaks the API, how is that? It seems that before this fix, if you pass in a NULL "from" parameter, you'll get a segmentation fault when apr_socket_recvfrom() passed dereferences &from->sa and &from->salen as params to recvfrom(2). So the change in behavior is instead of SEG'ing, you get a no-op. Is that considered breaking the API?
I'm new to the list, so please forgive me if I don't understand. Thanks. Dave > -----Original Message----- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > Sent: Monday, November 13, 2006 10:50 AM > To: Jim Jagielski > Cc: Garrett Rooney; APR Development List > Subject: Re: apr_socket_recvfrom > > +1 - I don't see an issue with a throwaway retval if it's the desire > of the end user. > > Because this behavior breaks the API (do this in APR 1.2 and your code > will implode on 1.2.7) can we push this at 1.3.0? > > Bill > > Jim Jagielski wrote: > > > > On Nov 10, 2006, at 3:56 PM, William A. Rowe, Jr. wrote: > > > >> Garrett Rooney wrote: > >>> On 11/10/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: > >>>> Anyone have issues with me making from an > >>>> optional argument, i.e. allowing from to be > >>>> NULL and apr_socket_recvfrom() doing the Right > >>>> Thing? > >>>> > >>>> In other words, making it more recvfrom()-like? > >>> > >>> Seems reasonable to me. > >> > >> Can you splash up to the list what the new .h doxygen comments would > >> look like? > >> > > > > /** > > * Read data from a socket. On success, the address of the peer from > > * which the data was sent is copied into the @param from parameter if > > not NULL, > > * and the @param len parameter is updated to give the number of bytes > > * written to @param buf. > > * @param from if not NULL updated with the address from which the data > > was received > > * @param sock The socket to use > > * @param flags The flags to use > > * @param buf The buffer to use > > * @param len The length of the available buffer > > */ > > > > > > > >
