NEWS - Hole in the Linux kernel allows root access (buh-by..

Hadron wrote:
> Lusotec writes:
>>> It does not matter what it is defined as, a NULL pointer does not have
>>> to be dereferenced to access address 0 (or whatever it is defined as).
>>> Check any number of C FAQs.
>>
>> If a null pointer is equal to a zero pointer (the most common case) then
>> directly, or indirectly, a null pointer has to be used to access address
>> zero, even if the zero pointer is the result of some pointer arithmetic's
>> or indexing.
>
> Meanwhile in the real world 99.9999999999999% of compiler/HW
> combinations the NULL pointer is indeed simply "0".

It is *null* pointer, not "NULL pointer". NULL is a constant.

> I'm not sure what your reason is. The access of address 0 is well known
> but does not, as you claim, make accessing via a null pointer
> "necessary".

If a null pointer is equal to a zero pointer then accessing address zero,
directly or indirectly, uses a null pointer since null and zero pointers are
exactly the same. How hard is this to understand!

> Dereferencing a null pointer in C leads to undefined
> behaviour. End of story.

Meanwhile in the real world, 99.9999999999999% of compiler/HW
combinations, dereferencing a null pointer is well defined.

Regards.

Lusotec <nomail.TakeThisOut@nomail.not> writes:

> Hadron wrote:
>> Lusotec writes:
>>>> It does not matter what it is defined as, a NULL pointer does not have
>>>> to be dereferenced to access address 0 (or whatever it is defined as).
>>>> Check any number of C FAQs.
>>>
>>> If a null pointer is equal to a zero pointer (the most common case) then
>>> directly, or indirectly, a null pointer has to be used to access address
>>> zero, even if the zero pointer is the result of some pointer arithmetic's
>>> or indexing.
>>
>> Meanwhile in the real world 99.9999999999999% of compiler/HW
>> combinations the NULL pointer is indeed simply "0".
>
> It is *null* pointer, not "NULL pointer". NULL is a constant.

sorry, predictive text again. nul pointer.

>
>> I'm not sure what your reason is. The access of address 0 is well known
>> but does not, as you claim, make accessing via a null pointer
>> "necessary".
>
> If a null pointer is equal to a zero pointer then accessing address zero,
> directly or indirectly, uses a null pointer since null and zero pointers are
> exactly the same. How hard is this to understand!
>
>> Dereferencing a null pointer in C leads to undefined
>> behaviour. End of story.
>
> Meanwhile in the real world, 99.9999999999999% of compiler/HW
> combinations, dereferencing a null pointer is well defined.
>
> Regards.
>

By the specific platform/compiler. Not by the language.

Yes, we could argue about a null pointer and a zero pointer to the cows
come home.

What are you trying to say here exactly?

Good C programmers do NOT dereference a null pointer. Doing so causes
issues.

I dont think you're being purposely obtuse but what are you trying to
say here?

Chris Ahlstrom <ahlstromc.TakeThisOut@launchmodem.com> writes:

> Hadron pulled this Usenet boner:
>
>> Meanwhile in the real world 99.9999999999999% of compiler/HW
>> combinations the NULL pointer is indeed simply "0".
>
> Wrong.

Not wrong.

>
> Debugging implementations that make use of a processor's automatic
> hardware checking (if available) of address accesses may have a separate
> representation (e.g., offset zero and a unique segment value) for
> every

May have in a debugging situation.


> null pointer constant in the source. (This enables runtime checks to
> trace back dereferences of the null pointer constant to the point
> in the source that created the constant.) (item 750)
>
> http://www.coding-guidelines.com/cbook/cbook1_2.pdf
>
>> I'm not sure what your reason is. The access of address 0 is well known
>> but does not, as you claim, make accessing via a null pointer
>> "necessary". Dereferencing a null pointer in C leads to undefined
>> behaviour. End of story.
>
> Code like the following looks like a dereference, but won't cause a
> fault, because it is not a dereference:
>
> int * n = NULL;
> int * p;
> p = &*n;
>
> Item 1092 from the same book.

That's just the same as p = n;

It's nothing more than a little novelty line that doesnt change the fact
that dereferencing the null pointer is a no no in C.

>
> By the way, that book is pretty eye-opening as to just how many ways both
> compilers and hardware can represent the "null pointer".

"can". In the real world its 0 nearly ALL the time, End of story.

cc pulled this Usenet boner:

> On Nov 5, 4:42?pm, Chris Ahlstrom <ahlstr....RemoveThis@launchmodem.com> wrote:
>>
>>
>> Code like the following looks like a dereference, but won't cause a
>> fault, because it is not a dereference:
>>
>> ? ?int * n = NULL;
>> ? ?int * p;
>> ? ?p = &*n;
>>
>> Item 1092 from the same book.
>
> That's in the C standard as well I believe. It's just p=n. What
> Lusotec was saying was that any way to get to address 0 was equal, but
> that's not true.
>
> int* p=NULL;
> int i =*p; /* undefined behavior */
>
> int* p=0;
> int i=*p; /* undefined behavior */
>
> union
> {
> int *u_p;
> int u_i;
> } p;
> p.u_i = 0;
> int i = *p.u_p; /* not undefined behavior */
>
> int* p;
> memset((void *)&p, 0, sizeof(p));
> int i=*p; /* not undefined behavior */
>
> Regardless of the implemenation's value of a null pointer, all of the
> above is always true.

Oh, I agree. I'm not sure what Lusotec is trying to say.

However, I think it would be more fruitful to study this book than this
thread.

--
Q: What is purple and conquered the world?
A: Alexander the Grape.

On Thu, 05 Nov 2009 17:14:36 -0800, Tim Smith wrote:

> In article <hcsao4$4c1$1@news.eternal-september.org>,
> "Ezekiel" <zeke DeleteThis @nosuchdomain.com> wrote:
>> Don't let little things like the FACT that Finale won 1st place as the best
>> music composition software get in way of your idiotic ramblings.
>
> I bet his answer to that will be that Finale doesn't *compose* the
> music--the user does.

I think that *was* his answer already.

These Linux people are crazy.

Tim Smith wrote:

> In article <hcsao4$4c1$1@news.eternal-september.org>,
> "Ezekiel" <zeke.TakeThisOut@nosuchdomain.com> wrote:
>> Don't let little things like the FACT that Finale won 1st place as the
>> best music composition software get in way of your idiotic ramblings.
>
> I bet his answer to that will be that Finale doesn't *compose* the
> music--the user does.
>

Right. Exactly as with other notation software. Which don't do prominent
ads about it being "compsosing" software to be cited by lemmings who
happily buy bridges
--
"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj

Tim Smith wrote:
> In article <hcsao4$4c1$1@news.eternal-september.org>,
> "Ezekiel" <zeke.TakeThisOut@nosuchdomain.com> wrote:
>> Don't let little things like the FACT that Finale won 1st place as
>> the best music composition software get in way of your idiotic
>> ramblings.
>
> I bet his answer to that will be that Finale doesn't *compose* the
> music--the user does.


MS Word doesn't process words - the user does.

On Fri, 6 Nov 2009 11:00:46 -0500, DFS wrote:

> Tim Smith wrote:
>> In article <hcsao4$4c1$1@news.eternal-september.org>,
>> "Ezekiel" <zeke.DeleteThis@nosuchdomain.com> wrote:
>>> Don't let little things like the FACT that Finale won 1st place as
>>> the best music composition software get in way of your idiotic
>>> ramblings.
>>
>> I bet his answer to that will be that Finale doesn't *compose* the
>> music--the user does.
>
>
> MS Word doesn't process words - the user does.

Kohlmann is just playing his semantic games in order to squirm out of his
being an idiot.