Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 20 Dec 1999 17:34:21 +1300 | From | Chris Wedgwood <> | Subject | Re: Ok, making ready for pre-2.4 and code-freeze.. |
| |
> Basically, I don't like "long long". I use it only when I absolutely > _have_ to, and we didn't have to in this case.
Fair enough.
> The shift from "long long" to a 32-bit "index" has to be done somewhere > anyway - the 32-bit index is the internal kernel way of doing things, and > makes perfect sense. So why not just do it in user space - that way people > who want to be clever CAN be clever (imagine a compiler that inlined the > shift and combined it with some other operation done on that argument).
OK
> The reason I don't like "long long" is that (a) gcc has historically had > tons of bugs in code generation for it and (b) it makes the generated code > impossible to read. The memory management is one of the areas where I > still =do= read the generated assembly every once in a while..
This seems reasonable, and it doesn't preclude the ability of a library interface having a u_int64_t interface either. I think once we support large files for other API like stat it should make application code much cleaner.
I really like the idea of being able to so something like:
u_int64_t offset;
f = open("really/bin/file",O_RDRW); fstat64(f,&st); /* probably doesn't need new syscall */
[...]
offset = 3ul*(1024*1024*1024); /* 3GB offset */
ptr = mmap64(NULL,small_size,PROT_READ|PROT_WRITE,MAP_SHARED,f,offset);
/* ptr now maps to 3GB offset into file... */
-cw
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |