NEWS - Hole in the Linux kernel allows root access (buh-bye security)
Ezekiel
But Kohltard insisted that it's perfectly legal to dereference a NULL
pointer so this can't be a real bug, can it?
<quote>
4 November 2009, 13:54
Hole in the Linux kernel allows root access
A null pointer dereference in the Linux kernel can be exploited to access a
system at root privilege level. The hole is reportedly contained in pipe.c
and can occur in certain circumstances when using the pipe_read_open(),
pipe_write_open() or pipe_rdwr_open() functions while releasing a mutex
(mutual exclusion) too early - which constitutes a classic race condition.
So far, the flaw has only been fixed in release candidate 6 of the
forthcoming version 2.6.32.
</quote>
http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-allows-root-access-850016.html
John Fuhrer
http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-allows-root-access-850016.html
Kohlmann got his a$$ seriously kicked in COLA yesterday.
Between the nvidia "just works" with Ubuntu 9.10 and his idiotic statement
about server Linux vs desktop Linux, it's been a bad day.
So now he gets rope-a-doped again.
Poor Peter.
How can we help?
Clogwog
news:rn8qjdtr4m75$.k2apbnabme3d$.dlg@40tude.net...
Off course by claims, without any proof, that these holes are fixed before
they are even discovered!
Poor P.I.K. (Peter Idiot Kohlmann), the usenet nazi!
<aside>
Obviously he runs Windows all day long, for windows programming, so Linux
security holes can't hurt him!
Ezekiel
"John Fuhrer" <fuhrer_sp...@yahoo.com> wrote in message
news:rn8qjdtr4m75$.k2apbnabme3d$.dlg@40tude.net...
Next he'll be telling people that Finale can't do music composition. Oh
wait... he did that too.
John Fuhrer
That was a beauty!
Seeing as the homepage for Finale proved Peter wrong from square one.
He would never admit it though and started his dancing, just like he is
doing now in several other threads.
Peter Köhlmann
Well, it can't
> That was a beauty!
Right.
> Seeing as the homepage for Finale proved Peter wrong from square one.
Actually, no, it didn't. Your reading comprehension is about as bad as the
one from Hadron Snot Quark
> He would never admit it though and started his dancing, just like he is
> doing now in several other threads.
Idiot
--
Microsoft's Guide To System Design:
If it starts working, we'll fix it. Pronto.
Ezekiel
"PeterK�hlmann" <peter-k...@t-online.de> wrote in message
news:hcs9j3$hdv$03$1...@news.t-online.com...
Because an idiot like you claims this doesn't make it so.
>> That was a beauty!
>
> Right.
Wrong retard. Cut your losses now before you look like an even bigger idiot
than you already are.
>> Seeing as the homepage for Finale proved Peter wrong from square one.
>
> Actually, no, it didn't. Your reading comprehension is about as bad as the
> one from Hadron Snot Quark
Learn to read dumbass. There are several colleges that offer courses in
music composition using Finale and several books written on the subject.
Don't let little facts like that get in your way of your stupid delusions.
>> He would never admit it though and started his dancing, just like he is
>> doing now in several other threads.
>
> Idiot
You are certainly the expert at being an idiot.
Ezekiel
"Peter K�hlmann" <peter-k...@t-online.de> wrote in message
news:hcs9j3$hdv$03$1...@news.t-online.com...
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.
Congrats K�hltard - most cretins have to work very hard to be half as
stupid as you are.
<quote>
Finale 2010 Notation Software
Winner of: Best Music Notation & Composition Software
#1 - Finale 2010 Notation Software
Why it's best:
Finale 2010 is an ever-evolving music notation software. It gives uses the
tools needed for music composition, arrangement, notation, and even the
ability to print engraver-quality sheet music.
#2 - Sibelius 6 Professional Notation Software
#3 - NOTION 3.0 Composition Software
</quote>
http://www.bestcovery.com/best-music-notation-composition-software
John Fuhrer
He's a waste of time.
I've scored him down because his purpose here is to draw people into an
endless meta thread so they don't have the time to focus on Linux vs other
operating systems.
John Fuhrer
Facts always seem to bother the Linux COLA freaks for some reason.
I don't know why that is.
Lusotec
> But Kohltard insisted that it's perfectly legal to dereference a NULL
> pointer so this can't be a real bug, can it?
In kernel space, it is perfectly legal (and a necessity) to dereference a
NULL (ZERO) pointer or this would not result in a exploit but a
crash/panic/oops.
<quote>
However, like previous null pointer dereference issues in the Linux kernel,
the vulnerability can only be exploited if the kernel's mmap_min_addr system
variable is set to 0. mmap_min_addr describes the lowest virtual address a
process can use for mapping. If it is greater than 0, exploits that involve
a null-valued pointer to this address won't work. However, as this will also
cause certain open source applications like Wine and DOSEMU to malfunction,
distributors such as Red Hat and Debian set the respective value to 0 by
default.
</quote>
From <http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-
allows-root-access-850016.html>
I find it strange that Red Hat would set mmap_min_addr to 0 because of Wine
or DOSEMU. First, Wine works with a non zero mmap_min_addr, at least in all
systems I ever used Wine. Second, Red Hat is mostly used on servers and Wine
or DOSEMU have no place there.
Can anyone check mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) on your Red
Hat and/or Debian systems?
Regards.
Hadron
> "Peter Köhlmann" <peter-k...@t-online.de> wrote in message
> Congrats Köhltard - most cretins have to work very hard to be half as
> stupid as you are.
>
> <quote>
> Finale 2010 Notation Software
> Winner of: Best Music Notation & Composition Software
>
> #1 - Finale 2010 Notation Software
> Why it's best:
> Finale 2010 is an ever-evolving music notation software. It gives uses the
> tools needed for music composition, arrangement, notation, and even the
> ability to print engraver-quality sheet music.
>
> #2 - Sibelius 6 Professional Notation Software
>
> #3 - NOTION 3.0 Composition Software
> </quote>
>
> http://www.bestcovery.com/best-music-notation-composition-software
Koehltard does not "do" links. Like chrisv he is afraid of what waits at
the other end.
John Fuhrer
> "Ezekiel" <ze...@nosuchdomain.com> writes:
>
>> "Peter K�hlmann" <peter-k...@t-online.de> wrote in message
>> Congrats K�hltard - most cretins have to work very hard to be half as
>> stupid as you are.
>>
>> <quote>
>> Finale 2010 Notation Software
>> Winner of: Best Music Notation & Composition Software
>>
>> #1 - Finale 2010 Notation Software
>> Why it's best:
>> Finale 2010 is an ever-evolving music notation software. It gives uses the
>> tools needed for music composition, arrangement, notation, and even the
>> ability to print engraver-quality sheet music.
>>
>> #2 - Sibelius 6 Professional Notation Software
>>
>> #3 - NOTION 3.0 Composition Software
>> </quote>
>>
>> http://www.bestcovery.com/best-music-notation-composition-software
>
>
> Koehltard does not "do" links. Like chrisv he is afraid of what waits at
> the other end.
Yep.
chrisv has already slinked from the other threads where the links proved
him completely wrong.
Chris Ahlstrom
> <quote>
> However, like previous null pointer dereference issues in the Linux kernel,
> the vulnerability can only be exploited if the kernel's mmap_min_addr system
> variable is set to 0. mmap_min_addr describes the lowest virtual address a
> process can use for mapping. If it is greater than 0, exploits that involve
> a null-valued pointer to this address won't work.
> </quote>
> <http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-allows-root-access-850016.html>
>
> I find it strange that Red Hat would set mmap_min_addr to 0 because of Wine
> or DOSEMU. First, Wine works with a non zero mmap_min_addr, at least in all
> systems I ever used Wine. Second, Red Hat is mostly used on servers and Wine
> or DOSEMU have no place there.
>
> Can anyone check mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) on your Red
> Hat and/or Debian systems?
Debian squeeze 32-bit: 4096
Debian squeeze 64-bit: 4096
Fedora 11 64-bit: 65536
--
Green light in A.M. for new projects. Red light in P.M. for traffic tickets.
Hadron
> On Wed, 04 Nov 2009 17:57:40 +0100, Hadron wrote:
>
>> "Ezekiel" <ze...@nosuchdomain.com> writes:
>>
>>> "Peter Köhlmann" <peter-k...@t-online.de> wrote in message
>>> Congrats Köhltard - most cretins have to work very hard to be half as
>>> stupid as you are.
>>>
>>> <quote>
>>> Finale 2010 Notation Software
>>> Winner of: Best Music Notation & Composition Software
>>>
>>> #1 - Finale 2010 Notation Software
>>> Why it's best:
>>> Finale 2010 is an ever-evolving music notation software. It gives uses the
>>> tools needed for music composition, arrangement, notation, and even the
>>> ability to print engraver-quality sheet music.
>>>
>>> #2 - Sibelius 6 Professional Notation Software
>>>
>>> #3 - NOTION 3.0 Composition Software
>>> </quote>
>>>
>>> http://www.bestcovery.com/best-music-notation-composition-software
>>
>>
>> Koehltard does not "do" links. Like chrisv he is afraid of what waits at
>> the other end.
>
> Yep.
> chrisv has already slinked from the other threads where the links proved
> him completely wrong.
Chrisv is on a par with Willy Poaster as the most useless poster in
COLA. Only HPT and Rick come close.
Lusotec
Thank you, Chris.
On all systems I manage: 1048576 (1MiB)
On Mandriva by default: 4096 (4KiB)
Regards.
Peter Köhlmann
It still does not composition. It simply *helps* composers, but it does
not do composition by itself. *No* music notation software does
This is true for basically all music notation software. It just is
different how easy it is to enter notes
--
Windows was created to keep stupid people away from UNIX."
-- Tom Christiansen
Ezekiel
"Lusotec" <nom...@nomail.not> wrote in message
news:hcscgr$ivn$2...@news.eternal-september.org...
On two Ubuntu 8.04 installs it's 65536
but on Debian 5.0 it's:
zeke@debian:~$ cat /proc/sys/vm/mmap_min_addr
0
zeke@debian:~$ uname -a
Linux debian 2.6.26-2-686 #1 SMP Sat Oct 17 17:59:23 UTC 2009 i686 GNU/Linux
Ezekiel
"PeterKöhlmann" <peter-k...@t-online.de> wrote in message
news:hcsdp8$c2p$02$1...@news.t-online.com...
Well DUH!!! Your defense is to now claim that all along you were arguing
about the application composing music all "by itself." The obvious point
that it's software that allows musicians to do composition never occurred to
you - you thought the music would just write itself? Do we also need to
point out that it has to be a "live" musician in order for the software to
work and that it can't magically compose music for Mozart?
> This is true for basically all music notation software.
Yeah - it's basically true that people have to use the software to compose
music. The software can't do it all "by itself."
Hadron
Pathetic. Even by your standards.
>
> This is true for basically all music notation software. It just is
> different how easy it is to enter notes
You mean Music notation? You get more idiotic with every post. Even
Ahlstrom will get a giggle from this latest cock up by you.
John Fuhrer
Kohlmann is dancing like a drunk Luftwaffe pilot.
Between the nvidia thread, the null pointer thread and his idiotic Finale
cock up.
He has a serious problem admitting when he is wrong.
Ezekiel
"John Fuhrer" <fuhrer_sp...@yahoo.com> wrote in message
news:5d1tc68sfqbn.15efrgnisy0hc$.dlg@40tude.net...
That's a keeper!
cc
> Ezekiel wrote:
> > But Kohltard insisted that it's perfectly legal to dereference a NULL
> > pointer so this can't be a real bug, can it?
>
> In kernel space, it is perfectly legal (and a necessity) to dereference a
> NULL (ZERO) pointer or this would not result in a exploit but a
> crash/panic/oops.
>
How is it a necessity? Since the Linux kernel is written in C, it is
legal in the sense that it is undefined behavior, so gcc or whatever
implementation you're using to compile could define it however they
choose, which is why it results in an exploit and not a crash. Note
that a NULL pointer does not have to correspond to address zero, but
NULL==0. So if you think it's necessary because the kernel needs
access to 0, then you're completely mistaken. So I'm not sure why it's
necessary.
Rick
Rick
... except that Finale doesn't "do composition" any more than quill,
ink and paper do.
Hadron
> Ezekiel wrote:
>> "Peter Köhlmann" <peter-k...@t-online.de> wrote in message
>> Congrats Köhltard - most cretins have to work very hard to be half as
>> stupid as you are.
>>
>> <quote>
>> Finale 2010 Notation Software
>> Winner of: Best Music Notation & Composition Software
>>
>> #1 - Finale 2010 Notation Software
>> Why it's best:
>> Finale 2010 is an ever-evolving music notation software. It gives uses the
>> tools needed for music composition, arrangement, notation, and even the
>> ability to print engraver-quality sheet music.
>>
>> #2 - Sibelius 6 Professional Notation Software
>>
>> #3 - NOTION 3.0 Composition Software
>> </quote>
>>
>> http://www.bestcovery.com/best-music-notation-composition-software
>>
>>
>>
>>
> Finale doesn't "do composition" any more than a quill, ink and paper does.
>
Rick. Shut up. You really don't need to dig Koehlmann out of this. It IS
Music Composition SW.
Tell me do you expect the OO word processor to "process the words" on
its own too?
Do grow up.
Ezekiel
"Rick" <nom...@none.invalid> wrote in message
news:AaednRJP-ovKRGzX...@supernews.com...
No need to keep proving that you're an idiot Rick. Nobody ever claimed that
Finale does composition all by itself. Any more than photography software
won't take photos all by itself. This doesn't change the *fact* that Finale
is music composition software that can be used by a human to compose music.
John Fuhrer
> Rick <nom...@none.invalid> writes:
>
>> Ezekiel wrote:
>>> "Peter K�hlmann" <peter-k...@t-online.de> wrote in message
>>> Congrats K�hltard - most cretins have to work very hard to be half as
>>> stupid as you are.
>>>
>>> <quote>
>>> Finale 2010 Notation Software
>>> Winner of: Best Music Notation & Composition Software
>>>
>>> #1 - Finale 2010 Notation Software
>>> Why it's best:
>>> Finale 2010 is an ever-evolving music notation software. It gives uses the
>>> tools needed for music composition, arrangement, notation, and even the
>>> ability to print engraver-quality sheet music.
>>>
>>> #2 - Sibelius 6 Professional Notation Software
>>>
>>> #3 - NOTION 3.0 Composition Software
>>> </quote>
>>>
>>> http://www.bestcovery.com/best-music-notation-composition-software
>>>
>>>
>>>
>>>
>> Finale doesn't "do composition" any more than a quill, ink and paper does.
>>
>
> Rick. Shut up. You really don't need to dig Koehlmann out of this. It IS
> Music Composition SW.
>
> Tell me do you expect the OO word processor to "process the words" on
> its own too?
>
> Do grow up.
Between him and Willy Poser playing semantic games in the Nvidia
discussion, it's getting rather pathetic around here.
They are just looking like idiots the more they bob and weave.
Whatever small amount of Linux advocacy that was once in COLA has
disintegrated to just about nothing.
John Fuhrer
Poor Rick.
He is looking as foolish as Kohlmann, Willy Poaster and Terry Porter.
Tim Smith
"Ezekiel" <ze...@nosuchdomain.com> wrote:
> But Kohltard insisted that it's perfectly legal to dereference a NULL
> pointer so this can't be a real bug, can it?
Actually, I believe what he insisted on in the incident you are
referring to was that the code in question did not dereference a null
pointer. It was his understanding (or lack thereof) of C that he failed
on there, not his understanding of the legality of null pointer
dereferencing.
--
--Tim Smith
John Fuhrer
Kohlmann sidesteps so often that it is virtually impossible to determine
what he meant, what he means nor what he might mean in the future.
Ezekiel
"Tim Smith" <reply_i...@mouse-potato.com> wrote in message
news:reply_in_group-BED...@news.supernews.com...
(There's a lot of word smithing going on today <g>)
Correct. He didn't say that you could dereference a NULL pointer. He claimed
that dereferencing a pointer who's value is NULL wouldn't result in a memory
access. Minor difference but a difference never less.
This time around the code is similar but is writing rather than reading the
memory.
static int
pipe_rdwr_open(struct inode *inode, struct file *filp)
{
mutex_lock(&inode->i_mutex);
if (filp->f_mode & FMODE_READ)
inode->i_pipe->readers++; (<- HERE!)
(inode is valid but inode->i_pipe is NULL.)
Clogwog
news:AaednQ1P-otERGzX...@supernews.com...
Your a stupid one, battling with Kohlmann on stupidity, huh!
A gem like Finale for a lousy $600.00
Talk with Marti about your "ink and paper" idiocy, Marti chooses Linux for
his compositions, that's *his* choice.
Marti is a Linux advocate, Kohlmann and you are not and never will be
advocates!, you pigheaded twit!
jebblue
Props.
--
// This is my opinion.
Lusotec
NULL is defined as ZERO and the kernel needs to access that part of memory.
You are right that NULL does not have to be ZERO, but in this case it is,
thus my comment.
Regards.
Lusotec
Thank you, Ezekiel.
It is curious that Debian decided to set mmap_min_addr to zero. If some
program needs it, then set it only when that program is installed and warn
the user about it. Setting it to zero by default is a bad idea. The safety
net provided by mmap_min_addr should not be removed unless absolutely
needed. These kinds of bugs in the kernel and programs are unlikely to
disappear any time soon.
Regards.
Chris Ahlstrom
> Ezekiel wrote:
>> Lusotec wrote:
>>> Chris Ahlstrom wrote:
>>>> Lusotec pulled this Usenet boner:
>>>>>
>>>>> Can anyone check mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) on your
>>>>> Red Hat and/or Debian systems?
>>>>
>>>> Debian squeeze 32-bit: 4096
>>>> Debian squeeze 64-bit: 4096
>>>> Fedora 11 64-bit: 65536
>>>
>>> On all systems I manage: 1048576 (1MiB)
>>> On Mandriva by default: 4096 (4KiB)
>>
>> On two Ubuntu 8.04 installs it's 65536
>>
>> but on Debian 5.0 it's:
>> 0
>> zeke@debian:~$ uname -a
>> Linux debian 2.6.26-2-686 #1 SMP Sat Oct 17 17:59:23 UTC 2009 i686
>
> Thank you, Ezekiel.
>
> It is curious that Debian decided to set mmap_min_addr to zero.
I thought the article said that some Wine functionality needed that setting.
Of course, with Debian, they may have had a brain fart that they corrected
in squeeze. :-)
> If some
> program needs it, then set it only when that program is installed and warn
> the user about it. Setting it to zero by default is a bad idea. The safety
> net provided by mmap_min_addr should not be removed unless absolutely
> needed. These kinds of bugs in the kernel and programs are unlikely to
> disappear any time soon.
Huh? Once found, I'm sure they're fixed rather quickly. I know what you
mean, though.
--
You will win success in whatever calling you adopt.
Lusotec
> Lusotec pulled this Usenet boner:
>
> I thought the article said that some Wine functionality needed that
> setting.
I run Wine with mmap_min_addr=1MiB without problems.
>> If some
>> program needs it, then set it only when that program is installed and
>> warn the user about it. Setting it to zero by default is a bad idea. The
>> safety net provided by mmap_min_addr should not be removed unless
>> absolutely needed. These kinds of bugs in the kernel and programs are
>> unlikely to disappear any time soon.
>
> Huh? Once found, I'm sure they're fixed rather quickly. I know what you
> mean, though.
These kinds of bugs are very easy to fix once they are found but the problem
is the time between someone with bad intentions finding a way to exploit the
bug and the bug being patched in all the systems. That can be a windows of
time more than enough to cause lots damage.
That is why multiple layers of protection are a must. Even if one or more
protective layers have holes the remaining layers will still protect the
system.
Simply discarding layers for convenience is a bad approach. Setting
mmap_min_addr to a large enough value can easily protect the kernel and
applications from an important class of exploitable bugs. This alone should
be enough for people not to mess with it without a very good reason.
Regards.
cc
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.
Hadron
Not at application level code. Else it would make a bit of a mockery of
HW checking Koehlmann's crap code for NULL access. But hey! Apparently
him and Liarmutt "craft world class code" : AND they read
articles. Really!
cc
Not at any level code. Before Tim and Chris come along with their
assembly code again, let me stress that the alternatives to
dereferencing a NULL to get access to zero almost certainly produce
the exact same assembly code as actually dereferencing a NULL pointer.
BUT assumptions the compiler can make based on whether you are
invoking undefined behavior or not change. The produced assembly has
no meaning in the context of what C compilers can do according to the
C standard. In both recent cases of kernel errors, accessing the
pointers differently wouldn't have changed anything, but hopefully the
knowledge that NULL pointer dereferences aren't necessary in the
kernel, and that they would invoke undefined behavior will keep people
from blaming gcc for coder errors.
Richard Rasker
[snip local root exploit]
FYI: once someone has physical access to a Linux box, they almost always
have root access as well. So this "buh-bye security" story is wildly
exaggerated, to say the least.
The tricky thing is to remotely compromise a Linux box -- which usually
means you have to get users to execute your virus code. This is where Linux
is more secure than Windows, because Linux users do not expect to download
and execute code in order to get something done.
The most common cause of Linux security problems is sloppy maintenance, with
server admins leaving vulnerable scripts in place.
Anyway, until a significant portion of all Linux machines gets compromised
(more than, say, 1%), even an idiot can see that Linux is vastly more
secure than Windows (with a near 60% infection rate worldwide).
Richard Rasker
--
http://www.linetec.nl
Chris Ahlstrom
> Apparently him and Chris "craft world class code".
Thanks for the vote of confidence, "Hadron", but, no, I have never claimed
to "craft world class code".
To me, the term "craft" refers to taking the time and effort to do things
right. It says nothing about the quality of the code the results... even a
craftsman can be mistaken. And a craftsman can work hard and still produce
code that is not "world class" -- it may be too limited in what it does, or
too non-standard for others to use or to want to use.
I enjoy crafting code. I work hard at it, as you would know if you have
found my publicly posted project and perused the source code, documentation,
and scripts that accompany it.
But in no way do I claim to be a crafter of world-class code. That would be
for someone else to decide.
--
Nothing so needs reforming as other people's habits.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Lusotec
> Lusotec wrote:
>> NULL is defined as ZERO and the kernel needs to access that part of
>> memory. You are right that NULL does not have to be ZERO, but in this
>> case it is, thus my comment.
One correction to what I wrote before. NULL is always defined as ZERO but a
null pointer is not required to be equal to a zero pointer, but usually is.
> 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.
Regards.
Hadron
Meanwhile in the real world 99.9999999999999% of compiler/HW
combinations the NULL pointer is indeed simply "0".
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.
Lusotec
> 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.
>
> 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.
cc
> 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!
They are not the same. A compiler does not have to compile a pointer
set to 0 (NULL) that is then accessed. A compiler does have to compile
any number of equivalent, but well defined alternatives (memset,
unions).
> > 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.
>
Yes, it's defined as undefined behavior. That's why gcc optimized away
a NULL check after a pointer had already been dereferenced, which lead
to a previous kernel exploit.
Hadron
> 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
> Meanwhile in the real world 99.9999999999999% of compiler/HW
> combinations the NULL pointer is indeed simply "0".
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
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.
By the way, that book is pretty eye-opening as to just how many ways both
compilers and hardware can represent the "null pointer".
--
Your aim is high and to the right.
Hadron
> 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
>
>
> 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.
Chris Ahlstrom
> On Nov 5, 4:42?pm, Chris Ahlstrom <ahlstr...@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.
Tim Smith
"Ezekiel" <ze...@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.
--
--Tim Smith
John Fuhrer
I think that *was* his answer already.
These Linux people are crazy.
Peter Köhlmann
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
DFS
MS Word doesn't process words - the user does.
John Fuhrer
Kohlmann is just playing his semantic games in order to squirm out of his
being an idiot.