Poxy old computers (was RE: [extropy-chat] SPACE: Spirit Prob lems)

[Emlyn O'regan]

> -----Original Message-----
> From: Harvey Newstrom [mailto:mail at HarveyNewstrom.com]
> Sent: Tuesday, 3 February 2004 10:52 AM
> To: ExI chat list
> Subject: Re: Poxy old computers (was RE: [extropy-chat] SPACE: Spirit
> Prob lems)
> 
> On Monday, February 2, 2004, at 05:50 pm, Emlyn O'regan wrote:
> 
> > Adrian wrote:
> >> including the
> >> "nevers" such as strcpy instead of strncpy (or, at
> >> least, strcpy into a buffer that could be smaller than
> >> necessary).
> >
> > You can fix a lot of these kinds of problems, also, by only 
> writing in 
> > C
> > when there is absolutely no alternative. Which is really 
> rather seldom.
> 
> Actually, this is not true.  Other computer languages have the same 
> basic computer problems as C, usually.  They just hide them from the 
> user.  For example, C has pointers that tell you where a 
> string starts. 
>   If a pointer is null or points to the wrong spot, you can have a 
> problem.  Java doesn't have pointers defined in the language.  Most 
> people believe that Java therefore doesn't have pointers in the 
> programs.  Not so!  The Java compiler does indeed use 
> pointers, just as 
> all machine-language compiled code does.  It just does not 
> provide any 
> language equivalent to discuss them or utilize them.  Java 
> programs can 
> still crash with a null-pointer error, which confuses Java people who 
> think it has no pointers.

Yes, Java doesn't have pointers, it has object references instead, which
suffer from the same problems of referencing uninitialised memory as other
languages (or at least trying to dereference a nil variable as if it were an
object). But what you wont do (unless you try really really really hard) is:

- Access a freed but not nil object reference (because you have to clear
them for the gc to take the object away).
- Access an uninitialised but non-zero reference (because (I think) the
references are all initialised to nil)
- Leak memory (unless you really work at it)

Yes, there are pointers, but they are not as general, and so not anywhere
near as prone to screw ups. In general, it's much easier to get things
right. There are also lots of pointers under the covers in the VM, doing the
abstraction for you, but we'll assume the VM writers and compiler writers
are getting it right :-)

> 
> Another example:  In C, a string of characters is an array of 
> characters.  So the variable NAME_ONE is really a pointer to a series 
> of characters.  In C, if you set NAME_TWO to equal NAME_ONE, only the 
> pointer is copied.  Both variables point to the same sequence in 
> memory.  Thus, any changes to NAME_ONE magically appear changed in 
> NAME_TWO, because they really are overlapping memory spaces.  Guess 
> what?  Java does the same thing.  Only without the pointers, it isn't 
> clear.  Declare a Java string called NAME_ONE.  Declare another 
> variable called NAME_TWO and set it equal to NAME_ONE.  Suprisingly, 
> any change to one variable appears in the other.

That's not surprising for any half decent programmer. It may sound
unintuitive, but if you compare it to C or C++ string handling (including
all the various libraries you'll run across, the hell of trying to convert
between them, the sheer verbosity of managing strings in C compared to a
high level language), it really is child's play.

> Many Java 
> programmers 
> don't know this, because they don't know how the underlying pointers 
> and structures are being used.

Well, shitty coders are shitty coders, you can't do much about that (except
watch them closely and carry a big knobbly blunt instrument).

The amount you need to know, however, to get it right in C or C++ vs get it
right in Java is very different.

> 
> It is not clear to me if Java fixes the problems of C, or just hides 
> them so they are harder to see.
> 

It doesn't fix them. Hand coding is always going to suffer from issues like
this, full stop. What it does do is to strongly ameliorate these issues. So
that for domains to which both C (or C++!) and Java are applicable, Java
coding can be done far more quickly and more accurately by someone with a
lower skill level than that required for C/C++ programming. 

I'll issue a disclaimer here that I've hardly written any Java; I'm
primarily Delphi programmer (who also writes a lot of everything else, like
everyone else also does). Delphi's a lot like Java, but has pointers and no
GC, so has more of the C pointer issues (although you can stick to object
references and never have the problems). You can always theoretically say
that all the languages are equivalent, and can theoretically face the same
issues, so you may as well pick C/C++ because it's industrial strength. But
in practice, the (good) higher level languages really crap all over C/C++
for productivity, reliability, and general ease of use for domains to which
both are applicable. We would have a lot less of those nasty coding related
security issues if people stuck to the right languages in the right
circumstances, and ditched C/C++ for application development. 

Emlyn

> --
> Harvey Newstrom, CISSP, CISA, CISM, IAM, IBMCP, GSEC
> Certified IS Security Pro, Certified IS Auditor, Certified InfoSec 
> Manager,
> NSA Certified Assessor, IBM Certified Consultant, SANS Certified GIAC
> <HarveyNewstrom.com> <Newstaff.com>
> 
> _______________________________________________
> extropy-chat mailing list
> extropy-chat at lists.extropy.org
> http://lists.extropy.org/mailman/listinfo/extropy-chat
>