Hi!
> "Jean Delvare" <[EMAIL PROTECTED]> said:
> > > > > No, there is a third case: the pointer can be NULL, but the compiler
> > > > > happened to move the dereference down to after the check.
>
> > > > Wow. Great point. I completely missed that possibility. In fact I didn't
> > > > know that
Hi!
Jean Delvare [EMAIL PROTECTED] said:
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could
On Wednesday 30 March 2005 01:55 pm, Olivier Galibert wrote:
> Actually it is. Dereferencing a null pointer is either undefined or
> implementation-dependant in the standard (don't remember which), and
> as such the compiler can do whatever it wants, be it starting nethack
Can this be configured
On Mar 30, 2005, at 20:12, Nick Piggin wrote:
Why should this be in the kernel makefiles? If my_struct is NULL,
then the kernel will never reach the if statement.
Well, I think there is probably some arch code that uses 16-bit
that might use a null pointer, or at least a struct that starts
at the
Kyle Moffett wrote:
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote:
This testcase violates ISO C99 6.3.2.3:
If a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
Except that
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote:
This testcase violates ISO C99 6.3.2.3:
If a null pointer constant is converted to a pointer type, the
resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
Except that the result of
Kyle Moffett wrote:
Dereferencing null pointers is relied upon by a number of various
emulators and such, and is "platform-defined" in the standard, so
since Linux allows mmap at NULL, GCC shouldn't optimize that case
any differently.
From the GCC manual: "The compiler assumes that dereferencing a
On Mar 30, 2005, at 14:14, Paulo Marques wrote:
Just a minor nitpick, though: wouldn't it be possible for an
application to catch the SIGSEGV and let the code proceed,
making invalid the assumption made by gcc?
Uhh, it's even worse than that. Have a look at the following code:
#include
#include
Shankar Unni wrote:
Jean Delvare wrote:
v = p->field;
if (!p) return;
can be seen as equivalent to
if (!p) return;
v = p->field;
Heck, no.
You're missing the side-effect of a null pointer dereference crash (for
p->field) (even though v is unused before the return). The optimizer
On Wed, Mar 30, 2005 at 10:29:43AM -0800, Shankar Unni wrote:
> Jean Delvare wrote:
>
> >v = p->field;
> >if (!p) return;
> >
> >can be seen as equivalent to
> >
> >if (!p) return;
> >v = p->field;
>
> Heck, no.
>
> You're missing the side-effect of a null pointer dereference
Jean Delvare wrote:
v = p->field;
if (!p) return;
can be seen as equivalent to
if (!p) return;
v = p->field;
Heck, no.
You're missing the side-effect of a null pointer dereference crash (for
p->field) (even though v is unused before the return). The optimizer is
not allowed to
"Jean Delvare" <[EMAIL PROTECTED]> said:
> > > > No, there is a third case: the pointer can be NULL, but the compiler
> > > > happened to move the dereference down to after the check.
> > > Wow. Great point. I completely missed that possibility. In fact I didn't
> > > know that the compiler could
Hi Horst,
> > > No, there is a third case: the pointer can be NULL, but the compiler
> > > happened to move the dereference down to after the check.
>
> > Wow. Great point. I completely missed that possibility. In fact I didn't
> > know that the compiler could possibly alter the order of the
> >
Hi Horst,
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could possibly alter the order of the
Jean Delvare [EMAIL PROTECTED] said:
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could possibly alter
Jean Delvare wrote:
v = p-field;
if (!p) return;
can be seen as equivalent to
if (!p) return;
v = p-field;
Heck, no.
You're missing the side-effect of a null pointer dereference crash (for
p-field) (even though v is unused before the return). The optimizer is
not allowed to make
On Wed, Mar 30, 2005 at 10:29:43AM -0800, Shankar Unni wrote:
Jean Delvare wrote:
v = p-field;
if (!p) return;
can be seen as equivalent to
if (!p) return;
v = p-field;
Heck, no.
You're missing the side-effect of a null pointer dereference crash (for
p-field)
Shankar Unni wrote:
Jean Delvare wrote:
v = p-field;
if (!p) return;
can be seen as equivalent to
if (!p) return;
v = p-field;
Heck, no.
You're missing the side-effect of a null pointer dereference crash (for
p-field) (even though v is unused before the return). The optimizer is
On Mar 30, 2005, at 14:14, Paulo Marques wrote:
Just a minor nitpick, though: wouldn't it be possible for an
application to catch the SIGSEGV and let the code proceed,
making invalid the assumption made by gcc?
Uhh, it's even worse than that. Have a look at the following code:
#include stdio.h
Kyle Moffett wrote:
Dereferencing null pointers is relied upon by a number of various
emulators and such, and is platform-defined in the standard, so
since Linux allows mmap at NULL, GCC shouldn't optimize that case
any differently.
From the GCC manual: The compiler assumes that dereferencing a
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote:
This testcase violates ISO C99 6.3.2.3:
If a null pointer constant is converted to a pointer type, the
resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
Except that the result of
Kyle Moffett wrote:
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote:
This testcase violates ISO C99 6.3.2.3:
If a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
Except that
On Mar 30, 2005, at 20:12, Nick Piggin wrote:
Why should this be in the kernel makefiles? If my_struct is NULL,
then the kernel will never reach the if statement.
Well, I think there is probably some arch code that uses 16-bit
that might use a null pointer, or at least a struct that starts
at the
On Wednesday 30 March 2005 01:55 pm, Olivier Galibert wrote:
Actually it is. Dereferencing a null pointer is either undefined or
implementation-dependant in the standard (don't remember which), and
as such the compiler can do whatever it wants, be it starting nethack
Can this be configured to
"Jean Delvare" <[EMAIL PROTECTED]> said:
[Sttributions missing, sorry]
> > > Think about it. If the pointer could be NULL, then it's unlikely that
> > > the bug would have gone unnoticed so far (unless the code is very
> > > recent). Coverity found 3 such bugs in one i2c driver [1], and the
>
On Mar 29, 2005, at 09:22, Daniel Jacobowitz wrote:
The thing GCC is most likely to do with this code is discard the NULL
check entirely and leave only the oops; the "if (!card)" can not be
reached without passing through "card->amplifier", and a pointer which
is dereferenced can not be NULL in a
On Mon, Mar 28, 2005 at 10:23:48PM -0800, Andrew Morton wrote:
> > > -int old=card->amplifier;
> > > +int old;
> > > if(!card)
> > > {
> > > CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO
> > > "cs46xx: amp_hercules()
Jean Delvare wrote:
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could possibly alter the order of the
instructions. For one thing, I thought it was simply not allowed to. For
another, I didn't know that it had been made so aware that it could
Hi Andrew, all,
> > Think about it. If the pointer could be NULL, then it's unlikely that
> > the bug would have gone unnoticed so far (unless the code is very
> > recent). Coverity found 3 such bugs in one i2c driver [1], and the
> > correct solution was to NOT check for NULL because it
Hi Andrew, all,
Think about it. If the pointer could be NULL, then it's unlikely that
the bug would have gone unnoticed so far (unless the code is very
recent). Coverity found 3 such bugs in one i2c driver [1], and the
correct solution was to NOT check for NULL because it just
Jean Delvare wrote:
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could possibly alter the order of the
instructions. For one thing, I thought it was simply not allowed to. For
another, I didn't know that it had been made so aware that it could
On Mon, Mar 28, 2005 at 10:23:48PM -0800, Andrew Morton wrote:
-int old=card-amplifier;
+int old;
if(!card)
{
CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO
cs46xx: amp_hercules() called before
On Mar 29, 2005, at 09:22, Daniel Jacobowitz wrote:
The thing GCC is most likely to do with this code is discard the NULL
check entirely and leave only the oops; the if (!card) can not be
reached without passing through card-amplifier, and a pointer which
is dereferenced can not be NULL in a valid
Jean Delvare [EMAIL PROTECTED] said:
[Sttributions missing, sorry]
Think about it. If the pointer could be NULL, then it's unlikely that
the bug would have gone unnoticed so far (unless the code is very
recent). Coverity found 3 such bugs in one i2c driver [1], and the
correct
Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes a check after use found by the Coverity checker.
> > (...)
> > static void amp_hercules(struct cs_card *card, int change)
> > {
> > - int old=card->amplifier;
> > + int old;
> >if(!card)
> >{
> >
On Mon, 28 Mar 2005, L. A. Walsh wrote:
> However, in this case, if the author is _certain_ the
> pointer can never be NULL, than an "ASSERT(card!=NULL);" might
> be appropriate, where ASSERT is a macro that normally compiles
> in the check, but could compile to "nothing" for embedded or
>
Adrian Bunk wrote:
On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
In the first case, my patch doesn't do any harm (a superfluous isn't a
real bug).
In the second case, it fixed a
Jean Delvare schrieb:
Hi Adrian,
There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
Agreed.
In the first case, my patch doesn't do any harm (a superfluous isn't
a real bug).
The fact that it isn't a bug does not imply that the patch
Jean Delvare schrieb:
Hi Adrian,
There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
Agreed.
In the first case, my patch doesn't do any harm (a superfluous isn't
a real bug).
The fact that it isn't a bug does not imply that the patch
Adrian Bunk wrote:
On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
In the first case, my patch doesn't do any harm (a superfluous isn't a
real bug).
In the second case, it fixed a
On Mon, 28 Mar 2005, L. A. Walsh wrote:
However, in this case, if the author is _certain_ the
pointer can never be NULL, than an ASSERT(card!=NULL); might
be appropriate, where ASSERT is a macro that normally compiles
in the check, but could compile to nothing for embedded or
kernels
Jean Delvare [EMAIL PROTECTED] wrote:
This patch fixes a check after use found by the Coverity checker.
(...)
static void amp_hercules(struct cs_card *card, int change)
{
- int old=card-amplifier;
+ int old;
if(!card)
{
CS_DBGOUT(CS_ERROR, 2,
On Mon, Mar 28, 2005 at 12:34:01AM +0200, Jean Delvare wrote:
> I think that you'd be better just telling the
> maintainers about the problem without providing an arbitrary patch, so
> that they will actually look into the problem with their advanced
> knowledge of the driver
FWIW, I agree with
Hi Adrian,
> There are two cases:
> 1. NULL is impossible, the check is superfluous
> 2. this was an actual bug
Agreed.
> In the first case, my patch doesn't do any harm (a superfluous isn't
> a real bug).
The fact that it isn't a bug does not imply that the patch doesn't harm.
Tricking the
On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
> Hi Adrian,
>
> > This patch fixes a check after use found by the Coverity checker.
> > (...)
> > static void amp_hercules(struct cs_card *card, int change)
> > {
> > - int old=card->amplifier;
> > + int old;
> > if(!card)
>
Hi Adrian,
> This patch fixes a check after use found by the Coverity checker.
> (...)
> static void amp_hercules(struct cs_card *card, int change)
> {
> - int old=card->amplifier;
> + int old;
> if(!card)
> {
> CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO
>
Hi Adrian,
This patch fixes a check after use found by the Coverity checker.
(...)
static void amp_hercules(struct cs_card *card, int change)
{
- int old=card-amplifier;
+ int old;
if(!card)
{
CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO
Hi Adrian,
There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
Agreed.
In the first case, my patch doesn't do any harm (a superfluous isn't
a real bug).
The fact that it isn't a bug does not imply that the patch doesn't harm.
Tricking the reader
On Mon, Mar 28, 2005 at 12:34:01AM +0200, Jean Delvare wrote:
I think that you'd be better just telling the
maintainers about the problem without providing an arbitrary patch, so
that they will actually look into the problem with their advanced
knowledge of the driver
FWIW, I agree with Jean.
49 matches
Mail list logo
