Algol 68 open, book, channel RFC

[Jose E. Marchesi]

Hi Chris.

> Thanks Jose, really appreciated.  Updated idea at end, please take a look.
>
> On Sun, Jun 7, 2026 at 10:45 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> Hi Chris.
>>
>> > Me again,
>> >
>> > I came to a few provisional decisions tonight.
>> >
>> > van Vliet has his open call a procedure find_book_in_system (which is
>> > nowhere else used).  I changed this to attempt_to_open_and_link:
>> > - no buffer is involved (because I will let POSIX routines handle the
>> > buffering for now)
>> > - I need somewhere to put the file descriptor returned by the POSIX open,
>> > so attempt_to_open_and_link will put it in the Book
>>
>> Makes sense to me.
>>
>> > - I'm not messing with fstat nor access nor any of that because of this
>> > warning I see in the access man page:
>> >
>> >        Warning: Using these calls to check if a user is authorized to,
>> for
>> > example, open a file before actually doing so using open(2) creates a
>> > security hole, because the user might exploit the short time interval
>> > between checking and opening the file to manipulate it.  For this reason,
>> > the use of this system call should be avoided.  (In the example just
>> > described, a safer alternative would be to temporarily switch the
>> process's
>> > effective user ID to the real ID and then call open(2).)
>> >
>> > So, yeah, "just call open" (and similarly for establish and create).
>> >
>> > The POSIX open, when it fails, doesn't really play well with van Vliet's
>> > "channel preferences" - for example, EACCES is a bit of an omnibus error:
>> >
>> >     The requested access to the file is not allowed, or search permission
>> > is denied for one of the directories in the path prefix of path, or the
>> > file did not exist yet and write access to the parent directory is not
>> > allowed.
>> >
>> > I guess I can reflect on what I wanted vs the POSIX errno code and puzzle
>> > it out, but for now I'm just going to signal van Vliet's "badidf" error.
>> >
>> > Anyone who would like to argue with these provisional decisions, please
>> do!
>>
>> Ok so when you do transput open:
>>
>>   open (ref File file, string idf, Channel chan) int
>>
>> the channel through which open the file specifies the mode in which to
>> attempt the opening:
>>
>>   stand_in_channel opens a filesystem file read-only.
>>   stand_out_channel opens a filesystem file write-only.
>>   stand_back_channel opens a filesystem file in read-write mode.
>>
>> IMO it makes sense to, for example, fail the open call if a book
>> (filesystem file) cannot be found for the given idf that allow reading.
>> Ditto for the other channels: opening a filesystem file through
>> stand_back_channel requires both read and write permissions, whereas a
>> filesystem file (book) opened through the stand_out_channel requires at
>> least write permissions to success.
>>
>> Given the above doesn't fail, then after "open", as the report says:
>> "The available methods of access to a book which has been opened on a
>> file may be discovered by calls of the following routines[...]:
>> get_possible, put_possible, etc.
>>
>
> Ok.  I'm proposing this alternative to just returning "badidf"
>
> 1. add one more error code to van Vliet's list: "noreadwrite"
> 2. add two errno code definitions:
>    a. error_noent (corresponds to ENOENT)
>    b. error_acces (corresponds to EACCES)
> 3. look at the POSIX error number related to a failed fopen:
>    a. if error_noent return badidf
>    b. if error_acces:
>       i. if open tried POSIX flag file_o_rdwr return noreadwrite
>       ii. if open tried POSIX flag file_o_wronly return nowrite
>       iii. if open tried POSIX flag file_o_rdonly return noread
>       iv. otherwise return notavail
>    c. otherwise return notavail
>
> Does this make more sense?  Here are van Vliet's error codes related to
> opening a file:
>
> (2) 'badidf' - The string argument to 'open' or 'establish' is wrong; in
> 'establish', the given string cannot be used as the identification string
> of a new book, in 'open', no matching book is found.
> (3) 'nowrite' - Writing cannot be done (either the file requested cannot be
> written or the channel does not permit writing)
> (4) 'not avail' - At this instance of time, another file may not be
> "opened", "created" or "established" on the given channel. (This may be a
> temporary problem which can be handled by retrying the calling of 'open',
> 'create' or 'establish' - for instance, there is no room in the directory
> system for a new file.)
> (5) 'noestab' - 'estab possible(chan)' returns false: files simply cannot
> be established on this channel.
> (6) 'posmax' - One of the dimension arguments to 'establish' or 'set' is
> too large.
> (7) 'posmin' - One of the dimension arguments to 'establish' or 'set' is
> too small (i.e., ≤ 0)
> (9) 'noread' - Reading cannot be done (either the file requested cannot be
> read or the channel does not permit reading)
>
> I'm proposing to add
>
> (31) 'noreadwrite' - Reading and writing cannot be done (either the file
> requested cannot be both read and written or the channel does not permit
> reading and writing)

I personally think `badidf' is good for this case and wouldn't add an
additional error code.  This is because at this level `open' is very
abstract and its interpretation is all up to the device backed by the
used channel: an idf may contain a file path, but also permissions,
passwords, etc.  With stand_in_channel, for example, the backed physical
device is the filestore and the books are files that can not be written,
but that can be read.  If no such filesystem file is found given the
idf, then it is the idf that is wrong.

If you really must add an extra error code, why not reusing noread and
nowrite?  They are clearly intended to be used in transput (put, etc)
but they may also be returned by open with the obvious meaning.