Guarding against uninitialized variables RFC

chris hermansen clhermansen@gmail.com
Sun Jun 21 22:31:26 GMT 2026


Thanks Jose!

On Sun, Jun 21, 2026, 15:04 Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > 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..
>

Ok my Book mode contains a field to hold the file descriptor associates
with the system file, so I will initialize it to -1.

I will need to conduct a similar investigation with mode File.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260621/c665eb87/attachment.htm>


More information about the Algol68 mailing list