# Nil instead of EOF

**URL:** <https://www.ruby-forum.com/t/nil-instead-of-eof/92745>\
**Category:** Ruby\
**Created:** [April 23, 2007, 6:39pm UTC](https://www.ruby-forum.com/t/nil-instead-of-eof/92745 "2007-04-23T18:39:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![john\_old](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9f8e36/32.png) [@john\_old](https://www.ruby-forum.com/u/john_old)\
**Post date:** [April 23, 2007, 6:39pm UTC](https://www.ruby-forum.com/t/nil-instead-of-eof/92745/1 "2007-04-23T18:39:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![john\_old](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9f8e36/32.png) [@john\_old](https://www.ruby-forum.com/u/john_old)\
**Post date:** [April 23, 2007, 8:02pm UTC](https://www.ruby-forum.com/t/nil-instead-of-eof/92745/2 "2007-04-23T20:02:36Z")

</div>

On Apr 23, 2007, at 12:38 PM, John J. wrote:

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

---

<div class="post-metadata">

**Author:** ![john\_old](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9f8e36/32.png) [@john\_old](https://www.ruby-forum.com/u/john_old)\
**Post date:** [April 23, 2007, 8:32pm UTC](https://www.ruby-forum.com/t/nil-instead-of-eof/92745/3 "2007-04-23T20:32:39Z")

</div>

On Apr 24, 2007, at 3:01 AM, Gary W. wrote:

> > end  
> > out-of-band sentinel value. In C, EOF is usually -1 and the  
> > 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 W.

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