On 12/07/2009 11:55 AM, Paolo Bonzini wrote:
OTOH, If all it does it log it to a file, theres a fair chance it might
succeed.
Not necessarily, for example fprintf may fail. There _may_ be a fair
chance to succeed if you use write(2) directly, but that's it
basically, and ENOMEM is always th
On 12/07/2009 10:39 AM, Ian Molton wrote:
Send what message to the host? If the malloc in the socet reconnect code
fails, its the code on the host thats going to flag up that malloc failed.
He means to management code.
> and if it does manage to receive the message, you can be almost
> cert
On 12/06/2009 01:00 PM, malc wrote:
or anything else with said bit set will yield EFAULT. Consequently the
code you cited as a well behaving malloc(0) call site will bomb.
It is not well-behaving unless the definition of EFAULT is changed
consistently.
Paolo
On 12/06/2009 01:02 PM, malc wrote:
On Sun, 6 Dec 2009, Paolo Bonzini wrote:
On 12/06/2009 11:22 AM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31s
On Sun, 6 Dec 2009, Paolo Bonzini wrote:
> On 12/06/2009 11:22 AM, malc wrote:
> > Here, i believe, you are inventing artificial restrictions on how
> > malloc behaves, i don't see anything that prevents the implementor
> > from setting aside a range of addresses with 31st bit set as an
> > indica
On 12/06/2009 11:22 AM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31st bit set as an
indicator of "zero" allocations, and then happily giving it to t
