> > diff -ur hurd.old/libpthread/sysdeps/l4/hurd/pt-sysdep.h
> > hurd/libpthread/sysdeps/l4/hurd/pt-sysdep.h
> > --- hurd.old/libpthread/sysdeps/l4/hurd/pt-sysdep.h 2002-10-11
> > 01:05:05.0 +0200
> > +++ hurd/libpthread/sysdeps/l4/hurd/pt-sysdep.h 2003-03-09
> > 14:48:11.0 +
> this patch does s/inline/__inline__ for all pthread headers that get
> installed.
I've committed this but with s/inline/__inline/.
Thanks for your contribution.
Neal
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/b
> Maybe you want to consider this patch.
This patch is mostly incorrect.
> diff -ur hurd.old/libpthread/include/pthread/pthread.h
> hurd/libpthread/include/pthread/pthread.h
> --- hurd.old/libpthread/include/pthread/pthread.h 2002-11-10
> 18:00:40.0 +0100
> +++ hurd/libpthread/incl
> Roland, OK to commit?
For libpthread it's up to Neal.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Roland, OK to commit?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
On Fri, Jan 14, 2005 at 09:52:56PM +0100, Alfred M. Szmidt wrote:
> Why didn't you declare macro's for `extern __inline__' and use the
> already provided ones like __PT_SPIN_INLINE in
> sysdeps/generic/bits/pthread.h?
Robert Millan sent in a patch which does exactly this some time ago
(see http://
Why didn't you declare macro's for `extern __inline__' and use the
already provided ones like __PT_SPIN_INLINE in
sysdeps/generic/bits/pthread.h?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
this patch does s/inline/__inline__ for all pthread headers that get
installed.
2005-01-12 Pietro Ferrari <[EMAIL PROTECTED]>
* include/pthread/pthread.h (pthread_spin_destroy): Change
return type from extern inline to extern __inline__.
(pthread_spin_init): Likewise.
> I don't think this is quite correct. If it is extern inline
> (irregardless if you use inline, __inline or __inline__), it may not
> be inlined, but an external reference will be generated. Does our
> libpthread contain definitions for these inline functions?
>
> If not, we will need to add th
At Wed, 12 Jan 2005 12:05:45 +0100,
Alfred M. Szmidt wrote:
>
>Doesn't ../bits/pthread.h also do an extern inline int ... ??
>
> Sure, but it doesn't get installed.
Sure it does. That is the file that initiated this discussion.
___
Bug-hurd mai
At Tue, 11 Jan 2005 23:49:06 -0200,
pietro <[EMAIL PROTECTED]> wrote:
> i did a grep for inline in the libpthread/include dir and only
> pthread/pthread.h has inline in it. i'm attaching a patch that changes
> inlie to __inline__ as discussed in this list.
I don't think this is quite correct. I
>Doesn't ../bits/pthread.h also do an extern inline int ... ??
>
> Sure, butp it doesn't get installed.
Sure it does. That is the file that initiated this discussion.
Whoops, to early in the morning for me...
___
Bug-hurd mailing lis
Doesn't ../bits/pthread.h also do an extern inline int ... ??
Sure, but it doesn't get installed.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
pietro wrote:
Alfred M. Szmidt wrote:
If someone is bored, then they can fix the pthread headers to be C90
compliant. C90 disallows the use of the "inline" keyword.
Many programs still like to use -ansi, so this break compilation of
those on GNU/Hurd since our pthread headers aren't C90 compliant.
Alfred M. Szmidt wrote:
If someone is bored, then they can fix the pthread headers to be C90
compliant. C90 disallows the use of the "inline" keyword.
Many programs still like to use -ansi, so this break compilation of
those on GNU/Hurd since our pthread headers aren't C90 compliant.
i did a grep
On 20050111T190536-0500, James A. Morrison wrote:
> Why will extern inline change? I haven't seen anything in the gcc
> documentation to indicate any changes to extern inline.
Because the current semantics of inline are in conflict with what C99
specifies. The current GCC semantics and C99 sema
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
> Now, you seem to have completely missed *my* point. "extern inline"
> will change semantics sooner or later, and I would assume that "extern
> __inline__" does too. If you can tell me that my assumption is false,
> be my guest, but -ansi is n
If you can tell me that my assumption is false, be my guest, but
-ansi is not relevant here.
It is, -ansi does not support inline, and that is what the whole
discussion is about. That how the inline/__inline__ keywords get
changed is totally irrelevant to the discussion.
_
On 20050111T193321+0100, Alfred M. Szmidt wrote:
> You weren't making any point, I was correcting your impression as to
> the difference between __inline__ and inline.
You didn't correct my impression. since there was nothing to correct. I
know about the difference between __inline__ and inline w
At Tue, 11 Jan 2005 18:48:24 +0200,
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>
> [1 ]
> [1.1 ]
> On 20050111T174249+0100, Alfred M. Szmidt wrote:
> >I would expect GCC to eventually fix its inline handling to conform with
> >C99
> >
> > The problem isn't C99, but C90, __inline
>I was under the impression that __inline is an alias for
>inline, with no semantic differences.
>
> Then you have been under the wrong impression.
>
> ,[ (gcc)C Dialect Options ]
> | The alternate keywords `__asm__', `__extension__', `__inline__' and
> | `__type
On 20050111T180656+0100, Alfred M. Szmidt wrote:
>I was under the impression that __inline is an alias for inline,
>with no semantic differences.
>
> Then you have been under the wrong impression.
>
> ,[ (gcc)C Dialect Options ]
> | The alternate keywords `__asm__', `__extension__', `
> What about ditching the _EXTERN_INLINE macros and just use
> "extern __inline" directly? I don't see a reason why we should
> bother with a non-gcc compilers...
The _EXTERN_INLINE macros aren't there to protect against non-gcc;
That is true, silly me.
I was under the impression that __inline is an alias for inline,
with no semantic differences.
Then you have been under the wrong impression.
,[ (gcc)C Dialect Options ]
| The alternate keywords `__asm__', `__extension__', `__inline__' and
| `__typeof__' continue to work despite `-ansi'
I would expect GCC to eventually fix its inline handling to conform with
C99
The problem isn't C99, but C90, __inline is handled differently than
inline by gcc. The former works even with -ansi enabled.
___
Bug-hurd mailing list
Bug-hurd@gnu.or
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> What about ditching the _EXTERN_INLINE macros and just use "extern
> __inline" directly? I don't see a reason why we should bother with a
> non-gcc compilers...
The _EXTERN_INLINE macros aren't there to protect against non-gcc;
they are there so t
On 20050111T174249+0100, Alfred M. Szmidt wrote:
>I would expect GCC to eventually fix its inline handling to conform with
>C99
>
> The problem isn't C99, but C90, __inline is handled differently than
> inline by gcc. The former works even with -ansi enabled.
I was under the impression
On 20050111T162536+0100, Alfred M. Szmidt wrote:
> What about ditching the _EXTERN_INLINE macros and just use "extern
> __inline" directly? I don't see a reason why we should bother with a
> non-gcc compilers...
I would expect GCC to eventually fix its inline handling to conform with
C99 - at tha
I wonder if the best approach would be to just s/inline/__inline__/
in the public headers.
What about ditching the _EXTERN_INLINE macros and just use "extern
__inline" directly? I don't see a reason why we should bother with a
non-gcc compilers...
_
> I wonder if the best approach would be to just s/inline/__inline__/ in
> the public headers. gcc allows this even in -ansi mode (unlike just
> inline).
Yes, do that. It will at least be enough for some.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
ht
At Tue, 11 Jan 2005 01:55:22 +0100,
Alfred M. Szmidt wrote:
>
> If someone is bored, then they can fix the pthread headers to be C90
> compliant. C90 disallows the use of the "inline" keyword.
>
> Many programs still like to use -ansi, so this break compilation of
> those on GNU/Hurd since our p
31 matches
Mail list logo
