Re: Fortran/C string interop?

Joe Krahn <lastname_at_niehs.nih.gov@xxxxx> wrote:

Brooks Moses wrote:
[describes f2003 C string interop]

Yes, but this still does not allow for using fixed-length strings,

Sure it does. See below.

only NUL terminated strings.

Please note that there is nothing at all about NUL termination in the
interop spec. You *MAY* - repeat may - nul terminate, but that's
entirely up to the writer of the relevant C and Fortran code. Nothing in
the normative text of the standard even mentions NUL here; it is used
only in an example.

I suppose it could be done manually by
passing a C_PTR which points to the first character of a fixed string,
plus a length argument.

Yes. That's why I said "sure it does" above. Or for that matter, if it
is a sring whose length you always know independently, you don't need to
pass any length information at all.

I don't see what problem it is that you are proposing to solve. Until
there is a problem, I don't think we should be solving it. Passing a
string length separately is a perfectly "normal" thing to do in C for a
string without NUL termination. And it is simple to do in Fortran. Seems
to me that adding an API element for this is making things more
complicated instead of simpler. You sure wouldn't be able to call any
existing C code, which won't have the API calls, that way.

The situation with arrays is different. The difference does *NOT* have
anything to do with any percieved difference in importance of string
versus numeric data. The difference is that there are things that cannot
be done with some array cases without extra help from the standard. Note
the "cannot" there. This is not just a matter of syntactic sugar to
avoid having to pass shape information separately. In particular, you
cannot pass a noncontiguous array to C without copying it. And there
aren't even facilities to inquire about things like stride that would be
needed to access such arrays in C.

Seems to me that you are looking for the standard to come up with
something that a user could just as well do. For the array case, the
user can't do it. There are some areas where I recommend standardization
of things that users can do because those things are so widely needed or
because there is benefit to all users doing them the same way. But I
don't see either of those justifications as applying here. There is zero
existing code base that uses the as yet non-existant proposed API. A lot
of new C interoperating code will use NUL termination, as tends to be
common in C. In those remaining cases where it is necessary to pass a
string length, passing it as an explicit (manual, if you prefer)
separate argument doesn't seem like a big deal, is intuitive, and is
consistent with existing practice - heck, that even allows some existing
"normal" C functions to be used without change. I'm left seeing no
problem to be solved by standardizing a new API for this.

--
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
.

Relevant Pages

  • Re: Null terminated strings: bad or good?
    ... The standard allows this for string literals, ... suppose you recompute the stored strlenevery time the array ... re-scanning arrays rather than doing actual work? ...
    (comp.lang.c)
  • Re: int array to string?
    ... Is there a standard library function I can use? ... >next integer from the array onto the growing string, ... >adequate memory set aside for this task). ...
    (comp.lang.c)
  • Re: bus errors accessing a char * by index?!
    ... The problem is that you're trying to modify a string literal. ... Any attempt to modify this array, ... You might want to look at the standard strtok() function. ...
    (comp.lang.c)
  • Re: an string array problem
    ... current standard, you may still use the "set" container. ... N items using an unsorted array). ... A hashset (stdext::hashset in recent VC ... whether the string is in the set). ...
    (microsoft.public.vc.language)
  • Re: [C] simple string question
    ... for "string" to be nul-terminated. ... nul-terminator" camp, we've been arguing at cross-purposes, and I ... containing a "variable length nul-terminated sequence of characters". ... expect nul termination", my assumption will have been proven wrong. ...
    (alt.comp.lang.learn.c-cpp)