[Top] [All Lists]

Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration

To: "Maciej W. Rozycki" <>
Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration
From: Andreas Jaeger <>
Date: 01 Jun 2001 15:48:36 +0200
Cc:,, Ralf Baechle <>, Jun Sun <>
In-reply-to: <> ("Maciej W. Rozycki"'s message of "Fri, 1 Jun 2001 14:18:04 +0200 (MET DST)")
Mail-copies-to: never
References: <>
User-agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley)
"Maciej W. Rozycki" <> writes:

> On 1 Jun 2001, Andreas Jaeger wrote:
>>  #include "sys/tas.h"
>> +
>> +#ifdef __NR__test_and_set
>> +# ifdef __ASSUME__TEST_AND_SET
>> +#  define __have_no__test_and_set 0
>> Don't add this, compare how we do it in similar cases.
>  Hmm, I looked at sysdeps/unix/sysv/linux/getcwd.c.  It does it in a
> similar way.  What's wrong with this approach?  I'm just asking -- it
> looks I do not always guess glibc rules right and not everything is
> documented.
We normally do not define anything to 0 - unless there's no other
way.  And looking briefly over your code there should be other
solutions.  Sorry, I'm limited in time currently, otherwise I would
rewrite it myself.

Look at i386/lockf64.c for a cleaner example.

>  Actually I tried to avoid macros if at all possible but gcc refuses to
> eliminate code even if that's something like:
> static const int var = 1;
> <...>
> if (var)
> <...>
> It still generates the code to check the value of var, sigh...
>  Also I feel a bit uneasy about placing the "#ifdef
> __ASSUME__TEST_AND_SET" condition outside -- __NR__test_and_set might be
> undefined due to outdated kernel headers even if someone specified the
> --enable-kernel option.  Is it considered justified within glibc to bail
> out at the compilation time in this case? 

We check that for the kernel headers in configure.

>>  extern int _test_and_set (int *p, int v) __THROW;
>> +extern int ___test_and_set (int *p, int v) __THROW;
>> Why do you export this here?
>  It's a syscall wrapper.  We want to export syscall wrappers, don't
>  we? 

No, not everything - we already export _test_and_set and that should
be enough.
> And if we export a symbol, we should also declare it -- programs declaring
> library symbols themselves are broken and doomed to fail sooner or later
> -- have you seen what happens on glibc systems to old programs which
> declare <string.h> functions due to the lack of appropriate declarations
> in system headers at one time?
>  If we don't want to export the wrapper, then fine -- I'll remove both the
> symbol and the declaration. 

 Andreas Jaeger
  SuSE Labs

<Prev in Thread] Current Thread [Next in Thread>