Guarding against uninitialized variables RFC

chris hermansen clhermansen@gmail.com
Mon Jun 22 18:20:20 GMT 2026


Good morning everyone, thanks for the comments.

On Mon, Jun 22, 2026 at 6:27 AM Paul Leyland <paul.leyland@gmail.com> wrote:

> > Date: Mon, 22 Jun 2026 00:03:58 +0200
> > From: "Jose E. Marchesi"<jemarch@gnu.org>
> > To: chris hermansen<clhermansen@gmail.com>
> > Cc:algol68@gcc.gnu.org
> > Subject: Re: Guarding against uninitialized variables RFC
> > Message-ID:<87ik7by2i9.fsf@gnu.org>
> > Content-Type: text/plain
> >
> > Good day everyone,
> >
> > After 10 days away from almost everything to do with computers in order
> to
> > concentrate on Important Stuff (like beaches), I'm back prodding van
> > Vliet's transput.
> >
> > The open, establish and create procedures will fail with a non-zero
> return
> > code if they cannot establish the linkage between File, Channel, Book and
> > the operating system file.  However this can leave the nonpublic Book
> > variable in an uninitialized state.
> >
> > Of course, I can initialize the Book variable to some pattern that I can
> > later interpret as meaning no linkage was created; and I can check
> wherever
> > that Book variable is used to make sure it has a valid linkage.
> >
> > But I don't believe there is a way to detect uninitialized variables
> other
> > than this.
> >
> > Does anyone have any suggestions?  Thanks in advance!
> >
> > I think there is no way.
> >
> > In strict Algol 68 the value actually held by uninitialized variables is
> > undefined.
> >
> > In GNU Algol 68 uninitialized variables all have a predictable value: 0
> > for int, 0.0 for real, " " for char, etc.
> >
> > But that will not really help to detect uninitialized variables.
> >
> > I would look to declare a no_book identifier with some distinguishable
> > value ascribed to it, then get the books initialized to it, then check
> > for it before accesses.  Alternatively, you could add an additional
> > book_initialized boolean.
>
> Adding a boolean is by far the most robust way of dealing with this
> issue.  "Special" values which "never" get used all too often become not
> special and are eventually used.
>
> My strongly held opinion anyway.
>

In general I like this idea (of a dedicated flag value).

In the specific case of the Book mode, and at least for my first go-around
with this transput stuff where I'm wrapping POSIX open to do my
system-level work for me, I'm storing the result of POSIX open as int
posix_file_descriptor in the Book.  If POSIX open fails, this value is -1
(not a legal file descriptor).

So rather than having two indicators, for now I'm going to use
posix_file_descriptor = -1 as the 'uninitialized Book indicator', which
shows that either I haven't open-ed the associated file as yet or the open
/ establish / create failed.


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260622/d46f8b47/attachment.htm>


More information about the Algol68 mailing list