Hi Bill,
On 5/18/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> *Unfortunately* (the trouble with C itself, is that a *committee* has made
> it into ... something ... that it should not have made it into) -- anyway,
> unfortunately C took it upon itself to solve a problem
Satyam Sharma wrote:
*Unfortunately* (the trouble with C itself, is that a *committee* has made
it into ... something ... that it should not have made it into) -- anyway,
unfortunately C took it upon itself to solve a problem that it did not
have (and does not even bring about) in the first
Satyam Sharma wrote:
*Unfortunately* (the trouble with C itself, is that a *committee* has made
it into ... something ... that it should not have made it into) -- anyway,
unfortunately C took it upon itself to solve a problem that it did not
have (and does not even bring about) in the first
Hi Bill,
On 5/18/07, Bill Davidsen [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
*Unfortunately* (the trouble with C itself, is that a *committee* has made
it into ... something ... that it should not have made it into) -- anyway,
unfortunately C took it upon itself to solve a problem that
Hi Bodo,
On 5/13/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it
Hi Bodo,
On 5/13/07, Bodo Eggert [EMAIL PROTECTED] wrote:
Satyam Sharma [EMAIL PROTECTED] wrote:
In fact you can't really say the same for
volatile. We already assume the compiler _actually_ took some
pains to stuff meaning into C's (lack of) definition of volatile and
implement it -- but
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
* H. Peter Anvin ([EMAIL PROTECTED]) wrote:
> Satyam Sharma wrote:
> >
> > Because volatile is ill-defined? Or actually, *undefined* (well,
> > implementation-defined is as good as that)? It's *so* _vague_,
> > one doesn't _feel_ like using it at all!
> >
>
> Sorry, that's just utter crap.
Stefan Richter wrote:
> H. Peter Anvin wrote:
> [slightly off topic: GCCisms in Linux kernel]
>> It contains *many* constructs that are not defined in, for
>> example, C99, and it would in fact be impossible to write the Linux
>> kernel using only C99-compliant constructs.
>
> True. On the other
On Sat, May 12, 2007 at 09:53:03AM +0200, Stefan Richter wrote:
> H. Peter Anvin wrote:
> [slightly off topic: GCCisms in Linux kernel]
> > It contains *many* constructs that are not defined in, for
> > example, C99, and it would in fact be impossible to write the Linux
> > kernel using only
H. Peter Anvin wrote:
[slightly off topic: GCCisms in Linux kernel]
> It contains *many* constructs that are not defined in, for
> example, C99, and it would in fact be impossible to write the Linux
> kernel using only C99-compliant constructs.
True. On the other hand, it is possible to keep
jimmy bahuleyan wrote:
i believe, the doc here is pretty unambiguous regarding the fact that
volatile should be avoided. And as Stefan pointed out, anyone who feels
the need to use, must surely _know_ what he is doing & hence is in a
position t make that decision
Honestly, the above quoted
Stefan Richter wrote:
> Satyam Sharma wrote:
>> Coming back to the document, we do need to document / find
>> consensus on the "preferred" way to do similar business in the
>> kernel, and my opinion as far as that is concerned is to shun
>> volatile wherever possible (which includes the case
On 5/12/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>>
>> Sorry, that's just utter crap. Linux isn't written in some mythical C
>> which only exists in standard document, it is written in a particular
>> subset of GNU C. "volatile" is well enough defined in that context,
Satyam Sharma wrote:
> Coming back to the document, we do need to document / find
> consensus on the "preferred" way to do similar business in the
> kernel, and my opinion as far as that is concerned is to shun
> volatile wherever possible (which includes the case originally
> discussed above).
I
Satyam Sharma wrote:
>>
>> Sorry, that's just utter crap. Linux isn't written in some mythical C
>> which only exists in standard document, it is written in a particular
>> subset of GNU C. "volatile" is well enough defined in that context, it
>> is just frequently misused.
>
> Of course,
On 5/12/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
> Because volatile is ill-defined? Or actually, *undefined* (well,
> implementation-defined is as good as that)? It's *so* _vague_,
> one doesn't _feel_ like using it at all!
>
Sorry, that's just utter crap. Linux
Satyam Sharma wrote:
>
> Because volatile is ill-defined? Or actually, *undefined* (well,
> implementation-defined is as good as that)? It's *so* _vague_,
> one doesn't _feel_ like using it at all!
>
Sorry, that's just utter crap. Linux isn't written in some mythical C
which only exists in
On 5/12/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
>> + - Pointers to data structures in coherent memory which might be
>> modified
>> +by I/O devices can, sometimes, legitimately be volatile. A ring
>> buffer
>> +used by a network adapter, where that adapter
On 5/12/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
+ - Pointers to data structures in coherent memory which might be
modified
+by I/O devices can, sometimes, legitimately be volatile. A ring
buffer
+used by a network adapter, where that adapter changes
Satyam Sharma wrote:
Because volatile is ill-defined? Or actually, *undefined* (well,
implementation-defined is as good as that)? It's *so* _vague_,
one doesn't _feel_ like using it at all!
Sorry, that's just utter crap. Linux isn't written in some mythical C
which only exists in standard
On 5/12/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Because volatile is ill-defined? Or actually, *undefined* (well,
implementation-defined is as good as that)? It's *so* _vague_,
one doesn't _feel_ like using it at all!
Sorry, that's just utter crap. Linux isn't
Satyam Sharma wrote:
Sorry, that's just utter crap. Linux isn't written in some mythical C
which only exists in standard document, it is written in a particular
subset of GNU C. volatile is well enough defined in that context, it
is just frequently misused.
Of course, volatile _is_
Satyam Sharma wrote:
Coming back to the document, we do need to document / find
consensus on the preferred way to do similar business in the
kernel, and my opinion as far as that is concerned is to shun
volatile wherever possible (which includes the case originally
discussed above).
I too
On 5/12/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Sorry, that's just utter crap. Linux isn't written in some mythical C
which only exists in standard document, it is written in a particular
subset of GNU C. volatile is well enough defined in that context, it
is just
Stefan Richter wrote:
Satyam Sharma wrote:
Coming back to the document, we do need to document / find
consensus on the preferred way to do similar business in the
kernel, and my opinion as far as that is concerned is to shun
volatile wherever possible (which includes the case originally
jimmy bahuleyan wrote:
i believe, the doc here is pretty unambiguous regarding the fact that
volatile should be avoided. And as Stefan pointed out, anyone who feels
the need to use, must surely _know_ what he is doing hence is in a
position t make that decision
Honestly, the above quoted
H. Peter Anvin wrote:
[slightly off topic: GCCisms in Linux kernel]
It contains *many* constructs that are not defined in, for
example, C99, and it would in fact be impossible to write the Linux
kernel using only C99-compliant constructs.
True. On the other hand, it is possible to keep large
On Sat, May 12, 2007 at 09:53:03AM +0200, Stefan Richter wrote:
H. Peter Anvin wrote:
[slightly off topic: GCCisms in Linux kernel]
It contains *many* constructs that are not defined in, for
example, C99, and it would in fact be impossible to write the Linux
kernel using only C99-compliant
Stefan Richter wrote:
H. Peter Anvin wrote:
[slightly off topic: GCCisms in Linux kernel]
It contains *many* constructs that are not defined in, for
example, C99, and it would in fact be impossible to write the Linux
kernel using only C99-compliant constructs.
True. On the other hand, it
* H. Peter Anvin ([EMAIL PROTECTED]) wrote:
Satyam Sharma wrote:
Because volatile is ill-defined? Or actually, *undefined* (well,
implementation-defined is as good as that)? It's *so* _vague_,
one doesn't _feel_ like using it at all!
Sorry, that's just utter crap. Linux isn't
Satyam Sharma [EMAIL PROTECTED] wrote:
In fact you can't really say the same for
volatile. We already assume the compiler _actually_ took some
pains to stuff meaning into C's (lack of) definition of volatile and
implement it -- but in what sense, nobody knows (the C standard
H. Peter Anvin wrote:
>
> I don't see why Alan's way is necessarily better; it should work but is
> more heavy-handed as it's disabling *all* optimization such as loop
> invariants across the barrier.
>
To expand on this further: the way this probably *should* be handled,
Linux-style, is with
Satyam Sharma wrote:
>
>> + - Pointers to data structures in coherent memory which might be
>> modified
>> +by I/O devices can, sometimes, legitimately be volatile. A ring
>> buffer
>> +used by a network adapter, where that adapter changes pointers to
>> +indicate which descriptors
Satyam Sharma wrote:
On 5/11/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
+ - Pointers to data structures in coherent memory which might be
modified
+by I/O devices can, sometimes, legitimately be volatile. A ring
buffer
+used by a network adapter, where that adapter changes
On 5/11/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's
On 11/05/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's expressed. I'm glad to see files in
Documentation/ held
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's expressed. I'm glad to see files in
Documentation/ held
On 11/05/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's
On 5/11/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's
Satyam Sharma wrote:
On 5/11/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
+ - Pointers to data structures in coherent memory which might be
modified
+by I/O devices can, sometimes, legitimately be volatile. A ring
buffer
+used by a network adapter, where that adapter changes
Satyam Sharma wrote:
+ - Pointers to data structures in coherent memory which might be
modified
+by I/O devices can, sometimes, legitimately be volatile. A ring
buffer
+used by a network adapter, where that adapter changes pointers to
+indicate which descriptors have been
H. Peter Anvin wrote:
I don't see why Alan's way is necessarily better; it should work but is
more heavy-handed as it's disabling *all* optimization such as loop
invariants across the barrier.
To expand on this further: the way this probably *should* be handled,
Linux-style, is with
44 matches
Mail list logo
