nil instead of EOF

[John Joyce]

Seeing as how Ruby will return nil when an I/O stream is empty,
is there anything wrong with using nil where other languages might
use EOF ?
As in this example:

File.open("text.txt") do |f|
puts f.gets(nil)
end

 

[Gary Wright]

Seeing as how Ruby will return nil when an I/O stream is empty,
is there anything wrong with using nil where other languages might
use EOF ?
As in this example:

File.open("text.txt") do |f|
puts f.gets(nil)
end

It isn't clear what you are asking. gets(nil) has a well-defined
behavior
right now, it means to return the remaining data in the IO stream (i.e.,
until the end of file is encountered).

It sounds like you are thinking of EOF as an in-band but special
character
value that marks the end of file. It is better to think of it as an
out-of-band sentinel value. In C, EOF is usually -1 and the associated
API specifies integer return values so that EOF is guaranteed to
never be confused with a valid in-band value.

In C, getc has to be defined to return an integer value so that
characters (0..255) and EOF (-1) are both statically valid but
can be differentiated. In Ruby, getc can return a fixnum or nil since
there is no need to statically define the return value of methods.

In C, gets returns a pointer to a string or NULL to indicate there is
no data (end of file has been reached). In Ruby gets returns a
reference
to a string or nil when end of file has been reached.

I would be careful about thinking of nil and EOF (as in C) as
interchangeable. They serve similar purposes but the APIs and languages
are sufficiently different that I wouldn't push that analogy too far.

Gary Wright

 

[John Joyce]

It isn't clear what you are asking. gets(nil) has a well-defined
behavior
right now, it means to return the remaining data in the IO stream
(i.e.,
until the end of file is encountered).

It sounds like you are thinking of EOF as an in-band but special
character
value that marks the end of file. It is better to think of it as an
out-of-band sentinel value. In C, EOF is usually -1 and the
associated
API specifies integer return values so that EOF is guaranteed to
never be confused with a valid in-band value.

In C, getc has to be defined to return an integer value so that
characters (0..255) and EOF (-1) are both statically valid but
can be differentiated. In Ruby, getc can return a fixnum or nil since
there is no need to statically define the return value of methods.

In C, gets returns a pointer to a string or NULL to indicate there is
no data (end of file has been reached). In Ruby gets returns a
reference
to a string or nil when end of file has been reached.

I would be careful about thinking of nil and EOF (as in C) as
interchangeable. They serve similar purposes but the APIs and
languages
are sufficiently different that I wouldn't push that analogy too far.

Gary Wright

Thanks for the input. I hear you and already have the difference in
my mind. Just that for those coming from other languages, especially
the dive-in-with-only-online materials types, this might be a useful
point.
I know what you mean already though, about EOF in Ruby. It's just
that I've seen other posts where there was some confusion about that.
I guess I'm just wondering if using nil in this manner is indeed
appropriate, or if there is some check or hole that needs performing.
Coming from other languages this is often more of a concern. The way
Ruby's objects work does a great deal to protect us from hosing
things the way you can with C or C++ . Ruby certainly performs as I
am often least surprised. (perhaps living in Japan for a long time
does something to make Ruby make sense.)