>>> 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...
There's just that little overflow problem to worry about,
trailing garbage, encouragement of assumptions about the
maximum size... is that a %d or a %llu or what?
Given n fields and an constant c>5, there will be at least
exp(c,n) ways to parse and generate the data. All will be
implemented. In addition to disagreement over the format,
most parsers will be buggy.
You just like ASCII because that's the Plan 9 way.
There's a time and place for ASCII, and this isn't it.
> 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
type safety, given a C struct with proper alignment
> Should we declare that arithmetics is dangerous?
We should use FORTRAN or Pascal, with overflow/underflow
trapping enabled for integer math and array access. :-)
-
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/