atof use question

I am using some sun computers (Solaris 8) and an ancient version of
g77 (2.95.2).  I've done some programming but I don't know alot about
how "things" work, so this is why I am asking this question.

I had an code that I was working with and I wanted to add some command
line inputs, so I used getarg, which returns things as a character
string.  Well, I was entering some floating-point numbers, so I just
used the function atof.  This works great, but now I am wondering why?

I poked thought the man(3F) pages but there is no reference to atof.
Of course there is one in the man(3C) pages, but how does g77 know
where to find it since I didn't include that header file?  Does g77
know that I am calling a C function and know to include it?  Or is
there some undocumented fortran or unix function that I am calling?

I see now that I should of used some form of internal read statement.

Anyway, just trying to learn more about it.

Thanks,
Brett Grant

Brett Grant wrote:

(snip)

>   Well, I was entering some floating-point numbers, so I just
> used the function atof.  This works great, but now I am wondering why?

> I poked thought the man(3F) pages but there is no reference to atof.
> Of course there is one in the man(3C) pages, but how does g77 know
> where to find it since I didn't include that header file?  Does g77
> know that I am calling a C function and know to include it?  Or is
> there some undocumented fortran or unix function that I am calling?

C header files don't tell the compiler or linker where to find
something, they just declare the argument and return types.
The linker still needs to find it.  Many Fortran systems will use
some of the C library, so C routines will be available for linking.
It may or may not agree with the argument and return types that
Fortran expects.   You may have been lucky.

-- glen

Brett Grant wrote:
>
> I am using some sun computers (Solaris 8) and an ancient version of
> g77 (2.95.2).  I've done some programming but I don't know alot about
> how "things" work, so this is why I am asking this question.
>
> I had an code that I was working with and I wanted to add some command
> line inputs, so I used getarg, which returns things as a character
> string.  Well, I was entering some floating-point numbers, so I just
> used the function atof.  This works great, but now I am wondering why?
>
> I poked thought the man(3F) pages but there is no reference to atof.
> Of course there is one in the man(3C) pages, but how does g77 know
> where to find it since I didn't include that header file?  Does g77
> know that I am calling a C function and know to include it?  Or is
> there some undocumented fortran or unix function that I am calling?
>
> I see now that I should of used some form of internal read statement.
>
> Anyway, just trying to learn more about it.
>
> Thanks,
> Brett Grant

atof() is likely to be a C function that, due to its simple interface,
can be called from FORTRAN directly. Other variations on this theme
exist: atoi(), atol(), atod().

Regards,

Arjen

Arjen Markus wrote:
| Brett Grant wrote:
||
|| I am using some sun computers (Solaris 8) and an ancient version of
|| g77 (2.95.2).  I've done some programming but I don't know alot about
|| how "things" work, so this is why I am asking this question.
||
|| I had an code that I was working with and I wanted to add some command
|| line inputs, so I used getarg, which returns things as a character
|| string.  Well, I was entering some floating-point numbers, so I just
|| used the function atof.  This works great, but now I am wondering why?
||
|| I poked thought the man(3F) pages but there is no reference to atof.
|| Of course there is one in the man(3C) pages, but how does g77 know
|| where to find it since I didn't include that header file?  Does g77
|| know that I am calling a C function and know to include it?  Or is
|| there some undocumented fortran or unix function that I am calling?
||
|| I see now that I should of used some form of internal read statement.
||
|| Anyway, just trying to learn more about it.
||
|| Thanks,
|| Brett Grant
|
| atof() is likely to be a C function that, due to its simple interface,
| can be called from FORTRAN directly. Other variations on this theme
| exist: atoi(), atol(), atod().

...but the fact that it requires the input string to be char(0)-terminated
makes me scary... at least, I would append it myself, and at best, I would
replace it with standard Fortran READ(), which also provides error handling.

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jugoslav Dujic wrote:
>
> Arjen Markus wrote:

> | atof() is likely to be a C function that, due to its simple interface,
> | can be called from FORTRAN directly. Other variations on this theme
> | exist: atoi(), atol(), atod().
>
> ...but the fact that it requires the input string to be char(0)-terminated
> makes me scary... at least, I would append it myself, and at best, I would
> replace it with standard Fortran READ(), which also provides error handlin
g.
>

It will most probably stop at the first character it can not regard as
part of
a legitimate decimal number ... So the chances of it failing by
accessing
bytes beyond what is good for it are minimal ;).

However, I empahtically agree: READ is definitely the Fortran way and
provides all the error checking you may want. (On the other hand, in
FORTRAN 77, internal READs did not allow list-directed input, so that
might
be a complication)

Regards,

Arjen

Arjen Markus <arjen.markus@wldelft.nl> writes:

> Jugoslav Dujic wrote:
 
>
> It will most probably stop at the first character it can not regard as
> part of  a legitimate decimal number ... So the chances of it failing by
> accessing  bytes beyond what is good for it are minimal ;).

