effect of free()

[Kim Letkeman]

In article <138 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
> In article <990 at kim.misemi> kim at kim.misemi (Kim Letkeman) writes:
> >
> >Can you tell me how you would go about causing an 80286 to trap on
> >load of a "bad" value in the ES That's? This register is internal to
> >the CPU and I doubt that there are any values that would cause a trap
> >to be raised simply by loading them.

> When you load a segment register on an 80286/80386 in *protected* mode
> the CPU actually goes into an in-memory table an load a segment
> descriptor in to an on-chip cache so that subsequent address translation
> is reasonably fast.  If the segment register is loaded with a value
> that does not have an associated segment descriptor then a trap
> occurs.  This normally doesn't cause a problem.  ES is not
> preserved across CALLs.  C compilers on the 80286 are not inclined
> to load ES just to perform a pointer move or compare because

>    1) segment register loads are expensive
>    2) there is no segment register compare instruction

> In *real* mode (MS-DOS) there is no possibility of a bad address trap.

Makes sense. This does seem to add a bit of support for one of the
main themes of this thread (that one should not use pointers after
free() has been called.) 

C compilers run on so many different chips and it is impossible for
every one to know the peculiarities of every implementation. In the
portion of my previous article that is quoted here, I drew a
conclusion based on years of experience with M68000's and with 80x86's
in *real* mode.

I still feel, as posted early in this thread (Aug 24 approx) that it
is not worth the risk to use a pointer once you have disposed of it.

Thanks Scott




-- 
Kim Letkeman    uunet!mitel!spock!kim