On 12 Mar 2010, at 3:30 PM, Joe Orton wrote:
Well, right, this the point I was making - it should be no different
at
run-time; i.e. you can achieve exactly what you want already without
adding a new interface which uses up one of the remaining bits in the
APR_FOPEN_* bitmask, must be
As nobody has offered an opinion or explanation I'll go ahead and remove
the build.conf trailing backslashes in trunk. I've verified that it
doesn't cause a problem with a Linux build so I don't expect it to cause
anyone any trouble.
Brian Havard wrote:
I'm doing a bit of work with the OS/2
On Sat, 2010-03-13 at 17:54 +0200, Graham Leggett wrote:
Based on what you've written above, the #else ENOTIMPL seems to be the
way to go. If it isn't supported, you get explicit confirmation of the
fact
Probably the safe thing to do. Probably won't get many hits, but
nevertheless.
--
Bojan
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
I'd expect to see some description of exactly what the new APR_FOPEN_*
flag changes w.r.t. method calls; does it affect just read/write, what
about flush, sync, etc? Can I presume POSIX semantics w.r.t.
O_NONBLOCK in open()? The questions
On 3/13/2010 9:54 AM, Graham Leggett wrote:
To zoom out a bit to put this into context, right now APR has no support
for non blocking behaviour at all, and this is the problem I would like
to fix. Using apr_os_file_put(), while functional, isn't portable, and
as a result a user of the API is
On 3/13/2010 5:44 PM, Bojan Smojver wrote:
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
I'd expect to see some description of exactly what the new APR_FOPEN_*
flag changes w.r.t. method calls; does it affect just read/write, what
about flush, sync, etc? Can I presume POSIX semantics
