This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in pipe() and pipe2()

On 30/06/2011 5:38 AM, Corinna Vinschen wrote:
On Jun 29 15:30, Eric Blake wrote:
I was testing the behavior when pipe() fails, in order to propose an
update to POSIX wording:

However, cygwin's pipe implementation dumps core when it runs out of
fds, [...]
Expected behavior is EMFILE and fd unchanged, after however many
iterations it takes to reach the ulimit on max fd.
The problem is that Cygwin uses a placement new operator to allocate
new fhandlers.  This type of new operator calls the constructor even
if the placement pointer is NULL.  This in turn crashes in a rather
obvious way.

Since we need the placement new for fhandlers to make sure they are
allocated on the cygheap, and since there is no such operator which
only calls the constructor, I only see a very ugly workaround for this

I checked it in, together with two more fixes to avoid a crash.
If somebody has a better solution, feel free to mention it.
If you don't mind using a couple of gcc extensions (we are a gcc-only shop, right?):

#define cnew(name, ...) ({ \
void* ptr = (void*) ccalloc (HEAP_FHANDLER, 1, sizeof (name)); \
ptr? new(ptr) name(__VA_ARGS__) : NULL; \

The macro's usage would change to look like a normal function call:

fhandler_base *fh = cnew(fhandler_nodevice);

You just need to check fh != NULL afterward. If the ctor for fhandler_nodevice took an argument 'x' it would follow as additional args to the cnew macro, rather than as an additional set of parens:

fhandler_base *fh = cnew(fhandler_nodevice, x);


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]