Interfaces.C.String.Update

Interfaces.C.String.Update

[awdorrin]

What is the suggested method to null terminate an Ada string being
passed back to C via Interfaces.C.Strings.Update() ?

I've been looking at the code for i-cstrin.adb, and it seems that by
default that the procedure, when passing in an Ada String, uses To_C
with Append_Null  set to False.

I was trying to determine if I should manually place the null
character, or instead call Update like:

Update( cPtr, 0, To_C( AStr, Append_Nul => True), False);

I haven't been able to find any discussions on this, so I'm just not
sure what the 'best' approach for this would be.

Re: Interfaces.C.String.Update

[Adam Beneschan]

On Nov 28, 7:55 am, awdorrin <awdor...@gmail.com> wrote:
> What is the suggested method to null terminate an Ada string being
> passed back to C via Interfaces.C.Strings.Update() ?
>
> I've been looking at the code for i-cstrin.adb, and it seems that by
> default that the procedure, when passing in an Ada String, uses To_C
> with Append_Null  set to False.

Right, that's actually in the RM.  B.3.1(49-50):

[49] procedure Update (Item   : in chars_ptr;
                       Offset : in size_t;
                       Str    : in String;
                       Check  : in Boolean := True);

[50] Equivalent to Update(Item, Offset, To_C(Str, Append_Nul =>
False), Check).

Since that's the language used in the RM, it seems most appropriate to
me that if you want to do the same kind of Update but *with* a null
character appended, you'd use the same code shown in the RM but with
Append_Nul => True.  It probably doesn't matter except as a matter of
style, but that's what I'd do (unless execution speed is *very*
critical, in which case a function call such as To_C that returns an
unconstrained array could involve too much overhead.  I doubt that's
true in your case).

                  -- Adam

Re: Interfaces.C.String.Update

[Ludovic Brenta]

awdorrin wrote on comp.lang.ada:
> What is the suggested method to null terminate an Ada string being
> passed back to C via Interfaces.C.Strings.Update() ?
>
> I've been looking at the code for i-cstrin.adb, and it seems that by
> default that the procedure, when passing in an Ada String, uses To_C
> with Append_Null  set to False.
>
> I was trying to determine if I should manually place the null
> character, or instead call Update like:
>
> Update( cPtr, 0, To_C( AStr, Append_Nul => True), False);
>
> I haven't been able to find any discussions on this, so I'm just not
> sure what the 'best' approach for this would be.

I think you are correct, perhaps a more terse idiom would be:

Update( cPtr, 0, AStr & ASCII.NUL, False);

This is because, if Check is True,

procedure Update (Item   : in chars_ptr;
                  Offset : in size_t;
                  Chars  : in char_array;
                  Check  : Boolean := True);

assumes that Item is null-terminated on input in order to call
Strlen (Item), but does not require Chars to be null-terminated
because
Chars is a char_array with known bounds.  If Item is not null-
terminated
before you call Update, you're in for C-style trouble :)

If Check is False, all bets are off, so you'd better null-terminate
Item manually.

--
Ludovic Brenta.
The synchronized executive talents result in the functional successful
execution.

Re: Interfaces.C.String.Update

[awdorrin]

Thanks for the confirmation and the suggestions.

One followup question about Update and the use of Check=>True...

If I'm understanding things properly, given the following scenario:

Character array defined in C, initialized with a memset of nulls.

Passing a char* to Ada, using the Chars_Ptr - Any attempt to use
Update with Check=>True will raise an Update_Error, because Ada will
see the string pointed to as zero length, right?

So this requires us to disable the check and do some checking on both
sides to make sure that we don't blow the char buffers.

I think, updating these functions to pass in the buffer length (or
'cheating' by initializing the char arrays with spaces instead of
nulls) would be safer, and allow me to take advantage of the
Check=>True functionality.

Re: Interfaces.C.String.Update

[Ludovic Brenta]

awdorrin wrote on comp.lang.ada:
> Thanks for the confirmation and the suggestions.
>
> One followup question about Update and the use of Check=>True...
>
> If I'm understanding things properly, given the following scenario:
>
> Character array defined in C, initialized with a memset of nulls.
>
> Passing a char* to Ada, using the Chars_Ptr - Any attempt to use
> Update with Check=>True will raise an Update_Error, because Ada will
> see the string pointed to as zero length, right?

Right.

> So this requires us to disable the check and do some checking on both
> sides to make sure that we don't blow the char buffers.

Right.

> I think, updating these functions to pass in the buffer length (or
> 'cheating' by initializing the char arrays with spaces instead of
> nulls) would be safer, and allow me to take advantage of the
> Check=>True functionality.

In this case I would think it is easier to forget about C's notion
of a string (null-terminated, no length) and use Ada's notion on
both sides (length known at run time).  If you control the C side
of your system, you can easily make it allocate exactly the length
needed and pass the length explicitly.  Then on the Ada side you do
not need Interfaces.C.Strings anymore, just copy one char_array to
another.

--
Ludovic Brenta.
Our gut-feeling is that the stakeholders transition a progressive
trend across the board.