"Minimal, huh?" Based on just a "most probably" guess unsupported by
documentation?  Sounds like the kind of assumption responsible for
a significant fraction of the security holes and other bugs in some
software.  :-(

I haven't bothered to look into this case in particular, but with most
compilers you can't just go calling c library functions from Fortran
without at least some kind of trickery.

For a start, name mangling usually keeps it from happening. That's
intentional. It is a real pain if there isn't such name mangling.
Been there.  :-( From the days before C/Unix, I used to have some
Fortran library functions named fs and fread.  This was also in the
days when I stuck to the F77 standard name length limit of 7 characters,
which limits you a lot if you want a name that is even vaguely
evocative of functionality.  (It was also in the days when I used
functions with side effects, but I have reformed).

When I ported to an HP compiler that didn't do name mangling (at least
not by default - maybe it had an option, but if so, I didn't know
about it at the time), the names fread and fs just wouldn't do.
There could only be one fread - either mine of the system one.  Guess
which one had to change.  Wouldn't have been so bad if it as just
in my program innards, but that was part of my documented interface
to the library.  Thus, not only did I have to diddle my code, but
every user of my library also had to correspondingly change their
callls.  Would have been a much bigger PITA if we ended up with a
lot of those systems, but fortunately there were only a small
handful of them here (2 that I recall, but might have been another
1 or 2 more).

Anyway, the fact that the atoi call worked at all makes me at least
vaguely suspicious that there *IS* a Fortran wrapper for it.  But
before I'd use such a thing, I'd want more than a vague suspicion
based on the fact that it appeared to work. Just like I'd want more
than a guess that it would stop before stomping all over memory.
If one want to write buggy and unreliable code, an excellent way
to do it is to make a habit of guessing about interfaces instead
of actually reading their documentation; this applies to far more
than just C libraries.

Of course, as pretty much everyone in the thread has noted, calling
this particular C function probably isn't the best way to go about
things anyway, but the general principles still apply and thus seem
worth commenting on.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

On Wed, 17 Nov 2004 08:33:41 -0800
Richard E Maine <nospam@see.signature> wrote:

> For a start, name mangling usually keeps it from happening. That's
> intentional. It is a real pain if there isn't such name mangling.
> Been there.  :-( From the days before C/Unix,

That is a truly scary statement. Some of us weren't even born when Unix
came out.

David

Richard E Maine wrote:

(snnip)

> "Minimal, huh?" Based on just a "most probably" guess unsupported by
> documentation?  Sounds like the kind of assumption responsible for
> a significant fraction of the security holes and other bugs in some
> software.  :-(

Well, ASCII digits are 10/256 of the possible 8 bit characters,
and the probability of accidentally getting one is probably
somewhat higher.

> I haven't bothered to look into this case in particular, but with most
> compilers you can't just go calling c library functions from Fortran
> without at least some kind of trickery.

I was pretty surprised to.  C tradition is that atof() returns a
double, and he didn't say that it was declared that way.  That
would reduce the chance of it accidentally working.

> For a start, name mangling usually keeps it from happening. That's
> intentional. It is a real pain if there isn't such name mangling.
> Been there.  :-( From the days before C/Unix, I used to have some
> Fortran library functions named fs and fread.  This was also in the
> days when I stuck to the F77 standard name length limit of 7 characters,
> which limits you a lot if you want a name that is even vaguely
> evocative of functionality.  (It was also in the days when I used
> functions with side effects, but I have reformed).

Well, C++ does name mangling.  Unix tended to put extra '_' on
names, but not much more.  I believe that the HP/UX Fortran library
uses the C library for I/O, so I am not surprised that you would be
stuck with C library names.  I at least once changed the name in a
system object file with a binary editor.  A little non-portable, though.

(snip)


-- glen

So if I understand correctly, when the program compiles, the linker
looks around for the symbol _atof and if it finds it, it substitutes
it all correctly, even though I haven't used a CALL statement or
included the proper header file.  (The proper header file isn't needed
because this isn't C - is that correct?)

This is just an added bonus for using the gcc compilers. :grin:  I
guess that I should read the section on calling c from fortran.

As a test, I tried compiling it using the Sun Suite and sure enough it
gave an error.  The read method works fine, though, so I will be using
that.

Thanks,
Brett

(original message deleted)

NoSpam@grantb.org (Brett Grant) writes:

> So if I understand correctly, when the program compiles, the linker
> looks around for the symbol _atof and if it finds it, it substitutes
> it all correctly, even though I haven't used a CALL statement or
> included the proper header file.  (The proper header file isn't needed
> because this isn't C - is that correct?)

Sort of.  CALL statements are for subroutines.  The equivalent for
functions is just the function reference.  This distinction has nothing
to do with the linker - it is just the difference between the syntax
used for subroutines and functions.

And header files aren't even necessarily needed for C.  They are often
needed to make the call actually work correctly, but seldom have much
to do with finding the function.  In most cases (exceptions exist),
there is nothing "magic" about C header files; they are literally
nothing but some extra C code to be included.  The linker has no
idea whether you used the C header file or not.

Using a C header file is unlikely to be helpful in Fortran, since the
header file has C code - not Fortran code.  However, you will
occasionally find things like C header files that have been translated
into Fortan equivalents.  This tends to be more "interesting" for
functions that are more complicated than atoi and involve special
derived types and other things.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain