473,883 Members | 1,660 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Null pointers

Can 0x0 be a valid virtual address in the address space
of an application ?
If it is valid, then the location pointed by a NULL pointer
is also valid and application should not receive "SIGSEGV"
( i am talking of unix machine ) while trying to read that
location.
Then how can i distinguish between a NULL pointer and an invalid
location ?
Is this essential that NULL pointer should not point to any of
the location in the virtual address space ?

If NULL pointer should not essentially point to an invalid
location, then why we should always use NULL to be location 0x0,
can we use some other location as well ?

Is this necessary that whenever an application try to access
location pointed by NULL pointer, it should be aborted by kernel
by posting some signal ?

Please i need your help, beacuse i am getting more confused
as i am reading more and more documents on NULL pointers.
thanx for any help in advance.....
Nov 14 '05
102 6129
In article <ch************ *************** ******@slb-newsm1.svr.pol. co.uk>,
Christian Bau <ch***********@ cbau.freeserve. co.uk> wrote:
1. Conversion is implementation defined
2. Converting a null pointer constant produces a null pointer.

I interpret this as "The implementation defines what the result of
conversion from integer to pointer types is. However, it is not
completely free to do this in arbitrary ways: Whatever rules the
implementati on chooses, it must make sure that these rules convert null
pointer constants to null pointers. "


Your argument relies on the assumption that the implementation-defined
conversion must return the same result for a null pointer constant as
for non-constant zeros. Can you show that from the standard?

After all, if the standard's own definition of the conversion of
integers to pointers can make use of this distinction, why can't
the implementation' s?

-- Richard
Nov 14 '05 #91
Emmanuel Delahaye wrote:
.... snip ...
It's different on a 68k where the address 0 holds the boot vector.
Must be a *ROM, not a RAM.


That does not necessarily follow. An 8080 starts execution at 0,
but that address also normally holds an interrupt vector. My
solution was to have the power on reset set a circuit which jammed
the high order address byte (from a dipswitch) onto the buss for
the first 3 cycles. Now I could set an initializing ROM anywhere
on 256 byte intervals, as long as the first instruction was a jmp
absolute.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"A man who is right every time is not likely to do very much."
- Francis Crick, co-discover of DNA
Nov 14 '05 #92
Christian Bau <ch***********@ cbau.freeserve. co.uk> wrote:
In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:
(char*)0 --> $12345678$ (null pointer)
int zero = 0;
(char*)zero --> $00000000$ (non-null pointer)
(char*)0x123456 78 --> $12345678$ (happens to be a null pointer)


Quite possible in C90, but most definitely not in C99. In C90, the
wording was such that in an assignment, or within an equality operator,
and probably some cases that I forgot, a null pointer constant was
replaced with a null pointer. (char*)0 was _not_ one if these cases and
in C90 not guaranteed to be a null pointer; in C99 they added that
_every_ conversion of a null pointer constant to a pointer produces a
null pointer.


Ok, but whatever makes you think that (char *)zero involves a null
pointer constant? A null pointer constant is not an integer expression,
it is an integer _constant_ expression.

Richard
Nov 14 '05 #93
"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:
"Keith Thompson" <ks***@mib.or g> wrote in message

[...]
If address all-bits-zero were always reserved on all systems, the C
standard might as well have mandated that a null pointer is always
represented as all-bits-zero. As we all know, it didn't.

The special feature might be that a value of all bits zero automatically
traps when loaded into an address register, so obviously this would be a
poor choice of value for the null pointer. Alternatively execution may
always start at 0, which might mean that a function pointer set to main
would be all bits zero.


Depending on the details of the architecture, trapping on loading
all-bits-zero into an address register might be a good argument in
favor of using all-bits-zero for the null pointer, assuming that
legitimate operations on a null pointer (such as assignment and
equality comparison) can be done without loading it into an address
register.

But you're right; even if all-bits-zero were always reserved on all
systems, that wouldn't necessarily mean it's always a good idea to use
all-bits-zero as the null pointer.

But I still maintain that we can't assume (and, more importantly,
shouldn't care) that all-bits-zero is always reserved on all systems.
Even if it is, there's nothing useful we can do with that information.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #94

"Michael Wojcik" <mw*****@newsgu y.com> wrote

Always? There has never been and will never be a system where address
0 isn't used for some special purpose? There are no embedded systems
which would permit the designer to put ordinary RAM at location 0?

I think you'll find you're wrong about that. A little Google searching
turned up a couple of memory maps with RAM banks starting at address 0.

The "system" is the hardware plus the C compiler. If the hardware doesn't
use all bits zero for something special the C compiler probably will, often
for the null pointer but maybe just as a control block for the beginning of
the heap or something similar.
Nov 14 '05 #95
"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:
"Michael Wojcik" <mw*****@newsgu y.com> wrote
Always? There has never been and will never be a system where address
0 isn't used for some special purpose? There are no embedded systems
which would permit the designer to put ordinary RAM at location 0?

I think you'll find you're wrong about that. A little Google searching
turned up a couple of memory maps with RAM banks starting at address 0.

The "system" is the hardware plus the C compiler. If the hardware doesn't
use all bits zero for something special the C compiler probably will, often
for the null pointer but maybe just as a control block for the beginning of
the heap or something similar.


If you're arguing that the all-bits-zero address is *usually* reserved
for something special (whether for the null pointer for for something
else), I completely agree.

If you're arguing, as I think you have been, that it's *always*
reserved, I suspect you're mistaken, but it doesn't really matter one
way or the other. It's not always reserved for the same thing on
different systems, so the assumption that it's always reserved doesn't
lead to any useful conclusions.

If you're arguing that it *should* always be reserved, I strongly
disagree. There's no point in imposing this kind of restriction.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #96

In article <cf**********@n ews6.svr.pol.co .uk>, "Malcolm" <ma*****@55bank .freeserve.co.u k> writes:

"Michael Wojcik" <mw*****@newsgu y.com> wrote

Always? There has never been and will never be a system where address
0 isn't used for some special purpose? There are no embedded systems
which would permit the designer to put ordinary RAM at location 0?

The "system" is the hardware plus the C compiler. If the hardware doesn't
use all bits zero for something special the C compiler probably will, often
for the null pointer but maybe just as a control block for the beginning of
the heap or something similar.


You claimed address 0 was *always* reserved. This "probably" is just
weaseling out.

And yes, I think this *is* important here. Some people like to make
pronouncements on c.l.c of the form "X isn't guaranteed by the
standard, but in practice it's always true". That sort of thing
leads to bad practice. I've known plenty of C programmers who think
that in practice the alpha characters are contiguous (in a single
case), but anyone who's had to port C to an EBCDIC machine, as I
have, knows that's not the case, and that there's plenty of code
which breaks on EBCDIC systems because of such assumptions.

It is rarely a good idea to declare that something is always true in
C, if it's not specified that way by the standard. And in a case
like this it wouldn't be useful anyway if it were true. So why make
that claim? It's more useful to be precise and say, "look, don't
count on it; write your code correctly".

--
Michael Wojcik mi************@ microfocus.com

Push up the bottom with your finger, it will puffy and makes stand up.
-- instructions for "swan" from an origami kit
Nov 14 '05 #97

"Michael Wojcik" <mw*****@newsgu y.com> wrote

You claimed address 0 was *always* reserved. This "probably" is just
weaseling out.
No one has posted a counter example, which strongly suggests that there
isn't one.
And yes, I think this *is* important here. Some people like to make
pronouncements on c.l.c of the form "X isn't guaranteed by the
standard, but in practice it's always true". That sort of thing
leads to bad practice.
But also helps understanding. If a newbie thinks that something is likely
which he will never in fact encounter, that causes confusions. Humans are
not natural lawyers who can learn a rule divorced from practical examples.
I've known plenty of C programmers who think
that in practice the alpha characters are contiguous (in a single
case), but anyone who's had to port C to an EBCDIC machine, as I
have, knows that's not the case, and that there's plenty of code
which breaks on EBCDIC systems because of such assumptions.

A lot of code is like that. For instance IFF files have 4-byte ASCII
identifiers. It is natural to write if(!strcmp(tag, "HEAD")), but of course
this will break on non-ASCII machines. It is rarely much of a problem since
in most environments you can assume ASCII. If you put the ASCII codes in the
tag would become unreadable.
Nov 14 '05 #98
"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:
"Michael Wojcik" <mw*****@newsgu y.com> wrote

You claimed address 0 was *always* reserved. This "probably" is just
weaseling out.

No one has posted a counter example, which strongly suggests that there
isn't one.


Maybe, but so what? There is nothing to be gained by assuming that
address all-bits-zero is always reserved.

I'd be willing to bet (but not much) that no real-world system will
have a C object at address all-bits-one, but that's no more or less
useful.

There can be some benefit, I suppose, in knowing that the
all-bits-zero address is *probably* reserved for something, even on a
system where a null pointer has some other representation. If you
examine a pointer variable in a debugger (or display it with printf's
"%p" format, depending on how that works), you see that its value is
all-bits-zero, and you happen to know that a null pointer isn't
all-bits-zero on the current system, then it's likely that something
has gone wrong. But if you're doing that kind of low-level
examination of pointer representations , you really should know
something about the system you're working on without reference to any
hypothetical univeral principle about all-bits-zero pointers. That
kind of system-specific knowledge is very different from your original
claim, that the all-bits-zero address is *always* reserved (for
something or other) on all systems.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #99
On Tue, 10 Aug 2004 20:24:19 +0100
"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote:

"Michael Wojcik" <mw*****@newsgu y.com> wrote

You claimed address 0 was *always* reserved. This "probably" is
just weaseling out.
No one has posted a counter example, which strongly suggests that
there isn't one.


