[PATCH 1/1] hwclock: Verify RTC file descriptor; use reentrant functions
Isaac Dunham
ibid.ag at gmail.com
Sat May 3 00:38:48 UTC 2014
On Fri, May 02, 2014 at 06:11:41PM +0000, Bryan Evenson wrote:
> Denys,
>
> > -----Original Message-----
> > From: Denys Vlasenko [mailto:vda.linux at googlemail.com]
> > Sent: Friday, May 02, 2014 3:10 AM
> > To: Bryan Evenson
> > Cc: Ralf.Friedl at online.de; busybox; griebl at gmx.de
> > Subject: Re: [PATCH 1/1] hwclock: Verify RTC file descriptor; use reentrant
> > functions
> >
> >
> > I don't see how this can happen. Do you have evidence rtc_xopen() did
> > return a result less than zero?
>
> I don't have evidence, but that seemed to be the most likely result through code inspection. rtc_xopen() returns the result of xopen(), which returns the result of open(). open() returns -1 if an error occurred, meaning rtc_xopen() could return -1 if an error occurred opening the rtc file.
>
...except that xopen() does not just return the result of open().
xopen() calls xopen3(), which has this:
ret = open(pathname, flags, mode);
if (ret < 0) {
bb_perror_msg_and_die("can't open '%s'", pathname);
}
bb_perror_msg_and_die should do exactly what it says: exit verbosely.
So no, xopen() cannot ever return -1 unless you have a broken compiler.
rtc_xopen() similarly cannot return -1.
As a rule of thumb, all the x*() functions will abort if they do not
succeed.
HTH,
Isaac Dunham
More information about the busybox
mailing list