Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-28 10:54:35

At 10:41 PM 3/27/2002, Ross Smith wrote:

>Dylan Nicholson wrote:
>> --- Ross Smith <r-smith_at_[hidden]> wrote: > Dylan Nicholson wrote:
>> > >
>> > > >
>> > > access(filename, W_OK) == W_OK?
>> >
>> > That gives you the access rights for your real user/group id, not
>> > effective user/group id -- i.e. it tells you whether the user running
>> > the process can write to the file, not whether the calling process
>> >
>> But it is the only recognised way under POSIX of determining whether a
>file is
>> writable.
>But it _doesn't_ determine that.
>The essential point I'm trying to make is that a test that can't be
>trusted is useless. Unless we can have an is_readonly() test that's
>_guaranteed_ to always give the right answer, there's no point in having
>it at all.

Agree. Although it isn't always easy to tell what "right" is.

>If is_readonly() doesn't actually tell you whether the file is
>read-only, what possible use could it be?

I just reviewed a very portable library I knew had once included a
is_readonly() function. The function actually did an fopen() to determine
the results, but it is gone now. Gradually, over time, all uses of the
function were replaced by actual application open attempts.

In other words, code that used to read like this:

    if ( is_readonly( "foo" ) ) { open "foo" for reading only }
    else { open "foo" for reading and writing }

was replace by code like this:

    open "foo" for reading and writing
    if ( open failed ) { open "foo" for reading only }

("open" might be fopen(), or, after the library was converted to C++, one
of the fstream constructors or opens).

There isn't any history of why the changes were made, but they appear to
have happened in the time frame when the library was being ported to
several new (at the time) platforms.

is_readonly() is looking like more trouble than its limited usefulness is


Boost list run by bdawes at, gregod at, cpdaniel at, john at