I've used embedded systems where it was ordinary RAM from location 0.
These were embedded systems designed with RAM at the bottom of the
memory map and ROM at the top because that was the simplest way to do
it. In such circumstances it would definitely make sense to have NULL as
being something other than all bits zero to avoid wasting a location.
And yes, I think this *is* important here. Some people like to make
pronouncements on c.l.c of the form "X isn't guaranteed by the
standard, but in practice it's always true". That sort of thing
leads to bad practice.

But also helps understanding. If a newbie thinks that something is
likely which he will never in fact encounter, that causes confusions.
Humans are not natural lawyers who can learn a rule divorced from
practical examples.


To be a good programmer you have to learn to understand and work with
abstractions, which is all you have to think of NULL, the null pointer
constant and null pointers as being. They are all just ways of
representing a guaranteed invalid pointer value.

You also have to learn to accept that some things which are incorrect
will work 99.9% of the time, but the time they fail is almost certainly
going to be the worst possible time for you.
I've known plenty of C programmers who think
that in practice the alpha characters are contiguous (in a single
case), but anyone who's had to port C to an EBCDIC machine, as I
have, knows that's not the case, and that there's plenty of code
which breaks on EBCDIC systems because of such assumptions.

A lot of code is like that. For instance IFF files have 4-byte ASCII
identifiers. It is natural to write if(!strcmp(tag, "HEAD")), but of
course this will break on non-ASCII machines.


No, you write something like:
if(!strcmp(tag, IFF_HEAD_TAG))

with a #define in an appropriate header.
It is rarely much of a
problem since in most environments you can assume ASCII. If you put
the ASCII codes in the tag would become unreadable.


If you look at the Chinese character sets you might find this is not
true. Also, if you look at, for example, the character sets as used by
Germans you will find than not all characters counted as letters are
in the caught by:
if ((ch>= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z'))
since you have various accented letters.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

16
2417
by: mike79 | last post by:
Hi all, I have a the following simple piece of code which has taken me hours to try and sort out the problem, but still unable to find what is wrong. void main( void ) { char (*string); .......................(1)
29
3784
by: Jason Curl | last post by:
I've been reading this newsgroup for some time and now I am thoroughly confused over what NULL means. I've read a NULL pointer is zero (or zero typecast as a void pointer), others say it's compiler dependent (and that NULL might be anything, but it is always NULL). The source snippet is below. The question is: - When I use calloc to allocate a block of memory, preinitialising it to zero, is this equivalent (and portable C) to...
41
10079
by: Alexei A. Frounze | last post by:
Seems like, to make sure that a pointer doesn't point to an object/function, NULL (or simply 0) is good enough for both kind of pointers, data pointers and function pointers as per 6.3.2.3: 3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed...
16
10416
by: Abhishek | last post by:
why do I see that in most C programs, pointers in functions are accepted as: int func(int i,(void *)p) where p is a pointer or an address which is passed from the place where it is called. what do you mean by pointing to a void and why is it done? Aso, what happens when we typecast a pointer to another type. say for example int *i=(char *)p; under different situations? I am kind of confused..can anybody clear this confusion by clearly...
64
3967
by: yossi.kreinin | last post by:
Hi! There is a system where 0x0 is a valid address, but 0xffffffff isn't. How can null pointers be treated by a compiler (besides the typical "solution" of still using 0x0 for "null")? - AFAIK C allows "null pointers" to be represented differently then "all bits 0". Is this correct? - AFAIK I can't `#define NULL 0x10000' since `void* p=0;' should work just like `void* p=NULL'. Is this correct?
69
5620
by: fieldfallow | last post by:
Hello all, Before stating my question, I should mention that I'm fairly new to C. Now, I attempted a small demo that prints out the values of C's numeric types, both uninitialised and after assigning them their maximum defined values. However, the output of printf() for the long double 'ld' and the pointer of type void 'v_p', after initialisation don't seem to be right. The compiler used was gcc (mingw) with '-Wall', '-std=c99' and
11
1864
by: Johs32 | last post by:
If I have a pointer and initialize it to NULL does it have the same effect if I initialize it to 0 instead, no matter what kind of pointer it is?
12
10147
by: p.lavarre | last post by:
Q: The C idea of (pv != NULL) is said most directly in Python ctypes how? A: We are of course supposed to write something like: def c_not_null(pv): return (ctypes.cast(pv, ctypes.c_void_p).value != None) Yes?
76
4743
by: valentin tihomirov | last post by:
As explained in "Using pointers vs. references" http://groups.google.ee/group/borland.public.delphi.objectpascal/browse_thread/thread/683c30f161fc1e9c/ab294c7b02e8faca#ab294c7b02e8faca , the pointers are allowed to be null, while references must refer an existing variable of required type. The null is normally used for making optional parameters. But there is no way to pass null reference in C#. Something is missing.
0
9933
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9781
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11123
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10734
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10836
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9567
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7960
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7114
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5982
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.