Stdout "not equal to itself"?

Users
1

Hello: I would expect the code below,

use IO;
var f = stdout;
f.writeln("hello");
again(f);
proc again(
   const in g: fileWriter(true)
   ) {
   if g == stdout {
      g.writeln("hello again");
   }
}

to print two lines:

hello
hello again

But it only prints the first. I would appreciate to know why :slight_smile:

2

Hi Nelson —

This looks like a bug to me, as I'd expect the same behavior as you.

Digging into it a little bit, it appears to me that it's a result of internal fields of the fileWriter type not being identical and/or the type (or its field types) not defining a custom == operator to deal with that fact, but I am not 100% confident. If you would open a bug report issue for this on our GitHub repository, I think that would be ideal. Note that most of our team at HPE is off for the next few weeks, so a fix would probably happen in the new year.

Notes for developers: I added the following writeln()s to Nelson's code:

   writeln((g.locking, stdout.locking));
   writeln(g.locking == stdout.locking);
   writeln((g.serializerType:string, stdout.serializerType:string));
   writeln(g._serializer.type:string ==stdout._serializer.type:string);
   writeln(g._serializer == stdout._serializer);
   writeln((g._home.id, stdout._home.id));
   writeln(g._home == stdout._home);
   writeln((g._channel_internal, stdout._channel_internal));
   writeln(g._channel_internal == stdout._channel_internal);
   writeln((g._readWriteThisFromLocale, stdout._readWriteThisFromLocale));
   writeln(g._readWriteThisFromLocale == stdout._readWriteThisFromLocale);

and got a false for the comparison between serializers. I started to look into adding a custom == operator for _serializeWrapper or comparing the objects and individual _serializeWrapper fields, but timed out before completing.

-Brad

3

Thanks Brad: I just filed bug issue #28247.

Regards

Nelson

1 Like
4

Hi Nelson —

Thanks very much for filing this issue. This should be fixed on main, now, though please be sure to read the note in [Bug]: fileWriter argument checks false against stdout, when it should be true · Issue #28247 · chapel-lang/chapel · GitHub if you haven't already, which has some suggestions for arguably better / less ambiguous style for this pattern for consideration and the related issue Should copying a fileReader/Writer "alias" the original or produce a new one (e.g., with unique cursor) · Issue #28268 · chapel-lang/chapel · GitHub that it refers to.

Thanks again, and best wishes,
-Brad

5

Thanks Brad. I still have the (bad) habit of declaring vars where more accurately objects should be consts. This is clearly the case when dealing with a single fileReader/Writer that only needs to be opened, read/written, and closed. I believe I can trace this habit of mine back to a time when "consts" in pascal were most of the time integer or real consts, and in C were macros with #defines --- not to mention that in Fortran 66/77 the concept was even fuzzier. Of course, one can now declare a constant file pointer in C, or constant file reader / writer in Chapel, etc. Which teaches me that more structured objects such as arrays, records and files should be declared constant whenever possible. Regards,

Nelson

6

Hi Nelson —

Makes sense and I'm always happy to find a kindred spirit in Pascal.

Note, though, that it's the ref aspect of that comment that's key rather than the const aspect, as a means of saying "I'd like to refer to this existing thing rather than creating something new). The const is also necessary because stdout is a const, and Chapel won't permit a (modifiable) ref to refer to a const declaration, so const ref keeps the reference read-only.

Happy 2026,
-Brad