Re: writev is "unfair".

[Andreas Jaeger]

>>>>> Sebastian Wilhelmi writes:

 > Hi,
 > As one of the co-developers of ORBit I recently ran into the following 
 > probem:

 > writev first tries to just call the kernel's writev and if that fails due to 
 > a
 > oversized array of iovec's, it calls a fallback writev implementation, which
 > in turn allocates the necessary memory on the stack (alloca), copies the
 > contents of the iovec's there and "write"s it out.

 > Now some user of ORBit wanted to transmit real big buffers of data and thus 
 > he
 > ended up with a core dump, because of stack overrun (I suspect) in the
 > fallback writev. What I am proposing now is to change the fallback
 > implementation sysdeps/posix/writev.c to alloca at most (let's say) 10KB and
 > write bigger buffers directly. There of course could be problems with error
 > reporting. I do not fully know, how to handle that 100% correctly, but I have
 > a preliminary patch attached to solve that. It is against CVS libc, but not
 > fully tested, as CVS libc does not compile on my system (name-config.h
 > missing, once that is fixed sysdeps/unix/i386/fork.S refuses to compile, 
 > maybe
 > because of gcc-2.95.2)
Which binutils version?  gcc 2.95.2 should be fine - and works for me
without problems.  That problem seems to be elsewhere.

 > I just wanted to know, if such a change would at least have the chance to be
 > included, or if it isn't possible because of e.g. diagnosis semantics, that
 > require to call write inside writev exactly once.
I can't comment on this right now,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj