Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!amdahl!ames!hao!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: modemcap(5) and dial(3) Message-ID: <9156@mimsy.UUCP> Date: Thu, 29-Oct-87 14:11:53 EST Article-I.D.: mimsy.9156 Posted: Thu Oct 29 14:11:53 1987 Date-Received: Wed, 4-Nov-87 02:49:25 EST References: <1548@bloom-beacon.MIT.EDU> <142700004@tiger.UUCP> <292@minya.UUCP> <1933@killer.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 75 >In article <9128@mimsy.UUCP> I pleaded: >>If someone *does* work on a modem capability database for 4.3BSD, >>please *stop* using the awful two-letter-keyword format imposed by >>termcap. The buffer size limits in the termcap-reading code are >>also problematical. In article <1933@killer.UUCP> jfh@killer.UUCP (The Beach Bum) answers: >I hadn't considered the two letter codes to be a problem with termcap. >How often do you write termcap files? Too often. The abbreviations in terminfo are not all that much better, but (if not for the internal design of terminfo) the *set* of abbreviations could be extended with much less fear of collision. For instance, termcap does not have a way to start and end boldface or blinking modes, both of which are fairly common enhancement modes, much like inverse video (black-on-white characters) and underline. Underlining is started by `us' and ended by `ue'; inverse video is started by `so' and ended by `se'. By rights blinking should be `bs' and `be' or `bl' and be'; boldface should be `bs' and `be' or `bo' and `be'. `bs' is already in use for backspace, and clearly `be' cannot be used for both; I wound up using `bo' and `be' for bold, and `ws' and `we' for blink (`w' for `wink'). >Yes, my code uses two letter keywords. I didn't think going to terminfo >like descriptions was worth it. As for the buffer size limits, I don't >think that will be a problem with modems. (No one ever thinks buffer size limits will be a problem. They always are.) As another example, consider the flexnames (long variable names) code in 4BSD. The 4BSD compilers allow `infinitely long' variable names. In fact, these names are limited to 1023 characters. I claim that because this is a fixed limit, it is automatically too small. Do you agree? (Probably not.) The Berkeley Pascal compiler constructs unique global names for every function by stringing together the names of each outer function, joining them with underscores, so that in program foo; procedure globalproc; procedure localtoglobal; procedure localtolocal; function llfunc(a : integer) : integer; procedure lllproc; procedure llllproc; generates the name globalproc_localtoglobal_localtolocal_llfunc_lllproc_llllproc which is already 61 characters long. We have a group that has written a very large Pascal program in which the internally generated identifiers have been 140 characters long. This is already more than 1/10th of the way to reaching flexnames's idea of infinity. C++ constructs unique names by a set of rules known only to Bjarne Stroustrup. These, too, are often quite long. What will happen when someone writes an automatic programming system and uses it for a project as large as the one that generated to 140 character identifiers? I suspect that in a few years, *someone* will run into that 1023 character limit. Am I going to fix the 1023 character limit? No, or at least, not now. Would I write programs with such a limit? Probably. Is it `right'? No. There are tradeoffs everywhere; some of them involve programming time versus fixed limits. These will probably be resolved in favour of programming time. So it goes. Just remember that Limits Are Wrong, even when they are necessary. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris