From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10a146,a03ae7f4e53958e1 X-Google-Attributes: gid10a146,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public From: "William J. Leary Jr." Subject: Re: Which language pays most 17457 -- C++ vs. Java? Date: 1997/12/20 Message-ID: <#vJ8k2aD9GA.169@upnetnews03> X-Deja-AN: 308973252 References: <199712121931.LAA25389@sirius.infonex.com> <67bjnv$j35$1@brie.direct.ca> <349B0417.D4DB6A30@its.cl> <67gvpa$m3t$1@brie.direct.ca> <67hg7m$g9f$1@sparcserver.lrz-muenchen.de> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: Paralyn Associates Newsgroups: comp.lang.fortran,comp.lang.c,comp.lang.c++,comp.lang.eiffel,comp.lang.java.programmer,comp.lang.smalltalk,comp.lang.perl.misc,comp.lang.ada,comp.edu Date: 1997-12-20T00:00:00+00:00 List-Id: >Kurt Watzka wrote in message <67hg7m$g9f$1@sparcserver.lrz-muenchen.de>... >>"William J. Leary Jr." writes: >>> Kaz Kylheku wrote in message <67gvpa$m3t$1@brie.direct.ca>... --- ((..omitted..)) >What Kaz Kylheku is missing is the word "hosted environement". Yes, very good. THAT makes a lot of sense, and I've seen that myself. Still, that's the environment, not the langauge specification for C. --- ((..omitted..)) >>Not usually. Their "special status" comes from the fact that they get put >>into the symbol table because you always include "stdio.h" or "stdlib.h" or >>whatever. > > Not so. The names are reserved in a hosted environment no matter what > headers are included. Again, I agree. The environment might well require that. The language spec. doesn't. > This is what Kaz was trying to tell you. Not me. he was writing to someone else. > "All identifiers with external linkage in any of the following (i.e > the library) subclauses including the future library directions > are always reserved for use as identifiers with external linkage" > cannot be interpreted in a way that restricts the reservation to > compilation units that include certain standard headers. Yep, no disagreement. But we seem to be getting rather far afield of the argument I was commenting on, which *appeared* to be that the C language _itself_ included the standard library. >> In some cases a compiler will pay special attention to some of >>the routines (like strcpy) so it can inline them >>automagically. > >I doubt that it is allowed to do so in a freestanding environenment >without explicitly stating that fact in its documentation. Yes. The one I used (Metaware) and reviewed (Orin? Ordin? I'm not sure... years ago) both had notes in their compiler switches section about these features. Metaware also included it in the debugging section, since it was impossible to set a breakpoint on, say, strcpy if it was inlined. >> In all cases where I've seen this there's been a compiler >> switch to turn it off. > >Again, the point is the difference between a freestanding environement >and a hosted environment. I absolutely agree with you. However, the thread of conversation I reviewed didn't seem to be talking about operation under an environment. It seemed to be a discussion about the basic C language and it's supposed inclusion of the standard library as part of that language. > In a freestanding environment, the name and type of the function called at program > startup are implementation defined. It may well be "void ToasterStart(float > TimerSetting)". There are otherwise no reserved external identifiers in a freestanding > environment. This means that you are indeed free to use names in your toaster control > program that would be reserved identifiers in a program targeting a hosted > environment. Agreed again. >> I've dumped the standard library lots of times and written new routines for >> some of the standard features and never had a compiler or linker complain >> about them. > >>> If any C program contains an external definition of an identifier that is >>> an external name reserved by the standard library, the behavior is undefined. > > This means that neither the compiler nor the linker is obliged in any > way to complain about the redefinition of functions from the standard > library, but the behaviour of such a program is still undefined. "It > worked so far" is a _very_ weak proof of correctness, given that > undefined behaviour may well be limited to Thursdays before Friday > the 13th in odd years. No disagreement here either. >> If you link in the standard library, you usually get a linker error, unless >> the linker isn't too bright. If you don't link in the library, it usually >> just works as expected. That is, your routine which replaced, say, fputc, >> just gets linked in. > >This need not be true in a hosted environment. The compiler may well >inline calls to fputc(), or generate calls to __libc_term_FPUTC instead. It might well inline the function, but inlining is a performance issue. It's not supposed to break the integrity of the program in doing so. On the other hand, I don't disagree with you or him here. If the compiler writer has chosen to make such things primative AND doesn't pass on the symbols for the inlined to the linker, so they can be caught if re-used incorrectly, then of course it's undefined. >>> Secondly, if you include a standard header, you may not redeclare any >>> symbol in that standard header, not even in a nested scope. > >>Done it several times. Program started in DOS, so I needed the standard >>libs for progress messages. Switched to protected mode in high memory and >>zapped DOS in low RAM for buffers. Used my own fputc and so forth after >>that. > >You wouldn't mind telling us which companies use or sell your products, >would you? The Bytex Series 7700 Token Ring / Ethernet Programmable Hub. Long before the product got to market we'd eliminated the DOS stage and booted directly into protected mode from a modified BIOS, but the initial system did indeed work this way. The other I'm not at liberty to discuss due to non-disclosure agreements. >>> I'm not talking about optimization. I'm talking about recognition of standard >>> functions as thought they where primitives. The C standard permits an >>> implementation to do that. > >> Yep, some compilers will do that. Metaware, for example, will catch memcpy >> and optimize it for the 80x86 REPT modifier. It can be turned off with a >> compile time switch, because it's NOT part of the C langauge but rather is >> the compiler maker noticing a chance to get you better executing code by >> implementing one of the standard library functions as if it were a language >> primitave. > > The possibility that the definition of the C programming language indeed > does permit what Kaz claims it to permit does obviously escape you. Not at all. I've read the ANSI C spec and it clearly leave a lot of leeway about how things are implemented. I agreed. > An implementation of the C programming language is free to recognize calls > to functions from the standard C library as special cases and treat them in a > special way. Yep. I agreed with that. No argument at all. In fact, I provided an example of an compiler I'd used which did just that. > If you think that this is not so, don't try to prove your point with statements like "I tried > it once and it looked as if it worked on the implementation I was using at that time". I didn't. I pointed out how one specific implementation (Metaware) had both done the optimization route AND complied with the language spec by providing a switch to turn off the inlines. > Try to find some text in the language definition that supports your point of view. Supports it how? My point of view is that the C _language_ does not include the C _standard_library_ functions as part of the _language_. A particular C programming environment may well do something other than this, and that's their option. I don't see what it is I'm supposed to use to support my point of view, unless you'd like me to quote the entire language and end up saying "no standard library primitives found herein." For that matter, whether you'd like me to do that or not, perhaps you can point me to a place on the net where the ANSI C spec is available. I've just done a search and I've found the ANSI C++ spec, but can't find the ANSI C spec. The one I had belonged to my former employer and I had to leave it there when I left the company. - Bill