Re: Nice Article
> This isn't a bug. C variables aren't
> guaranteed to contain any particular
> value (this may be different in C99? I'm
> not sure, but I doubt it). Not having to
> make sure it's initialized to zero saves
> time; ergo, an optimization. :)
global and static variables ARE null (or zero) by default.
static int bar;
"foo" and "bar" are guaranteed to be initialized to zero. "baz" is not, it'll be undefined.
("initialized to zero" just means the compiler/linker puts them in the executable's "bss" segment, which is mapped with zeros before execution begins. This is actually more efficient than explicitly initializing with "int foo = 0;" since they won't take up space in the binary on disk, as "int foo = 0" will!)
signedness and off_t
One area where the UNIX file API has always been inconsistent is the signedness of file sizes and offsets. Naturally a file size is an unsigned quantity, but consider read() and write(), which want to return -1 for errors, or lseek(), which naturally should allow seeking backwards. I think one can build a case for either changing the APIs to use unsigned arguments everywhere, or giving up a bit and using signed arguments everywhere. But either of those have got to be better than the status quo, where you can't seek to an offset greater than 2^31 or 2^63 in one step, or write more than 2^31 or 2^63 bytes at once. (granted nobody is likely to want to write 2^64 bytes in one call, but 2^32 could happen today - and there is nothing in the API that should indicate it will fail, aside from the return value being interpreted incorrectly)
I should add that very few programmers are careful enough to write code that will continue to work when the file size creeps up into the sign bit. (e.g. this is a problem with 32-bit AVI files on Windows - the AVI standard consistently works for file sizes between 2^31 and 2^32, but lots of AVI-parsing software breaks when the size exceeds 2^31).
One problem with redefining off_t is that lots of software uses other types internally. e.g.
int my_get_filesize(const char *path)
struct stat ss;
which is never going to work for 64-bit files (because it returns an 'int'). With luck the compiler will notice the 64->32 conversion and alert the programmer. However, you can't assume that by re-defining off_t most software will "just work."