Jim Meyering <[EMAIL PROTECTED]> writes: > Is it really permitted to have sizeof (size_t) < sizeof (unsigned int)?
Yes, I'm afraid so. The C Standard merely says that size_t is an unsigned integer type; size_t is allowed to be narrower than unsigned int. See, for example, Mark Brader's 10-year-old post on this subject in <http://groups.google.com/group/comp.std.c/msg/70cbd32ec8543738> (originally <news:[EMAIL PROTECTED]>). > Sounds pretty darn perverted, and I'll bet it would make lots of code break. I agree. I can't imagine it occuring on a general-purpose host. Maybe some of the odder embedded hosts. It's not worth worrying about if it takes real work to make the code portable. >> Also, I'd rather not penalize all compilers just because GCC is busted. > > I understand the point, but wonder if this `penalty' > is even measurable, in practice. Not here; but I am a bit worried about the precedent. Checking for size-arithmetic overflow can slow things down quite a bit in some other cases. (Perhaps I'm being overly influenced here by the regex code, which I've been looking at for a bit, and which I'm afraid contains many arithmetic-overflow bugs....) > The offending warning breaks coreutils' `make distcheck' rule. Would it make sense to rewrite coreutils 'make distcheck' to filter out the bogus diagnostics? That might be a simpler fix. > The cure, with all of those #if's, is looking worse than the disease. You've convinced me. Let's ignore that #iffy patch and try to come up with a better solution to the real problem. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib