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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs