kent@xanth.UUCP (Kent Paul Dolan) (01/01/70)
That's me!
v
>In article <2163@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>:[I just _know_ this is gonna get me flamed. Line eater, eat this posting!]
>:
>:Is it just me, or has anyone else noticed how C is being warped, made
>:ugly and complex, because ONE microprocessor manufacturer couldn't see
>:fit to provide a flat, linear address space? [rants on...]
>:I don't think it is a useful endeavor to labor at such length to embed
>:the hardware design mistakes of the past in the C standards of the
>:future.
Well, I just saw another example in another posting. Pretty soon, C
is going to pass PL/1 in the ugly sweepstakes.
One manufacturer, Symbolics, commented to the standards committee that
their machine couldn't cope with setjmp() as currently defined (guess
that means they don't make a general purpose computer?), so every C
user on every machine for the rest of time gets to deal with the added
cruft of treating setjmp() as "almost" a function, and the standard
sinks under the weight of more accreted garbage.
Come on, guys, working standards are lean, clean, and don't cater to
every brain damaged misengineering that passes by. The point of
standards is to provide a target of excellence for the hardware
designers, not a museum of abominations.
Kent, the (ever more irritable+@an22:cgeailyreadgwyn@brl-smoke.ARPA (Doug Gwyn ) (01/01/70)
In article <2471@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >I must be missing something here. As usual. What you missed this time is the distinction between "software developers" (which I referred to) and implementors of ANSI C. The latter will occasionally have to work hard in order to make life simpler for the former. But then, this point is probably too subtle for someone who advocates changing a widely- used language simply to conform to some idealized model in the course of standardizing it.
throopw@xyzzy.UUCP (Wayne A. Throop) (01/01/70)
> kent@xanth.UUCP (Kent Paul Dolan) >> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) >> [...] software developers cannot really afford to take into >>account the uncontrolled vagaries of all past, present, and future >>operating systems. > Huh? But the standards committee has been defending to the death its right > to take into account the uncontrolled vagaries of all past, present, and > future computing hardware. I must be missing something here. Indeed you are. You've changed the subject from developers to committee-members. The standards comittee has been taking these things into account so that software developers who follow the standard won't have to. -- "I could give you my word as a Spaniard," Inigo said. "No good," the man in black replied. "I've known too many Spaniards." --- From The Princess Bride by William Goldman -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
bts@sas.UUCP (Brian T. Schellenberger) (09/10/87)
In article <2196@xanth.UUCP>, kent@xanth.UUCP (Kent Paul Dolan) writes: > > Come on, guys, working standards are lean, clean, and don't cater to > every brain damaged misengineering that passes by. The point of > standards is to provide a target of excellence for the hardware > designers, not a museum of abominations. I emphatically disagree. The point of standards is to allow people to get useful work done -- useful applications that need to work in lots of different environments. If you don't care about portability, you don't care about standards. If you *do* care about portability, you care about making the standards work on the widest possible variaty of machines that it can work on without doing true violence to the language. The only thing the setjmp() rule seems to break is that you can no longer assign setjmp to a function pointer and then call setjmp through the pointer. I would be quite surprised to find that this is an exceedingly common thing to do. One thing standards are *NOT* supposed to be is an unattainable standard that real-world manufacturers are hard-pressed to meet. If you think that's what standards are all about, look at Ada. That is the result of such an "Aim High" philosophy in standards-writing. Sure, some whiz-bang gizmos will work better in your native environment. And I'll bet that some other things work better in the environment that has trouble with setjmp/longjmp. Yet the standard disallows both bells, so the same code works on both machines. And that's precisely why a standard is useful. -- --Brian. (Brian T. Schellenberger) ...!mcnc!rti!sas!bts DISCLAIMER: Whereas Brian Schellenberger (hereinafter "the party of the first
guardian@laidbak.UUCP (Harry Skelton) (09/11/87)
In article <181@sas.UUCP> bts@sas.UUCP (Brian T. Schellenberger) writes: > >I emphatically disagree. The point of standards is to allow people to get >useful work done -- useful applications that need to work in lots of >different environments. If you don't care about portability, you don't care >about standards. If you *do* care about portability, you care about making >the standards work on the widest possible variaty of machines that it can >work on without doing true violence to the language. > >Sure, some whiz-bang gizmos will work better in your native environment. And >I'll bet that some other things work better in the environment that has >trouble with setjmp/longjmp. Yet the standard disallows both bells, so the >same code works on both machines. And that's precisely why a standard is >useful. >-- > --Brian. >(Brian T. Schellenberger) ...!mcnc!rti!sas!bts > It's hard to think that some people use the word 'standards' to address what can only work in the environment that they have access to. I agree with Brian in that if you work at setting up a program to work in a 'standard' that it should be created to work under as many environments as possible. This would address both the newest version of Unix to the old ( by someone's standard - brain damaged ) versions of Unix. I think that in the realm of public domain, such as Usenet, that programs or information that is to be considered 'standard' should apply to items that can address as many machines and/or versions of an OS as possible. I don't think the term 'standard' should be used to set guidelines in which to program by but rather to term the portability of a program or function or to discribe the actions of a program. Setting a standard for programming will only limit things and cause great outcry (such as been seen on this net). If you want to set a standard, how about just saying what will work under certain conditions and under different versions of an OS. Some of us don't have the money to purchase new versions of an OS every time it is released. I feel well enough knowing that what I make is upward compatable untill a major OS change makes it necessary for me to upgrade. #include <disclaimer.h> .---------. Harry Skelton : .-. : --- other mail drops --- guardian@laidbak.UUCP : `-'o : ihnp4!laidbak!ugh!bear ihnp4!laidbak!guardian : O : ihnp4!chinet!guardian `---------' As in the words of Socretes: "I drank wha*.........."
gwyn@brl-smoke.UUCP (09/12/87)
In article <1141@laidbak.UUCP> guardian@laidbak.UUCP writes: >If you want to set a standard, how about just saying what will work under >certain conditions and under different versions of an OS. That information might be useful for some purposes, but it cannot replace true standards. The essential problem requiring standards is that software developers cannot really afford to take into account the uncontrolled vagaries of all past, present, and future operating systems. Even just keeping abreast of them is beyond most organizations' budgets. The practical advantage of standards is that applications can be developed to use a known set of facilities with known properties, and they will then work across a wide variety of systems with negligible porting effort. If the standard environment is sufficiently rich, such applications can even be useful (unlike many that assume only the lowest common denominator environment). Of course, for this to work, there must be agreement on what the standards ARE, and they must be readily implementable across all those systems.
kent@xanth.UUCP (Kent Paul Dolan) (09/17/87)
In article <6422@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1141@laidbak.UUCP> guardian@laidbak.UUCP writes: >>If you want to set a standard, how about just saying what will work under >>certain conditions and under different versions of an OS. > >That information might be useful for some purposes, but it cannot >replace true standards. The essential problem requiring standards >is that software developers cannot really afford to take into >account the uncontrolled vagaries of all past, present, and future >operating systems. Huh? But the standards committee has been defending to the death its right to take into account the uncontrolled vagaries of all past, present, and future computing hardware. I must be missing something here. Kent, the man from xanth. "His expression lit up. 'Hey, you wouldn't be a dope smuggler, would you?' Rail looked confused. 'Why would anyone wish to smuggle stupidity when there is so much of it readily available?'" -- Alan Dean Foster, GLORY LANE
kent@xanth.UUCP (Kent Paul Dolan) (09/23/87)
In article <6447@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2471@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >>I must be missing something here. > >As usual. What you missed this time is the distinction between >"software developers" (which I referred to) and implementors of >ANSI C. The latter will occasionally have to work hard in order >to make life simpler for the former. But then, this point is >probably too subtle for someone who advocates changing a widely- >used language simply to conform to some idealized model in the >course of standardizing it. Mr. Gwyn, If you are unable to keep a civil tongue in your head, I suggest in the strongest terms that you have yourself replaced as a spokesperson in this forum for ANSI and X3J11. Your continued, intemperate and ad hominem attacks on me and other net correspondents, to the neglect of answering the valid technical issues raised here, are a disgrace. You continue to espouse embedding hardware misfeatures into the C language standard. Granted, the implementors of the resulting C compilers will be forced to take these abominations into account, but SO WILL EVERY C PROGRAMMER FOR GENERATIONS TO COME (those system developers you distinguish against). Kent, the (out of patience) man from xanth.
guy%gorodish@Sun.COM (Guy Harris) (09/23/87)
> You continue to espouse embedding hardware misfeatures into the C > language standard. Excuse me? How is he espousing this? He merely wishes to allow for the possibility that C might be implemented on machines that do not have a simple flat address space. If you wish to write programs that only work on machines with a flat address space, *nobody* is stopping you from doing so. You may, however, find yourself able to use this software more widely if you don't do so. The choice is yours. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guardian@laidbak.UUCP (09/24/87)
Should not 'C' Standards cover what will currently work with 'C' rather than
trying to re-write 'C' ? Maybe we should open up a Subject of "Setting 'C'
Standards" to cover what should be included in new versions of the 'C'
compiler.
update:
The document/book I am working on covers what is defined in various
'C' environments as well as what 'kludges' are needed to work on other
'brain damaged' 'C' systems. I have the manuals for Sun, AT&T,
IBM (AT/PC Class), Sequent, and various micro 'C' manuals. If anyone
would like to donate information on problems or hidden features of certain
compilers, please e-mail the information to: ihnp4!laidbak!guardian.
Manuals will also be accepted. All information recieved will be noted as
comming from the originator.
(yeah, it's gonna' take a while...)
.---------.
Harry Skelton : .-. : --- other mail drops ---
guardian@laidbak.UUCP : `-'o : ihnp4!laidbak!ugh!bear
ihnp4!laidbak!guardian : O : ihnp4!chinet!guardian
`---------'
"I thought about it, then I figured out that it was not worth thinking about."gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/25/87)
In article <2514@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >If you are unable to keep a civil tongue in your head, I suggest in >the strongest terms that you have yourself replaced as a spokesperson >in this forum for ANSI and X3J11. I don't know where "the man from Xanth" got the idea that I'm a spokesperson for ANSI and X3J11 -- I've included disclaimers many times. I think this is indicative of the level of care he takes when reading these articles. Dolan, despite admitting that he is only slightly acquainted with C and doesn't regularly use it, seems to feel qualified to declare what the language "should" be like, discounting the reality of the conflicting requirements that X3J11 has to take into account when designing a standard for a living language. He didn't bother to send suggestions to X3J11, where they might have done some good, but simply complains in this newsgroup that X3J11 isn't catering to his tunnel vision. This is the academic at his worst. I received the most amazing mail from this fellow, full of condescension and (when I failed to be impressed by his "credentials") quite insulting -- so much so that he has the honor of being the second person whose mail I automatically delete upon reception. This posting, unlike most of mine, has no appreciable technical content -- because the flame to which I'm responding had none.
throopw@xyzzy.UUCP (Wayne A. Throop) (09/28/87)
> kent@xanth.UUCP (Kent Paul Dolan) > You continue to espouse embedding hardware misfeatures into the C > language standard. Quite the reverse. He espouses NOT embedding non-universal hardware "features" into the C language standard, a different thing altogether. > Granted, the implementors of the resulting C > compilers will be forced to take these abominations into account, but > SO WILL EVERY C PROGRAMMER FOR GENERATIONS TO COME (those system > developers you distinguish against). No, they do *not* have to take the hardware misfeatures you disapprove of into account. They only have to take the standard into account. That is, developers don't have to know about segments, or word-granular pointers, or tagged pointers, or ringed architectures, or any such transient things of the mundane, hardware world. All they have to know is what the standard says are the properties of addresses. If they adhere to the standard, they don't have to care what hardware they are running on. Which is as it should be. (Granted, the standard *does* make certain assumptions, such as that the compiled program is to run on a binary digital computer. But some level of assumption is unavoidable. The point is that the standards committee has, indeed, chosen a good level.) -- Inigo hated it there. Everybody was so dangerous, big, mean and muscular, and so what if he was the greatest fencer in the world, who'd know it to look at him? He looked like a skinny Spanish guy it might be fun to rob. You couldn't walk around with a sign saying "Be careful, this is the greatest fencer since the death of the Wizard of Corsica. Do not burgle." --- From The Princess Bride by William Goldman -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw