Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site cuuxb.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!nwuxg!cuuxc!cuuxb!dbaker From: dbaker@cuuxb.UUCP (Darryl Baker) Newsgroups: net.bugs.4bsd,net.unix-wizards,net.bugs.usg Subject: Re: Bug in isatty (all systems!) Message-ID: <243@cuuxb.UUCP> Date: Thu, 18-Jul-85 06:29:38 EDT Article-I.D.: cuuxb.243 Posted: Thu Jul 18 06:29:38 1985 Date-Received: Sat, 13-Jul-85 08:24:49 EDT References: <726@mcvax.UUCP> <965@sdcsvax.UUCP> Reply-To: dbaker@cuuxb.UUCP (Darryl Baker) Organization: AT&T Technologies CSD, Lisle, Il. Lines: 25 Xref: watmath net.bugs.4bsd:1603 net.unix-wizards:13795 net.bugs.usg:249 In article <965@sdcsvax.UUCP> jww@sdcsvax.UUCP (Joel West) writes: >> The following short C program >> >> main(){ >> extern int errno; >> >> errno = 0; >> putchar('\n'); >> if(errno > 0) >> perror("perror"); >> } >> >> gives unexpected results. .... Stuff deleted to save space and keep people interested. .... >The other 'gotcha' (same systems) is mktemp, which attempts >to build a unique file name. errno is always 2 (file not >found) after successfully calling mktemp on these 3 systems. Now I am not going to go into a long explanation of poor coding, but aren't you supposed to check return values for errors. Lots of section 3 routines call things from section 2 that set errno. Also isn't also true that the intro to section 2 states that errno is not cleared on successful calls.