Re: Fastcode Memory Read Rules
- From: "Bart van der Werf" <bwerf@xxxxxxxxx>
- Date: Sat, 10 Mar 2007 22:59:26 +0100
"Dennis" <marianndkc@xxxxxxxxxxxxxxx> wrote in message news:45f315d0@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi
The two rules are for different string types
"It is allowed to read past the end of AnsiStrings and WideStrings including
the dword containing the zero-terminator."
Maybe this can be cleared up ?
How far beyond the end of the ansistring can allways safely be read and is garuanteed to not violate the general rule ?
does this mean you can read past the end aslong as the dword you are reading is alligned and atleast contains the trailing #0 ?
I can't image that the allocator would waste more then maybe 8 bytes?
Having written a checking allocator and trying to allign on byte instead of 8 byte boundaries i quickly ran into problems with fastcode :)
"It is not allowed to read past the end of ShortStrings and PChar strings."
Sounds good because these pchars might not be allocated using the local memorymanager but might come from some outside system and alligned on the end of a page. so this might be a slightly overly strict way of enforcing the general rule.
They are both more strict than the global rule
"It is allowed to read anywhere from any memory page containing at least one
byte of a ShortString, PChar, AnsiString or WideString string, including a
#0 terminator."
Strictly speaking this rule is ok aslong as hardware memory protection stays the same, but be aware that the size of a page can change in the future.
If they are removed then we will have the global rule for all targets, which
is much easier to handle in the B&V. If the global rule is 100% safe, which
we believe it is, then we do not need the two stricter rules for the RTL
replacement target (now renamed as IA32 size penalty target).
The global rule might be safe in the sense that it won't cause accessviolations, and fine aslong as the rules for writing are alot more strict.
but code writters do need to take care to be able to proccess pchars that do not start on an alligned bounary and where the first byte after then #0 might fall in a page with no read rights.
Memory pages are 1024 byte and they are read/write protected on a page
4096bytes ?
basis. This means that if you can read one byte from the page then you can
read the entire page without getting an AV. This means that you can read any
X byte aligned X byte sized block from the page without reading across a
page boundary. If you read a string in 16 byte aligned chunks then you are
safe as long as at least one byte is on the page where the string is
located.
16 byte ? hmz i only allign on 8 bytes in my own paging allocator, so this could run into problems with fastcode ?
The stricter rules ensure that only memory allocated for the string is read.
AnsiStrings/WideStrings are 4 byte aligned and 0-3 bytes after the end of
the string is allocated for it.
ShortStrings/PChars are not guaranteed to be aligned.
Feel free to ask again. Perhaps somebody else will help me explain the
rules?
Best regards
Dennis Kjaer Christensen
.
- Follow-Ups:
- Re: Fastcode Memory Read Rules
- From: Q Correll
- Re: Fastcode Memory Read Rules
- From: Dennis
- Re: Fastcode Memory Read Rules
- References:
- Fastcode Memory Read Rules
- From: Dennis
- Re: Fastcode Memory Read Rules
- From: Dennis
- Re: Fastcode Memory Read Rules
- From: Dennis
- Re: Fastcode Memory Read Rules
- From: Q Correll
- Re: Fastcode Memory Read Rules
- From: Dennis
- Fastcode Memory Read Rules
- Prev by Date: Re: Fastcode Memory Read Rules
- Next by Date: Re: Fastcode Memory Read Rules
- Previous by thread: Re: Fastcode Memory Read Rules
- Next by thread: Re: Fastcode Memory Read Rules
- Index(es):
Relevant Pages
|