On Thu, Jul 12, 2007 at 04:49:35PM +0200, Stefan Reinauer wrote:
- unsigned int *ptr = (unsigned int *) (lar->map + (filelen - 12));
What about all this pointer arithmetic? Is it really correct?
This code is not new, it is in another file already.
Yes. Sorry. It's fine.
Doesn't adding 1 to a pointer actually add sizeof pointed-to-type to the address? Ie. this code isn't portable?
What makes you think so? It fetches an int from 12 bytes before the end of the file (ie. after the reset vector).
I did not pay attention to the type of lar->map.
It is of course not portable because there is no reset vector at fffffff0 on non x86 machines. But that's another issue.
..
but then writing size to p[0] will write a different number of bytes on different archs, right?
int is 32bit on all GNU architectures I know that could theoretically run LinuxBIOS.
My point is that this is lar and not LB. While LB is completely tied to the architecture we want lar to be the opposite. I expect lar and larballs to be platform independent, just like other archivers and good file systems. :)
But since this is an x86 only thing anyways I would not care too much.
lar shouldn't be an x86 only thing, should it?
- lar = _open_lar(archive, s.st_size, O_RDWR);
Race conditions. First open() then fstat() to get the size.
What kind of situation that realisticly happens would produce such an issue? i.e. While a payload builds a lar, or while LinuxBIOS is compiled?
Interactive buildrom and automated v3 abuild running at the same time e.g. (In the same place.)
Yes, it's rather theoretical and there's no point in jumping through hoops trying to recover from it - I'm requesting a way to measure that the larball was broken by someone else and that lar doesn't create a crazy big file.
//Peter