cool stuff! On Tue, Oct 17, 2017 at 2:17 AM, Alan Gauld via Tutor <tutor@python.org> wrote:
> On 17/10/17 01:02, Michael C wrote: > > > that is, one number, can be truncated and exist in multiple locations > like > > this > > > > double = 12345678 > > > > 123 is at x001 > > 45 is at x005 > > 678 is at x010 > > That won't happen, a single variable will always be in a a single > area. > > But the representation won't be anything like you suggested. A > single number 12345678(assuming its a decimal integer) will be > stored as 0xbc614e, which is 3 bytes, so it will be part of > a 4byte (assuming a 32bit integer) chunk of storage. > Of course if the program declared the variable to be a long > then the same 3 bytes will be stored within an 8 byte chunk. > And if it was stored as a double floating point value then > the byte representation will be entirely different (and > I don't even know what that would be). > > > unless a number can be broken up like that, wouldn't I, > > while use the silly 'increment by one' approach, > > actually luck out and get that value in it's actual position? > > Yes, if you know that the decimal number 12345678 is stored > somewhere in memory, you can scan looking for the 3 bytes 0xbc, > 0x61,0x4e. And if you also know it was stored in a 32 bit int > you can check for zero before the first byte (or second, or last) > depending on the endian storage system used by your OS). > > But you still don't know for sure that you didn't just find a > byte of 0xbc followed by the start of a UTF8 string beginning > with the characters 'aN'... And there are likely to be several > hits not just one. You need to figure out which are your number > and which are just groups of 3 bytes that happen to look like it. > > If you are very clever you can look at the data surrounding > each set of bytes and make a fair guess about ones which > are not likely to be your variable (as above you might look > to see if the following bytes are all viable ascii characters > which might indicate that it was indeed a string and not > your number). But that may still leave several candidates, > and its all fraught with difficulty. > > If you do know the data types involved you can read your > memory into a buffer and apply the struct module to > interpret it (possibly in multiple ways) to extract > the values but you must know the nature of what you are > reading to be able to interpret it. ie. you need to know > the types. > > Reading the bytes in memory is one thing, and relatively easy. > Interpreting those bytes as actual data is nigh impossible > unless you know in advance what data types you are looking at. > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > http://www.amazon.com/author/alan_gauld > Follow my photo-blog on Flickr at: > http://www.flickr.com/photos/alangauldphotos > > > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
