On Thu, 1 Aug 2002, Thunder from the hill wrote:
> Hi,
>
> On Wed, 31 Jul 2002, Alexander Viro wrote:
> > What the bleedin' hell is wrong with <name> <start> <len>\n - all in ASCII?
> > Terminated by \0. No need for flags, no need for endianness crap, no
> > need to worry about field becoming too narrow...
>
> Well, why not long[] fields? Might be more powerful, and possibly not any
> slower than ASCII.
More powerful in which way? I see where it's less powerful - sizeof(long)
is platform-dependent and so is endianness. More powerful? Maybe, if
you have integers that do not have decimal representation. I've never
heard of such beasts, but sure would appreciate some examples.
As for the Martin's comments... Martin, if you can't write a function
that checks whether array of characters has a contents fitting the
description above - stand up and say so. Aloud. In public.
The fact that thousands of selfstyled "programmers" manage to screw that
up says only one thing - that they should not be allowed anywhere near
programming. Because the same guys screw up in _anything_ they do,
no matter what data types are involved. ASCII is tough? Make it "arithmetics
is tough". Examples on demand, including real gems like
fread(&foo, sizeof(foo), 1, fp);
if (foo.x >= 100000 || foo.y >= 100000)
/* fail and exit */
p = (char *)malloc(foo.x * foo.y);
if (!p)
/* fail and exit */
for (i = 0; i < foo.x; i++)
fread(p + i*foo.y. 1, foo.y, fp);
and similar wonders (if anybody wonders what's wrong with the code above,
you need to learn how multiplication is defined on int and compare 10^10 with
2^32). And yes, it's real-life code, from often-used programs. Used on
untrusted data, at that.
Should we declare that arithmetics is dangerous?
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:16 EST