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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public From: watzka@stat.uni-muenchen.de (Kurt Watzka) Subject: Re: Which language pays most 17457 -- C++ vs. Java? Date: 1997/12/20 Message-ID: <67hg7m$g9f$1@sparcserver.lrz-muenchen.de> X-Deja-AN: 308939118 Distribution: world References: <199712121931.LAA25389@sirius.infonex.com> <67bjnv$j35$1@brie.direct.ca> <349B0417.D4DB6A30@its.cl> <67gvpa$m3t$1@brie.direct.ca> Organization: Institut fuer Statistik der LMU Muenchen (Germany) Reply-To: watzka@stat.uni-muenchen.de 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: "William J. Leary Jr." writes: > Kaz Kylheku wrote in message <67gvpa$m3t$1@brie.direct.ca>... >>The library is part of the language, you buffoon, the same way that basic >>words like 'air' and 'water' are part of English. >Not that I've ever noticed. I frequently use C compilers to target embedded >systems. We pretty much always discard the standard library and bring up >our own basic library for the features we actually need. The standard >library pretty much is always hooked into the OS (or OS's) the compiler is >targeting. Since we're usually either on the iron, or on an RTOS the >standard stuff the standard library want's isn't usuall there. What Kaz Kylheku is missing is the word "hosted environement". He knows quite well that in a hosted environment, all the functions, macros, type definitions, and objects described in the library clause may be used, whereas in a freestanding environment (for example, an implementation targeting your average toaster), and libary facilities available to a program are implementation-defined. >>In C, the standard library functions have special status. >> First of all, their names are reserved external symbols. >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. This is what Kaz was trying to tell you. "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. > 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. > 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. 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. >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. >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. >>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? >> 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. 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. 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". Try to find some text in the language definition that supports your point of view. Kurt -- | Kurt Watzka Phone : +49-89-2178-2781 | watzka@stat.uni-muenchen.de