Re: problems with identifiers and keywords...

nmm1@cus.cam.ac.uk (Nick Maclaren)
1 Dec 2004 23:00:07 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: problems with identifiers and keywords... gracjan@acchsh.nospam.com (Gracjan Polak) (2004-11-19)
Re: problems with identifiers and keywords... Martin.Ward@durham.ac.uk (Martin Ward) (2004-11-19)
Re: problems with identifiers and keywords... Peter_Flass@Yahoo.com (Peter Flass) (2004-11-20)
Re: problems with identifiers and keywords... genew@mail.ocis.net (Gene Wirchenko) (2004-11-20)
Re: problems with identifiers and keywords... david.thompson1@worldnet.att.net (Dave Thompson) (2004-11-28)
Re: problems with identifiers and keywords... cgweav@aol.com (2004-11-29)
Re: problems with identifiers and keywords... nmm1@cus.cam.ac.uk (2004-12-01)
Re: problems with identifiers and keywords... cdc@maxnet.co.nz (Carl Cerecke) (2004-12-01)
Re: problems with identifiers and keywords... gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-12-05)
Re: problems with identifiers and keywords... vbdis@aol.com (2004-12-05)
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 1 Dec 2004 23:00:07 -0500
Organization: University of Cambridge, England
References: 04-10-148 04-11-031 04-11-052 04-11-105
Keywords: syntax, design
Posted-Date: 01 Dec 2004 23:00:07 EST

Dave Thompson <david.thompson1@worldnet.att.net> wrote:
>Library function names are reserved within translation units (roughly
>source files) if and only if the applicable standard header is
>#include'd. E.g. fopen is reserved iff you #include <stdio.h>.


Yes. And there are differently bizarre rules for other classes of
object, too, but let's skip them.


>All library function names are reserved _as external names_, meaning
>at the linker level as always implemented although the standards can't
>formally say so. This is pretty much inherent in traditional and still
>pretty much(?) universal one-level linkers.


Yes (as far as what C requires). But, no, it is NOT for that reason.
It is because the Unix community (NOT the authors of Unix, but their
followers, including Berkeley) had a religious objection to admitting
that computing technology was well advanced before that era of
computer science. That may not be polite, but is unfortunately true.


Fortran has no such constraint, and can be linked with a much simpler
linker than C can - in fact, a strict subset.


The first point to note is that, if you include the header, the symbol
exp may be a preprocessor symbol for __erf, so that even calling it
NOT via the macro gets __erf.


The second is that the permission to declare and use it without
calling the header needs only for program-declared external functions
to be searched before library ones.


This has the effect of meaning that such an explicit declaration will
call a program-declared rather than a library one, but that merely
provides a reasonable definition of currently undefined state.


This has all been standard practice since Fortran 66 - the really old
lags may be able to confirm whether or not is was before that. Yes, I
know that some Fortran 66 compilers didn't support program- defined
functions of the same name as library ones, but that was more for good
debugging than because the linkers couldn't handle it. Of course,
SOME linkers couldn't, but most could.




Regards,
Nick Maclaren.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.