Re: use of erf intrinsic
From: Dave Thompson (david.thompson1_at_worldnet.att.net)
Date: 04/26/04
- Next message: Dave Thompson: "Re: Need help in tracking down an error"
- Previous message: Gary L. Scott: "Re: Fortran decimal anyone?"
- In reply to: glen herrmannsfeldt: "Re: use of erf intrinsic"
- Next in thread: Richard Maine: "Re: use of erf intrinsic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 26 Apr 2004 03:07:14 GMT
On Fri, 16 Apr 2004 21:10:57 GMT, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> beliavsky@aol.com wrote:
>
> > Richard Maine <nospam@see.signature> wrote in message news:<m1fzb5ji5r.fsf@macfortran.local>...
>
> >>Diagnosis of [mismatched calls] for external procedures is very
> >>spotty and depends on many things. Some compilers will do it
> >>if the call is in the same file as the subroutine; compilers that
> >>can diagnose argument mismatches across separate files are rare.
<snip>
> The Fortran tradition was for the compiler to keep no state
> between different routines even in the same file. That caused
> funny errors from comments after the END statement of the last
> routine.
>
> C, which allows declaring (global) variables outside of any
> function can't do that. I don't believe there is any requirement
> to diagnose it, though.
>
C also allows declaring at "file" (global) scope functions that are
not "defined" (in the C meaning of that term = given a body, *not* set
to a value); while it is also legal to declare a referenced function
within the calling function(s) or even block(s), a la classic FORTRAN,
that is generally more work, less safe (see next), and (thus)
considered a poor idea. Any function definition is automatically also
a declaration of that function for the remainder of the translation
unit = source file after preprocessing.
The implementation (compiler) is required to check that references
later in the same t.u. to a globally declared variable are consistent
with its type. It is not required to check that references to the
same global in different t.u.s used the same (or compatible)
declarations, and generally doesn't. If the declaration is obtained
from an #include'd header file, as is considered good practice in most
cases, it will always be the same unless:
- the (correct) header file was changed after compiling some t.u.s and
before compiling others; and this was not caught by 'make' or a
similar dependency tracker/enforcer
- the #include'd text depends, explicitly or not, on preprocessor
macros #define'd to one value in one t.u. (before #include'ing it) and
a different value in another -- or, less likely, is #define'd in one
and not at all in another and works either way but differently
- compilation of one t.u. finds one header file but compilation of
another t.u. using the same #include statement finds a different file,
usually because of compilation parameters like -I or filesystem setup
It is also legal to declare 'extern' variables within a function or
even block that uses them, rather like FORTRAN COMMON, but in this
case the compiler need enforce them only within that scope; it need
not check consistency between declarations in different functions even
in the same t.u. Also, there is no way within a function to obtain
the same effect as a file-scope 'static' declaration; and as above
most "global" declarations should be obtained from header files, which
normally are #include'd at the top of the t.u. (thus) at file scope.
When you declare and/or define a function in C you can use either the
old/traditional/K&R1 syntax or the new/standard/prototype syntax --
where "new" means somewhat before 1989, and thus like "new" F90
features people should have adjusted by now.
If you use K&R1 syntax, the compiler is not required to detect
argument mismatches in calls; if you define the function in K&R1
syntax it actually has enough information to do so, but usually
doesn't; if you only declare the function -- which in K&R1 syntax
doesn't specify the parameters=formals -- it cannot except by heroic
efforts and doesn't. The compiler does check, and convert if needed,
the *return* type, which is declared even in K&R1 syntax. Although
before C99 you aren't required to declare at all a function called in
the normal way (not through a pointer) and the compiler assumes it
returns int, kind of but not exactly like the classic FORTRAN IMPLICIT
behavior, and if this assumption is wrong you're in trouble.
If you use prototype syntax, the compiler is required to check that
(actual) arguments match "closely enough" -- either exact or can be
implicitly converted -- to the *declared* types of (formal) parameters
in the prototype, and diagnose if not. (Plus the return type is still
handled as above.) Again there is no requirement to check that
declarations used in different t.u.s are the same, and C
implementations generally don't (I know of one unusual one that does);
OTOH C++ implementations aren't strictly required to, but they do have
to support overloading, and generally do so by mangling the linker
names in a fashion that detects many but not all type mismatches.
Again usually the declaration is actually obtained from an #include
file with the considerations above; and if you also #include that
header into the defining t.u., which is also considered good practice,
the compiler must diagnose any mismatch between the (#include'd)
*prototyped* declaration and the *prototyped* definition.
> I would find it very strange for a compiler to detect errors due
> to either source or object files that it wasn't asked to read.
>
Depends on what "asked" means. Java and Perl automatically search
for the (semi)object or source respectively of modules you reference
by name. Ada requires that modules referenced by name be fully
checked; some Ada implementations do this by keeping a repository of
parsed modules (like .mod files in most? F9x's) but GNAT, the GNU/GCC
one, found that it was faster to each time go find* the source and
(re)parse it, and so can get errors from that source. (* Found using
by default a simple mapping of must-be-exactly-one module = package or
subprogram name to file name, overridable by the user.)
- David.Thompson1 at worldnet.att.net
- Next message: Dave Thompson: "Re: Need help in tracking down an error"
- Previous message: Gary L. Scott: "Re: Fortran decimal anyone?"
- In reply to: glen herrmannsfeldt: "Re: use of erf intrinsic"
- Next in thread: Richard Maine: "Re: use of erf intrinsic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
