The free() thing and function names

[Joerg Lehners]

bill at twwells.com (T. William Wells) writes:

>[a bit deleted]

>Free() is defined in the dpANS library. That being the case, the
>compiler is free to assume that the pointer's value is not being used
>legitimately after the call. It knows that the object to which the
>pointer pointed no longer exists, so there is no valid use of the
>pointer's value.

>During code generation, it could mark the location the pointer is
>stored in as dead right after the pointer's value is made available
>for the free call, since it knows that there can be no legitimate
>reason to access the value of the pointer.

>[description and example C and 8086 code deleted]

I don't like this idea at all.
Don't hardcode any (even standard) functions into the compiler.
What about writing my own free() function, possibly with a completly
different semantic ?
The compiler has no chance to detect such a case on most systems, because
compilation and linkage are independent (is this independence standardized
at all ??).
On the machine I use, there are such things of compiler detected functions
for floating point operations: whenever I declare a function sin()
(arguments aren't checked -- no prototyping) WITH return value double
(as done in math.h) then the compiler generates some code for the
floating point coprocessor inline. Such things are evil enough.
But it seems the only way to make floating point operation real fast.

I wan't to feel free about naming my function's. Even overriding of
standardized functions should by possible (in my eyes).
(I know about the problems doing this when using other standardized
functions like the ones from stdio).

What does the standard say about standardized function overriding ?
Maybe one have to distingish between
   a.) C-Compiler: just the C keywords are reserved,
       function overriding possible and possible more.
   b.) C-System (C-Compiler plus standardized function package [often
       called 'library']: C keywords reserved; return type, argument types
       of standardized functions reserved; and more.

>So if you want to write portable programs, you had better assume that
>a freed pointer has no value that you should look at. Because it may
>have no determinate value.
I agree. The usabilty of a pointer after free() upto the next malloc
package function call should never have been a feature.

  Joerg
--
/ Joerg Lehners                       | Fachbereich 10 Informatik ARBI   \
|                                     | Universitaet Oldenburg           |
| BITNET/EARN: 066065 at DOLUNI1.BITNET  | Ammerlaender Heerstrasse 114-118 |
\ UUCP/Eunet:  lehners at uniol.uucp     | D-2900 Oldenburg                 /