On Thu, Feb 25, 2016 at 06:44:19PM +0300, Nick Zavaritsky
wrote:
> >> 1) UB from the libev point of view, or
> >> 2) works with certain versions of libev on certain OSes, but may break
> >> without warning, or
> >> 3) is fully supported and is a part of the public API contract.
> >
> > It's cer
Hi,
>> 1) UB from the libev point of view, or
>> 2) works with certain versions of libev on certain OSes, but may break
>> without warning, or
>> 3) is fully supported and is a part of the public API contract.
>
> It's certainly 1 or 2.
I am glad it was stated in clear now.
Remember a discussi
On Thu, Feb 25, 2016 at 12:47:15PM +0300, Nick Zavaritsky
wrote:
> 1) UB from the libev point of view, or
> 2) works with certain versions of libev on certain OSes, but may break
> without warning, or
> 3) is fully supported and is a part of the public API contract.
It's certainly 1 or 2.
Even
Hi,
>> Hi Mark,
> Still Marc, btw.
Please kindly excuse me for the typo.
>> Libev provides ev_set_syserr_cb() to customise error handling.
>>
>> I wonder, if longjump-ing from a error handler is supported.
>
> libev can't stop you, longjmp is part of the C language.
Well, since pointers are
On Wed, Feb 24, 2016 at 07:35:13PM +0300, Nick Zavaritsky
wrote:
> Hi Mark,
Still Marc, btw.
> Libev provides ev_set_syserr_cb() to customise error handling.
>
> I wonder, if longjump-ing from a error handler is supported.
libev can't stop you, longjmp is part of the C language.
> Consider a
Hi Mark,
Libev provides ev_set_syserr_cb() to customise error handling.
I wonder, if longjump-ing from a error handler is supported.
Consider a longjump removing all libev frames from the stack and landing at
some location that was set up earlier.
Are we going to get any leaks inside libev? Is
