[tor-bugs] #21416 [Core Tor/Tor]: util/fgets_eagain test failure on FreeBSD

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Feb 8 14:00:48 UTC 2017


#21416: util/fgets_eagain test failure on FreeBSD
--------------------------+---------------------
 Reporter:  ahf           |          Owner:  ahf
     Type:  defect        |         Status:  new
 Priority:  Low           |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Minor         |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+---------------------

Comment (by ahf):

 I've run the attached test case on a couple of targets thanks to some help
 by some friends on IRC.

 Linux with glibc:

 {{{
 feof()   = 0
 ferror() = 1
 retptr   = 0x7ffcefd02030
 }}}

 Linux with musl-libc (Thanks to Somasis):

 {{{
 feof()   = 0
 ferror() = 1
 retptr   = 0
 }}}

 FreeBSD:

 {{{
 feof()   = 0
 ferror() = 1
 retptr   = 0x0
 }}}

 OpenBSD (Thanks to Kramse):

 {{{
 feof()   = 0
 ferror() = 1
 retptr   = 0x7f7ffffbfd40
 }}}

 OS X

 {{{
 feof()   = 0
 ferror() = 1
 retptr   = 0x7fff5d37d710
 }}}

 It seems like the assumption that the returned pointer value is always the
 same as the input buffer in this case is incorrect for some of our
 supported operating systems.

 Should we consider making a `tor_fgets` in our compatibility layer, which
 checks for `ferror(file) == 1` and `errno == EAGAIN` and in that case
 returns `NULL`?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21416#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list