So make it network byte order.
How many bugs have you heard of with bad use of sscanf() ?
The counters *are* host specific. Available memory is 32 bits somewhere, 64
other places. That's the world we live in and hiding the difficulties in ASCII
that *can* be parsed so that it only breaks "sometimes" doesn't help the
application developers.
Better to face the facts, and get over it.
> It had been tried. Many times. It had backfired 100 times out 100.
> We have the same idiocy to thank for fun trying to move a disk with UFS
> volume from Solaris sparc to Solaris x86. We have the same idiocy to
> thank for a lot of ugliness in X.
>
> At the very least, use canonical bytesex and field sizes. Anything less
> is just begging for trouble. And in case of procfs or its equivalents,
> _use_ the_ _damn_ _ASCII_ _representations_. scanf(3) is there for
> purpose.
>
scanf can be used wrongly in more ways than the two of us can imagine
together, even if we try.
I disagree with harmonizing field sizes - that doesn't make sense. What's
64 bits today is 128 tomorrow (IPv6 related things, crypto, ...), what
used to fit in 32 is in 64, some places.
Having a library that gives you either compile-time errors if you use it
wrong, or barfs loudly at run-time is one hell of a lot better than having
silent mis-parsing of ASCII values.
-- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - 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/