Re: Porting APR to QNX4: portability problems.

[генерал Пурпоз <kb...@gmail.com>]

Hello dev,

The APR is really cool stuff - it has it's own implementation of the
apr_snprintf() so that it almost works even without the underlaying
int64-aware printf()|scanf().

Of the four failing tests here in the ./test/testfmt.c, three were
actually from the QNX4's native snprintf(). The fourth failure is
credited to the apr_snprintf() which handles well any unsigned value
and breaks on the signed decimal one larger or equal to (hexadecimal)
0x80000000. May be it is not even the apr_snprintf()'s fault again but
my toolchain's...

I cannot negotiate with these declarations:
#define APR_INT64_C(val) (val##LL)
#define APR_UINT64_C(val) (val##ULL)
They seems, do not change anything in the OpenWATCOM v1.6RC1...

The size of "long long" is detected to be == 8.
The formatters chosen by ./configure are:
"lld"
"llu"
respectively...

Please comment!
Thank you in advance.

-- 
Best regards,
 Anthony                   mailto:kb2wjw@gmail.com

apr_procattr_io_set() broken on win32?

[Derek Baum <de...@paremus.com>]

Hi,

I've been successfully developing using APR-1.2.7 on Unix for the last 
few months, and now I'm testing on Win/XP.

I'm launching processes like this:
>     apr_procattr_create (&attr, _pool);
>
>     // create pipes to read stdout and stderr
>     apr_procattr_io_set(attr, APR_NO_PIPE, APR_CHILD_BLOCK, 
> APR_CHILD_BLOCK);
>     
>     apr_proc_t proc;
>     stat = apr_proc_create(&proc, argv[0], argv, envv, attr, _pool);
and then reading their output in a non-blocking loop in another thread 
like this:
> for (;;) {
>         apr_size_t nbytes = sizeof(buf);
>         stat = apr_file_read(_proc.out, buf, &nbytes);
>
>         if ((stat != APR_SUCCESS) || (nbytes == 0)) break;
>               _out.append(buf, nbytes);
>         }
> }

This all works fine on Unix, but on Windows, the read blocks, even 
although I call apr_procattr_io_set() to set the parent end of the pipes 
to non-blocking.

The reason for this appears to be a problem in 
apr_create_nt_pipe(file_io/win32/pipe.c), which initialises the 
apr_file_t.timeout fields to -1 (blocking), and does not reset them to 0 
(zero-timeout) if a non-blocking mode has been requested:

Setting these timeouts to zero in my application code, solves the 
problem, although to do this I had to hack into the opaque 
apr_procattr_t structure:
> struct apr_procattr_hack {
>     apr_pool_t *pool;
>     apr_file_t *parent_in;
>     apr_file_t *child_in;
>     apr_file_t *parent_out;
>     apr_file_t *child_out;
>     apr_file_t *parent_err;
>     apr_file_t *child_err;
> };
>
> // add after apr_procattr_io_set() in first code snippet above
> apr_file_pipe_timeout_set(((apr_procattr_hack*)attr)->parent_out, 0);
> apr_file_pipe_timeout_set(((apr_procattr_hack*)attr)->parent_err, 0);

Can you confirm that this is a problem, or am I doing something wrong?
If it is a problem, should I log it as a bug?

Thanks,

Derek


________________________________________________________________________
The information transmitted is intended only for the person(s) or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer. 

Paremus Limited.
107-111 Fleet Street, London EC4A 2AB.  Phone number +44 20 7936 9098
________________________________________________________________________