William A. Rowe, Jr. wrote:
>Someone pointed out that we eat \r's in apr_file_gets() ... now if we
>respected the BINARY flag to open that might not be "as much" of
>a problem - but it's deeper than that...
>
>We also don't reassemble \r\n pairs in apr_file_puts() either, which
>means any file that goes while(apr_file_gets()) apr_file_puts(); will
>be corrupted. htpasswd.c is a good example of this.
>
>Now one solution would be to respect the BINARY flag, but that
>ignores the additional issue of APR_EOL_STR, and the Netware
>implementation (Unix'es) that doesn't do anything like 'dropping'
>\r's on the floor. It keeps them.
>
>If we define APR_EOL_STR, then our API's should be returning
>and assembling strings consistent with APR_EOL_STR, IMHO.
>Any other opinions or should I go ahead and apply the attached
>patch that doesn't do anything special with 'eliminating' \r's?
>
+1. Every other bit of apr_file_* code treats all files as pure binary
already. This shouldn't be an exception. We shouldn't eat \r's until we
have real translated streams, and even then, BINARY should be the
default ('cause if it isn't every existing APR app breaks).
--
Brane Čibej http://www.xbc.nu/brane/