[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