On Wed, 9 Jan 2002 07:58:03 -0600
Robert Wittig <[EMAIL PROTECTED]> wrote:
> Sam,
>> Bad HTML can lock up your computer and you will have to reboot.
>> I could refer you to several websites that will consistently
>> cause Arachne to crash. I know that there used to be some
>> websites out there that will always cause MSIE or NetScape
>> to crash. About three years ago I used to know about a web
>> page
>> that had links saying something like "Click here to crash MSIE"
>> and "Click here to crash Netscape" and "Click here to crash
>> Arachne". According to what was being said about the site
>> on a mailing list I subscribed to at the time, all of the links
>> were reported to work exactly as advertised!
>> Bad HTML usually contains inserted so-called Java Scripts or
> Java
>> Applets which run like executables to cause your computer to
>> crash. Of course not all so-called Java Scripts and Applets
> are
>> bad.
> Well, I will restrain myself from saying I am 100% sure I am
> right, but in my experience, I have never seen HTML crash a
> browser, and I would be very interested in seeing an example that
> would do such a thing.
Just plain straight-up HTML on pages where there is no
JavaScript or other gizmos can cause a browser to crash.
This has been pointed out in specific examples offered by
Ben A.L. Jemmett in his comments in this edition of the SurvPC
List Digest.
> On the other hand, when I said HTML, I was referring specifically
> to HTML, and not JavaScript, Java Applets, Perl Scripts, or any
> other scripting language, which I agree, can crash a browser, and
> have probably been responsible for many of the crashes I have
> experienced.
>> I haven't yet encountered the problem of overwriting my memory
>> allocations. I haven't yet seen this happen probably because I
>> have considerably less experience with C than you do. I do
> have
>> enough experience to have learned that C can do all kinds of
> other
>> disastrous stuff to me when I really screw up <g>. The
> compiler
>> isn't the culprit. If you accidently shoot yourself in the
> foot
>> you shouldn't blame the gun, even if the gun is found to be
>> defective in design and manufacture.
> Well, actually I have only been programming in C/C++ for about 6
> months, but that is 6 months, several hours per day, seven days
> per week.
Then you have a little bit more experience with it than me, and
your experience is very recent and fresh in your mind. I haven't
dedicated myself to doing a lot of C at any time during the last
five years or so. Nowadays I just dabble with it now and then.
> Overwriting a memory allocation is as simple as assigning too
> many characters to an array, for example: 'char cArray[2] = {'A',
> 'B', 'C'};' The C or C++ compiler will allow you to do this,
> because it expects the programmer to have enough sense not to do
> this, instead of having rules written into it forbidding the
> programmer from making such an error. 'C' winds up getting
> written to a memory address that is not reserved for cArray, and
> if that address is already written to by something else, it is no
> longer accurate. This is all that I was referring to.
I am aware of these kinds of errors. I thought you were referring
to problems that were more drastically bad.
> The compiler *is* the 'culprit', in the sense that it is
> deliberately designed to allow the programmer to do all sorts of
> things that might not be sound programming, if the programmer is
> careless enough to do them. From what history I have read, this
> was done with deliberation, by the compiler designers, who
> thought that it was better to have a compiler that would allow
> for maximum creativity (such restrictive compiler rules might
> also wind up forbidding the programmer from performing some other
> programming feat, that no-one has even thought of yet, but which
> might revolutionise the entire language), than a 'safe' compiler,
> that would protect a stupid programmer from him or her self. I
> personally agree with this idea.
I can agree with you on the matter referred to above, but only
within the specific context and sense whereof you speak.
> On the other hand, I think that your analogy with the gun fails
> utterly. If you shoot yourself in the foot with a gun that is
> found to be defective in design or manufacture, in a manner that
> causes the gun to fire in a case where a non-defective gun would
> not have been able to fire (for instance, if you had the safety
> set, but it was defective), I think that the maker would bear
> some responsibility for your injury.
I disagree. There is no federal law, nor is there any law in my
state mandating that a gun be provided with a safety mechanism
meeting any kind of "approved" design criteria. A gun manufacturer
isn't even required by federal law to provide any safety mechanism
whatsover. (There are some state laws, but none in my state, that
address such matters.) Furthermore, if you read the manufacturer's
manual you will always find warnings, often printed in bold red
letters, saying that you should never rely on a gun's safety
mechanism, and you should always keep the muzzle pointed in a safe
direction, etc. If you don't have an owner's manual you can download
one for free from the manufacturer's web site in the case of almost
all guns they have produced during the last few decades. If they
don't have a downloadable manual they will usually offer to send you
a printed one for free via snail mail. Almost every adult is aware
of these rules found in gun owner's manuals and in NRA publications.
All responsible adults respect the safe gun handling rules most
highly. Furthermore, anyone who allows an irresponsible, misbehaved,
or improperly trained child unsupervised access to a gun ought to be
prosecuted as a criminal, IMNSHO.
>> > It is pretty funny, how many messed up scripts there are on
> the Web,
>> > though. My debugger detects them and goes off while I am
> surfing,
>> > asking me if I want to debug.
>> I don't think it's funny at all. I think it is pathetic.
> I guess I don't take this sort of stuff as seriously as you do. I
> still remember the first incarnation of my website (just 20
> months ago), and how cool it looked in MSIE 5, and how proud I
> was of myself... until I started getting complaints from people
> using Netscape, Opera, etc. I am still fixing bugs in my HTML...
> of course, these are second and third generation bugs, and not
> nearly as many or as glaring as the first generation bugs.
Did you use Micro$oft web-page authoring tools? Micro$oft is
notorious for helping people to create web pages that won't work
with any browsers other than their own.
> The same thing goes for a lot of the programs I write, in C/C++.
> They are continually pushing the edge of my knowledge, and come
> complete with the kinds of bugs one would expect to find, in the
> work of a programmer of my skill level. My studies in Lin/Unix
> administration tasks are doing well, too... I have successfully
> rendered my operating system totally unbootable w/o a rescue
> disk, writing global environmental variables on several
> occasions! Now I have also finally succeeded in getting Borland
> TASM 5.0 up and running, and have written my first couple
> programs in Assembly Language as well, so I am looking forward to
> crashing my boxes (DOS, Windows98 and 3.1, and Linux) in ever
> new, and more creative ways, in the New Year.<g>
It sure is fun to be able to drive such powerful machines under
conditions where nothing terribly tragic can happen to you or
anyone else if you make a mistake and crash them. I wish it
were possible for people to safely drive their cars as recklessly
as they drive their computers, and without the risk of hurting or
injuring anyone for real. I guess that is what race car simulator
games are for.
Regards,
Sam Heywood
-- This mail was written by user of The Arachne Browser - http://arachne.cz/
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
