Check for NULL before calling free()?

[Nick Keighley]

that's a nice way of putting it!

I think Ersek and you are talking past each other a bit.  I suspect you
don't have the same mother tongue.

I grew up on windows so became weaned on OS's killing applications or
letting them run roughshod.

be careful "windows you grew up on" isn't Windows NT. Windows 3.x (or
whatever) was a bit of hack it used cooperative multi-tasking and had
little memory management and slightly iffy resource mangement. Some
people (not me) said it wasn't "really" an OS. Windows NT was a real
OS by any definition. MS used to have two lines of OS development one
for home/games without much protection and a proper kernel based OS
for everyone else. They merged those lines long ago (XP I think)

 

[Nick Keighley]

Yes.  strtok does not allocate any memory.  It return pointers into
the buffer so freeing the buffer is enough.  

just to make sure Poster Matt knows what's going on. strtok() actually
modifies the string it's passed. So readBuffer gets hacked by strtok
(). readBuffer must be a writeable string (so no string literals
should be passed to strtok()). strtok() may give problems in multi-
threaded environments because it stores internal state in static
variables. Calling strtok() more than once in the same expression will
probably be bad news. Some people don't like how it behaves if you two
delimiters in succession.

"wombat==megabowl"

 

[Nobody]

Windows NT was a real
OS by any definition. MS used to have two lines of OS development one
for home/games without much protection and a proper kernel based OS
for everyone else. They merged those lines long ago (XP I think)

XP has an NT kernel, but also includes features which weren't previously
available on the NT branch (primarily DirectX), which eliminated the last
remaining reason for the existence of the 95/98/ME branch.

 

[Tim Rentsch]

Strictly speaking a null pointer is defined as ((void*)0) which points
to the zero address. The only real reason that causes problems on

Strictly speaking, ((void*)0) is a null pointer constant. It only
becomes a null pointer after it is converted to pointer type.
[6.3.2.3-3]

Strictly speaking, the expression '((void*)0)' already has pointer
type, and the value of this expression, just as it stands, is
already a null pointer.

 

[Stefan Ram]

Strictly speaking, ((void*)0) is a null pointer constant. It only
becomes a null pointer after it is converted to pointer type.
[6.3.2.3-3]

Strictly speaking, the expression '((void*)0)' already has pointer
type, and the value of this expression, just as it stands, is
already a null pointer.

Possibly, Barry intended to write:

»Strictly speaking, 0 is a null pointer constant.
It only becomes a null pointer after it is converted to
pointer type.«

 

[Tim Rentsch]

Strictly speaking, ((void*)0) is a null pointer constant. It only
becomes a null pointer after it is converted to pointer type.
[6.3.2.3-3]

Strictly speaking, the expression '((void*)0)' already has pointer
type, and the value of this expression, just as it stands, is
already a null pointer.

Possibly, Barry intended to write:
It only becomes a null pointer after it is converted to
pointer type.<<

Yes, good observation. That didn't occur to me.