Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jun 1998 15:59:14 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        fenner@parc.xerox.com (Bill Fenner), current@FreeBSD.ORG
Subject:   Re: Bogus errno twiddling by lstat... 
Message-ID:  <199806210759.PAA27365@spinner.netplex.com.au>
In-Reply-To: Your message of "Fri, 19 Jun 1998 18:51:20 GMT." <199806191851.LAA12551@usr06.primenet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> > >> 1: This is a classic programming error.. You're not really supposed to b
    e 
> > >> looking at the value of errno except right after a -1 return from 
> > >> something.
> > >
> > >I know I'm not supposed to be.  However, it's not supposed to be diddling
> > >the errno.
> > 
> > The ANSI C standard says that unless stated otherwise in the standard
> > (e.g. the math functions), library functions may change errno even if
> > there is no error.
> 
> On the other hand, they may leave it alone.

Yes, which is why I changed malloc().

> Look, what I was surprised at was the multiple attempts to open
> malloc.conf after the first failure in crt0's use of ld.so.

What system is doing this?  -current and -stable don't do this.  I don't 
have anything older to test but as near as I can tell from the changelogs, 
this hasn't changed for a long time..  Incidently, ld.so had it's own 
malloc() until november '97, and even that was based on the old libc 
pre-phkmalloc which didn't look at malloc.conf.

> This alarm comes from somewhere that I can't at present identify: A
> system call in SCO Xenix whose failure detection requires the setting
> of errno to zero and on a return from the call (whose return value
> does not have a namespace incursion like "-1" or "NULL" that can
> be relied upon as an error indicator), comparing errno to zero to
> see if it was successful (if I recall correctly, the failure case
> returned EWOULDBLOCK).

What on earth are you doing?  Are you complaining about FreeBSD or SCO 
Xenix?  Or trying to run Xenix sources?  Or Xenix binaries under the 
emulator?  Or something else??

> I admit that this is terribly bogus, but it's the ABI, so live with it.

Xenix ABI?  So you are running binaries?  Then it's most likely the syscall
emulation that has a problem and that's within the kernel not libc where 
errno lives.

> So the question becomes: "At what point can I expect a library routine
> to behave like a system call"?

Only when it's documented to behave like a system call.

> Consider:
> 
> 	errno  = 0;
> 	printf( "testing for FreeBSD without malloc.conf....\n");
> 	if( errno == ENOFILE) {
> 		printf( "Sorry, your system is misconfigured!\n");
> 		exit( 1);
> 	}

.. would probably cause a compile failure.. ENOFILE doesn't exist.  I 
assume you mean ENOENT?

On a system with the *old* malloc that returns ENOENT at first call:

pwroot@spinner[3:46pm]/tmp-143# cat yy.c
#include <stdio.h>
#include <errno.h>

main()
{
        printf("ACME super stupid useless test program\n");
        printf("testing for foo\n");
        /* test something */
        printf("testing for bar\n");
        /* test something else */
        errno = 0;
        printf("testing for FreeBSD without malloc.conf....\n");
        if (errno != 0) {
                printf("Sorry, your system is well within it's rights but not what Terry wants\n");
                exit(1);
        } else
                printf("OK, printf didn't change errno\n");
}
spinner[3:46pm]/tmp-144# cc -o yy yy.c
spinner[3:46pm]/tmp-145# ./yy
ACME super stupid useless test program
testing for foo
testing for bar
testing for FreeBSD without malloc.conf....
OK, printf didn't change errno
spinner[3:46pm]/tmp-146#

Of course, this is a bogus test.  It also shows that printf() and malloc() 
are fine after the malloc at stdio init.  In order to get the test that 
you want, you'd have to do it as a self contained program that tested 
nothing else but the printf().  If you do something that calls malloc, 
you'll loose the side effect that you're testing for.

> This is especially an issue for POSIX threads implemented as a user
> space call conversion scheduler; they are, in fact, library routines
> which wrap system calls.
> 
> POSIX threads go to great lengths to do what I would call "the right
> thing".

Yes, and they have to because they are implementing services that are
defined to behave as syscalls in the specs.

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806210759.PAA27365>