C Interoperability - Strings

I haven't checked, sorry. Does C interoperability provide assistance
for string interoperability? It would be nice if I didn't keep having
to write a "delete nulls" function to remove those annoying null
characters from C-returned strings (e.g. API error message text). It
isn't very difficult, but I'd prefer a nice "slick" method.

On Sat, 30 Aug 2008 11:30:41 -0700 (PDT), GaryScott posted:

> I haven't checked, sorry. Does C interoperability provide assistance
> for string interoperability? It would be nice if I didn't keep having
> to write a "delete nulls" function to remove those annoying null
> characters from C-returned strings (e.g. API error message text). It
> isn't very difficult, but I'd prefer a nice "slick" method.

Gary,

Are you aware of c_null_char? The code listing for 14.3 MR&C might be what
you're looking for.
--
We must be willing to pay a price for freedom. 4
H. L. Mencken

Ron Ford wrote:

> On Sat, 30 Aug 2008 11:30:41 -0700 (PDT), GaryScott posted:
>
>
>>I haven't checked, sorry. Does C interoperability provide assistance
>>for string interoperability? It would be nice if I didn't keep having
>>to write a "delete nulls" function to remove those annoying null
>>characters from C-returned strings (e.g. API error message text). It
>>isn't very difficult, but I'd prefer a nice "slick" method.
>
>
> Gary,
>
> Are you aware of c_null_char? The code listing for 14.3 MR&C might be what
> you're looking for.

"The entity C_NULL_CHAR shall be a named constant of type character with
a length parameter of
one and a kind parameter equal to the value of C_CHAR, unless the value
of C_CHAR is -1, in
which case the kind parameter of C_NULL_CHAR is the default character
kind. If C_CHAR has a
non-negative value, the value of C_NULL_CHAR shall be the same as the
null value of the C
character type; otherwise, the value of C_NULL_CHAR shall be the first
character in the collating
sequence for characters of default kind. "

I don't think so. I'm looking for a C2FString()/F2CString() function or
for it to be handled automatically in the argument passing mechanism.
I've long had my own conversion routine, but in my adapting of 6k lines
of C recently, I found the C API rather than just terminating the used
part of a string buffer, was actually null filling the buffer to the end
(why the heck would it do that??). No biggie, I fixed my routine, but I
wonder what else I could possibly run into one day.


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

ianbush.throwaway.account@googlemail.com wrote:

> On Aug 30, 7:30 pm, GaryScott <garylsc...@sbcglobal.net> wrote:
>
>>I haven't checked, sorry. Does C interoperability provide assistance
>>for string interoperability? It would be nice if I didn't keep having
>>to write a "delete nulls" function to remove those annoying null
>>characters from C-returned strings (e.g. API error message text). It
>>isn't very difficult, but I'd prefer a nice "slick" method.
>
>
> No, there isn't an intrinsic way in the language to do this
> conversion.
> Also you are aware that to be interoperable Fortran Character
> variables
> must have Len = 1 ?

No, I only use F95 compilers at present (CVF, LF95, Absoft F90) that
interoperate with normal character buffers of whatever length as long as
you insert a null character at the end of the trimmed length. Are you
saying that I must use an array to designate a string? Boy that would
be inconvenient.

>
> Ian


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott <garylscott@sbcglobal.net> wrote:

> ianbush.throwaway.account@googlemail.com wrote:

> > Also you are aware that to be interoperable Fortran Character
> > variables must have Len = 1 ?
>
> No, I only use F95 compilers at present (CVF, LF95, Absoft F90) that
> interoperate with normal character buffers of whatever length as long as
> you insert a null character at the end of the trimmed length. Are you
> saying that I must use an array to designate a string? Boy that would
> be inconvenient.

No, that is *NOT* the implication, although Ian might well mistakenly
think so. That seems to be developing as a FAQ for the C interop stuff.
The developers of the standard aren't quite so dense as to not have
figured out how inconvenient that would be. That exact issue got very
specific attention during development. There is even a special-case rule
to facilitate it. (It turned out not to take too much of a special case,
but it did require one somewhat strange historical rule to be extended
from default character to also apply to character(kind=c-kind), even
though it doesn't apply to all character kinds).

See Note 15.23 in F2003, which gives an example of exactly this and
attempts to explain why it works.

The (very) short version is that an actual argument to a bind(c)
procedure does not have to be interoperable. Only the dummy arguments
have to be interoperable. The normal rules for argument agreement
(including the one historical special case) then apply to what the
actual arguments may be.

This is the same reason that, for example, you can pass an allocated
allocatable array or associated pointer array as an actual argument,
even though those things aren't interoperable. Those are valid actual
arguments for non-allocatable, non-pointer dummy arguments.

The special-case rule for strings is that you don't have to have length
agreement in all cases. In the exceptional cases, argument association
is done as character-by-character argument sequence association. That's
perhaps a complicated way of saying that it "just works". (But no, it
doesn't involve automatic appending or removal of null characters).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Gary Scott wrote:
(snip)

> No, I only use F95 compilers at present (CVF, LF95, Absoft F90) that
> interoperate with normal character buffers of whatever length as long as
> you insert a null character at the end of the trimmed length. Are you
> saying that I must use an array to designate a string? Boy that would
> be inconvenient.

Note that null terminated strings aren't part of the C language,
but are used by some C library routines. There are many library
routines that will work just fine with strings without null
terminators. As in a previous post on sorting, there is
strncmp which will compare strings up to a specified length
(or to a null character if that comes first.) There is
also memcmp() to compare strings containing null characters.

-- glen

glen herrmannsfeldt wrote:
> Gary Scott wrote:
> (snip)
>
>> No, I only use F95 compilers at present (CVF, LF95, Absoft F90) that
>> interoperate with normal character buffers of whatever length as long
>> as you insert a null character at the end of the trimmed length. Are
>> you saying that I must use an array to designate a string? Boy that
>> would be inconvenient.
>
>
> Note that null terminated strings aren't part of the C language,
> but are used by some C library routines. There are many library
> routines that will work just fine with strings without null
> terminators. As in a previous post on sorting, there is
> strncmp which will compare strings up to a specified length
> (or to a null character if that comes first.) There is
> also memcmp() to compare strings containing null characters.

I've yet to run across any C APIs that do not expect/return null
termintors, but if I ever do, it won't surprise me as much.

>
> -- glen
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

glen herrmannsfeldt wrote:

> Gary Scott wrote:
> (snip)
>
>> I've yet to run across any C APIs that do not expect/return null
>> termintors, but if I ever do, it won't surprise me as much.
>
>
> See strncpy() in the standard C library.

The only C APIs I use are those I'm forced to like Win32, or those for
various serial bus cards or discrete/analog I/O devices. I use nothing
that's part of the C language otherwise, and hope to never again have to.

>
> -- glen
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

glen herrmannsfeldt wrote:

> Note that null terminated strings aren't part of the C language,

This is from a old copy of a C99 draft I have, sorry, no date.

5.2.1 Character sets
[#2] In a character constant or string literal, members of
the execution character set shall be represented by
corresponding members of the source character set or by
escape sequences consisting of the backslash \ followed by
one or more characters. A byte with all bits set to 0,
called the null character, shall exist in the basic
execution character set; it is used to terminate a character
string.

LR

Gary Scott wrote:
(snip)

> I've yet to run across any C APIs that do not expect/return null
> termintors, but if I ever do, it won't surprise me as much.

See strncpy() in the standard C library.

-- glen