apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Ruppert ...@myarm.com>
Subject Re: buffered files read after apr_file_close()'ed
Date Tue, 03 Dec 2013 14:55:25 GMT
Am 03.12.2013 15:15, schrieb Daniel Lescohier:
> A null pointer will cause a segmentation fault.  Is it guaranteed that
> the memory page that the pointer 0xdeadbeef points to is one that is not
> marked readable & writable, so that one would get a segmentation fault
> on reading/writing to it?

A null pointer will not cause a segmantation fault on all systems. For 
example AIX will silently ignore a dereferencing of a null pointer 
resulting in unexpected behaviour. But your question about 0xdeadbeef is 
still valid. Its a common practice in memory debugging libraries to mark 
free'd memory with a pattern which is unlikely a valid pointer. However 
it depends on the OS and its memory management if 0xdeadbeef is invalid 
or not. But from my knowledge most OSes uses only the lower half of the 
address space for user processes.

> However, the functions still need to change to return errors for the
> cases when they are unbuffered files.  The buffer won't be referenced
> (and cause a crash) in those cases.

But in this case the OS will return an EBADF if read() or write() is called.

> I think the read/write functions should also do *nbytes=0 when filedes<0
> so caller's loops will stop looping.
> In addition, apr_file_eof should return an error APR_EBADF:

Some sanity checks can help but does not have to...


View raw message