Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: PROPOSAL: dot-proc interface [was: /proc stuff] | Date | Sun, 4 Nov 2001 16:41:13 -0500 (EST) |
| |
Alexander Viro writes:
> Folks, could we please deep-six the "ASCII is tough" mentality?
Sure. How about: It's a PITA to break out the dragon book, bloat sucks, and I'd just rather not have to write the code.
I also like: Trusting every little status app to not have exploitable buffer overruns is worrisome.
The more serious problem: ASCII formats change in unpredictable ways. (see below)
> Idea of > native-endian data is so broken that it's not even funny. Exercise: > try to export such thing over the network.
Ooh! You're making /proc NFS exportable?
> Another one: try to use > that in a shell script. One more: try to do it portably in Perl script.
FOO=`ps -o foo= -p $$` # Get our FOO value out of binary /proc
> 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.
Disks are slow, so native endian UFS was indeed a poor choice.
> We have the same idiocy to > thank for a lot of ugliness in X.
This was a necessary performance hack. Hopefully nobody wrote an X server or client that would do conditional byte swaps all over the code.
> 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.
SigCgt in /proc/self/status wasn't always spelled that way. It wasn't always in the same location either. ASCII bites because people can't resist screwing with it.
- 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/
| |