Prev: The next recall
Next: cop labor monopoly
From: Larry G on 22 Apr 2010 10:02
On Apr 21, 11:17 pm, Scott in SoCal <scottenazt...(a)yahoo.com> wrote:
> Last time on rec.autos.driving, Clark F Morris
> <cfmpub...(a)ns.sympatico.ca> said:
>
> Clark,
>
> Thanks for you reply, but I already know the answer. I just wanted to
> watch Larry hem and haw as he tried to come up with something. :)
>
> Larry, take note: it is the HARDWARE that supports this buffer overrun
> protection. Without the right support from the hardware, there's
> virtually nothing the OS can do to prevent overruns in user buffers.

I admitted early on that I did not know the exact details.. but I do
know that OS can be (or not be written) to deal with buffer overflow
issues (or I though so).. so it sounds like it's not the OS but the
hardware? or did you mean firmware?

From: Larry G on 23 Apr 2010 06:02
On Apr 23, 12:29 am, "Floyd Rogers" <fbloogy...(a)hotmail.com> wrote:
> "Larry G" <gross.la...(a)gmail.com> wrote
>
> >Scott in SoCal <scottenazt...(a)yahoo.com> wrote:
> >> Larry, take note: it is the HARDWARE that supports this buffer overrun
> >> protection. Without the right support from the hardware, there's
> >> virtually nothing the OS can do to prevent overruns in user buffers.
>
> >I admitted early on that I did not know the exact details.. but I do
> >know that OS can be (or not be written) to deal with buffer overflow
> >issues (or I though so).. so it sounds like it's not the OS but the
> >hardware?  or did you mean firmware?
>
> No.  The actual hardware, usually implemented on the processor
> chip, which has bits for memory access rights on a per-page basis.
> Attempts to write beyond the end of a page or writing to a read-
> only page generates a page fault which is then handled by the OS.
>
> But that's only a bare outline.

bring this back to cars and "by-wire" functionality...
From: Larry G on 23 Apr 2010 06:03
On Apr 23, 12:43 am, Scott in SoCal <scottenazt...(a)yahoo.com> wrote:
> Last time on rec.autos.driving, Larry G <gross.la...(a)gmail.com> said:
>
> >> Larry, take note: it is the HARDWARE that supports this buffer overrun
> >> protection. Without the right support from the hardware, there's
> >> virtually nothing the OS can do to prevent overruns in user buffers.
>
> >I admitted early on that I did not know the exact details.. but I do
> >know that OS can be (or not be written) to deal with buffer overflow
> >issues (or I though so).. so it sounds like it's not the OS but the
> >hardware?  or did you mean firmware?
>
> Well, the BEST way to prevent buffer overruns is to use good
> programming practices. However, the most efficient way to verify that
> you're really doing is right is to run your code on hardware that has
> memory protection features. Tools like Purify and Bounds Checker
> leverage this hardware support to detect overruns, memory leaks, and
> the like. The reason you have to buy tools like Purify and Bounds
> Checker is because the OS *doesn't* do those things. :)

okay.. let's bring this back to software that controls "by-wire" auto
functions

From: Larry G on 23 Apr 2010 11:04
On Apr 23, 10:49 am, Scott in SoCal <scottenazt...(a)yahoo.com> wrote:
> Last time on rec.autos.driving, Larry G <gross.la...(a)gmail.com> said:
>
> >> Well, the BEST way to prevent buffer overruns is to use good
> >> programming practices. However, the most efficient way to verify that
> >> you're really doing is right is to run your code on hardware that has
> >> memory protection features. Tools like Purify and Bounds Checker
> >> leverage this hardware support to detect overruns, memory leaks, and
> >> the like. The reason you have to buy tools like Purify and Bounds
> >> Checker is because the OS *doesn't* do those things. :)
>
> >okay.. let's bring this back to software that controls "by-wire" auto
> >functions
>
> We never left. :)
>
> Embedded systems in cars are certainly vulnerable to these sorts of
> problems, and need good programming practices just as much.
> --

I thought it was a hardware issue....

From: gpsman on 22 Apr 2010 01:12
On Apr 21, 11:17 pm, Scott in SoCal <scottenazt...(a)yahoo.com> wrote:
> Last time on rec.autos.driving, Clark F Morris
> <cfmpub...(a)ns.sympatico.ca> said:
>
> Clark,
>
> Thanks for you reply, but I already know the answer. I just wanted to
> watch Larry hem and haw as he tried to come up with something. :)

Sure.

The only thing you've ever previously posted that you know is who is
in your way, why, what they are thinking, and traffic code that you
misapply to your ROW. ;)

> The MFFY Litmus Test:
> If your maneuver forces another driver who has the right-of-way
> to alter course or speed, what you did was probably MFFY.

A litmus test for MFFY suggests the obvious.
-----

- gpsman
 |  Next  |  Last
Pages: 1 2
Prev: The next recall
Next: cop labor monopoly