Re "Cast? Why do you want to do that?" one might respond with cases such as
- variant types,
- code to implement a container/collection with arbitrary payloads, or
- because I want to do something naughty.
OK, maybe my one-liner was a bit cryptic (mea culpa). The
less-abbreviated version reads more as the following:
The underlying conceptual model for C is computer hardware. For
example, a pointer "is" a memory address, and it is very easy to
mis-use such things in a way that corrupts data, provides meaningless
results, etc.
The underlying conceptual model for Java is ... Java objects, (mostly)
without regard for the physical environment in which the object may be
found at a given time. Both the notation and the run-time behavior
assist in maintaining that model.
This thread began with Neil's post urging that security be an early
consideration rather than an afterthought. To me, security has (at
least) two aspects:
- helping a well-intentioned person avoid doing Bad Things, and
- preventing an ill-intentioned person from doing Bad Things.
As C is a general-purpose programming language, one CAN use C in a way
to implement any concept that exists in any other language--although
the form of expression may vary quite dramatically in readability! ;-)
However, implementing nice concepts (and avoiding Bad Things) in C
often requires that one code to certain conventions and
"gentleperson's agreements" which are at a conceptual layer outside
what the language itself specifies or requires.
So, when I said that a pointer "is" a memory address, I didn't mean
that a well-intentioned person could ONLY think of it in that way
(although that was still the common explanation, the last time I
looked at beginning C materials). I meant that it is trivially easy
for a programmer (either through ignorance or malice) to access/modify
an arbitrary chunk of bits (at least within one's own process space)
in a way that makes Bad Things happen sooner or later, and in a way
that can be highly difficult to track down. The very fact that there's
such a thriving market for development tools to detect memory leaks
and other kinds of pointer abuse (deliberate or accidential is beside
the point) is an indication that this is a problem.
The alternative to spending lots of energy on detection and
remediation of certain kinds of problems/defects is to spend a little
energy up front to prevent those problems/defects from occurring to
begin with.
-jn-
On 7/4/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
> Geir Magnusson Jr. wrote:
> >
> > On Jul 4, 2005, at 4:00 AM, Ben Laurie wrote:
> >
> >> Geir Magnusson Jr. wrote:
> >>
> >>> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
> >>>
> >>>> Joel Neely wrote:
> >>>>
> >>>>
> >>>>> Typed, constrained object references vs. untyped, unconstrained
> >>>>> pointers.
> >>>>>
> >>>>>
> >>>>
> >>>> C has typed pointers.
> >>>>
> >>> How are they really typed? In Java, I'll get a runtime exception
> >>> when I mis-cast... In C, IIRC, I get long hours of debugging...
> >>>
> >>
> >> Cast? Why do you want to do that?
> >
> >
> > I'll take this as a straight question, although I can actually hear you
> > saying it and I'm suspicious :)
> >
> > I actually never understood why I do it other than for readability,
> > because I do think that the runtime can figure it out.
> >
> > There's a legitimate use when upcasting to a superclass.
> >
> > public class Bar {
> > }
> >
> > public class Foo extends Bar {
> > }
> >
> > Foo f = new Foo();
> >
> > Bar b = (Bar) foo;
>
> I meant in C (which doesn't have superclasses).
>
> --
> >>>ApacheCon Europe<<< http://www.apachecon.com/
>
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
--
my morning coffee
middle-aged american
tea ceremony
