>> There's just that little overflow problem to worry about,
>
> Ummm:
>
> -- stuff ASCII digits into u64 (or u32, or whatever)
> -- if (still more digits)
> -- printk("partition too big to mount!\n")
> -- return error
>
> How hard is that?
I refer to overflowing the space allowed for your
partition table. Programs will generate the data,
then write it out. If the data gets too long, then
you overwrite part of your first filesystem.
Alternately, the partition table gets truncated
at the maximum size -- with or without a '\0'.
But sure, overflowing a u64 is also a problem.
This will not be checked for. Either the u64 will
get overflowed, or the parser will take what fits
and then mis-interpret the remaining digits as
a second number.
>> trailing garbage,
>
> Don't write garbage into your partition table.
I can see multiple ways for this to happen.
Take the length of the new data, with or without
the trailing '\0', and write it out. Write the
whole partition table, including uninitialized
data that happens to be in memory. (some other
program will of course not ignore trailing garbage)
>> encouragement of assumptions about the maximum size...
>> is that a %d or a %llu or what?
>
> See above. Use leading '-' for negative numbers. ASCII has no
> 2's complement ambiguity issues.
You've got to stuff it into something eventually,
unless you want to implement ASCII math. Will you
be using plain C, or C++ operator overloading?
Yeah, just what we need. The /proc mess expanding
into partition tables. That sounds like a great way
to increase filesystem destruction performance.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/