On 1/23/2012 1:38 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > You can always use a limit dictated by allocated bits and if it exceeds > this, you need to issue a warning. > However if the light of hpa's statement I suppose that it should handle > the overflow somehow as well.
That's why I said that technically linux.c should throw an exception warning when you exceed the kernel limit, but it has never done this before ( when the limit was much lower ), and now that the limit is so high, seems very unlikely to ever happen, so I'm not sure it's worth the bother. > Also any code asking for limits when there is none is either also > limited by something else or is against GNU Coding Standards. linux.c uses the lower of the two limits: what the kernel supports, and what the partition table supports. Given that the partition table claims to only support X partitions, then it assumes there can not be more than X partitions, even if the kernel supports it. This is why it was wrong for dos to claim a limit, but not enforce it. As for what that limit is, it could 65535 for all I care, but whatever the partition table claims its limit is, should actually be the limit.
