I cant find it anywhere, has anyone got any ideas ?
Answers can be mailed to mailto:ghe...@bit.net.au
Thanks very much in advance.
Glen
Yes! Somewhere, you are assinging a value to a null pointer...... :)
e.g.
*p=some_value; /* and p=NULL! */
hope it helps
O. Khe
GH> Answers can be mailed to mailto:ghe...@bit.net.au
Please mail your answers in this newsgroup, too. There are several people
out there who wants to know this (like me).
Ciao
Oli
--
Oliver Kurowski 09453/495
Der Mensch schuf Gott nach seinem Bild. <Ludwig Feuerbach>
## CrossPoint v3.11 R ##
Those errors many times come because you forget to malloc for the array
pointers, structure pointers and try to use the variable. It is very
difficult to say where this error can be occuring.
Another reason might be insufficient
available memory which cannot be checked. I recall an experience when
after mallocing I was confirming that the area has actually been malloced
by comparing the pointer with null. Still the program was giving null
pointer assignment somewhere. This was not observed when I removed unwanted
TSR's from memory.
Just check whether you are not using unmalloced pointers and
sufficient memory is available for program execution.
--
cheers,
ccn@kailash
[----------------------------------------------------------------]
Problems cannot be solved from within the framework in which
they are created. -- Albert Einstein.
[----------------------------------------------------------------]
>I have written a game (Glentris (downloadable from
>http://www.bit.net.au/~ghendry)) and when you quit out of the game it gives
>a null pointer assignment error. It is almost all in C (turbo C).
Does your program try to free() any NULL pointers on exit? This
should do nothing, but who knows what your compiler is doing? You
don't try to read or (even worse) write to a NULL pointer just before
exiting the program?
Check every single pointer in your program, especially in the main()
function, and make sure they are not NULL when you access them.
----- Dig the EVEN NEWER, MORE IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
http://aardvark.apana.org.au/~phaywood/
============= Ain't I'm a dawg!! ==============
Michel Robert
Montreal
In article <E7rq3...@bhishma.cse.iitb.ernet.in>, c...@cse.iitb.ernet.in
says...
>
>Glen Hendry (ghe...@bit.net.au) wrote:
>: I have written a game (Glentris (downloadable from
>: http://www.bit.net.au/~ghendry)) and when you quit out of the game it
gives
>: a null pointer assignment error. It is almost all in C (turbo C).
: Go away Albert, you're bulshitting again
Moreover, I don't think Einstein ever said anything like that. It sounds
to me like a paraphrase of Bertrand Russell's coming to grips with the age
old "all Cretians are liars" paradox (when stated by a Cretian).
The prototype of this kind of problem is the "set of all sets that
do not contain themselves as subsets".
--
*******************************************************************
Martin F. Sohnius msoh...@novell.co.uk
Novell IS & T, Bracknell, England +44-1344-724031
*******************************************************************
* if (status = UNDER_NUCLEAR_ATTACK) *
* launch_full_counterstrike(); *
*******************************************************************
(C) 1997 M.F.Sohnius -- free distribution on USENET
(Not a spokesperson -- just a cyclist!)
> Groovy hepcat "Glen Hendry" was jivin' on 26 Mar 1997 01:06:23 GMT in
> comp.lang.c.
> Problem : NULL POINTER ASSIGNMENT's a cool scene! Dig it!
>
> >I have written a game (Glentris (downloadable from
> >http://www.bit.net.au/~ghendry)) and when you quit out of the game it gives
> >a null pointer assignment error. It is almost all in C (turbo C).
>
> Does your program try to free() any NULL pointers on exit? This
That's probably not it.
Some DOS C compilers try to catch NULL pointer accesses (while using
"near" (i.e. 16 bit) data pointers) by having the "NULL" position of the
64K data segment filled with a particular pattern, and checking this on
exit().
"NULL pointer assignment" is the typical error message in that case.
Unfortunately, it's about as useful as "This program contains a syntax
error somewhere, but I'm not going to tell you where".
The typical solution in cases like that is divide-and-conquer. In this
case, try doing the check earlier to find the place where it happens -
either by putting exit() into your code, or by using weird nonstandard
tricks like checking the bytes that NULL points to.
Or else port the stuff to a reasonable Unix system (reasonable = NULL
pointer dereferencing always gives a SIGSEGV).
Kai
--
Internet: k...@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/private/khms/