Troubles with C strings

Troubles with C strings

[Victor Porton]

RM2012 B.3.1:

39 function Value (Item : in chars_ptr; Length : in size_t)
   return String;
40/1 Equivalent to To_Ada(Value(Item, Length) & nul, Trim_Nul=>True).

Isn't the function Value improperly recursively defined through itself?! 
Please explain.

Also: It seems that in Interfaces.C.Strings there is no function which 
creates an Ada string of specified length from a chars_ptr (without checking 
for NUL). Addition of such a function would be good, because it can be very 
fast (on some platforms it can be implemented as memcpy).

-- 
Victor Porton - http://portonvictor.org

Re: Troubles with C strings

[Shark8]

On 26-Jul-14 08:13, Victor Porton wrote:
> Also: It seems that in Interfaces.C.Strings there is no function which
> creates an Ada string of specified length from a chars_ptr (without checking
> for NUL). Addition of such a function would be good, because it can be very
> fast (on some platforms it can be implemented as memcpy).

Such a function cannot exist: to determine the length of a C-style 
string you *must* scan through it for the terminating NULL. What you 
describe would be a "substring" method that can read beyond the 
string-bounds without raising an error... and I see no way that would 
end well.

Re: Troubles with C strings

[Victor Porton]

Shark8 wrote:

> On 26-Jul-14 08:13, Victor Porton wrote:
>> Also: It seems that in Interfaces.C.Strings there is no function which
>> creates an Ada string of specified length from a chars_ptr (without
>> checking for NUL). Addition of such a function would be good, because it
>> can be very fast (on some platforms it can be implemented as memcpy).
> 
> Such a function cannot exist: to determine the length of a C-style
> string you *must* scan through it for the terminating NULL. What you
> describe would be a "substring" method that can read beyond the
> string-bounds without raising an error... and I see no way that would
> end well.

It can. The length of the string may be "scanned" earlier and be stored, so 
that we could later use it efficiently.

-- 
Victor Porton - http://portonvictor.org

Re: Troubles with C strings

[Shark8]

On 26-Jul-14 09:52, Victor Porton wrote:
> It can. The length of the string may be "scanned" earlier and be stored, so
> that we could later use it efficiently.

That still involves scanning.

Re: Troubles with C strings

[Niklas Holsti]

On 14-07-26 17:13 , Victor Porton wrote:
> RM2012 B.3.1:
> 
> 39 function Value (Item : in chars_ptr; Length : in size_t)
>    return String;
> 40/1 Equivalent to To_Ada(Value(Item, Length) & nul, Trim_Nul=>True).
> 
> Isn't the function Value improperly recursively defined through itself?! 

No, the definition uses another Value function.

> Please explain.

The call in 40/1 uses

   function Value (Item : in chars_ptr; Length : in size_t)
   return char_array;

from RM B.3.1(35), followed by

   function To_Ada (Item     : in char_array;
                    Trim_Nul : in Boolean := True)
   return String;

from RM B.3(26).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Troubles with C strings

[Peter Chapin]

On 2014-07-26 11:15, Shark8 wrote:

> On 26-Jul-14 08:13, Victor Porton wrote:
>> Also: It seems that in Interfaces.C.Strings there is no function which
>> creates an Ada string of specified length from a chars_ptr (without
>> checking for NUL).
> 
> Such a function cannot exist: to determine the length of a C-style
> string you *must* scan through it for the terminating NULL. What you
> describe would be a "substring" method that can read beyond the
> string-bounds without raising an error... and I see no way that would
> end well.

Well the function could exist; it would just require an additional
parameter to specify how much should be copied. While such an approach
might be contrary to the sensibilities of Ada programmers, I don't think
C programmers would find it shocking.

Of course we are talking about an Ada interface here so adding a
function that by its nature could easily lead to undefined behave...
er... erroneous execution probably wouldn't be great.

Re: Troubles with C strings

[Victor Porton]

Peter Chapin wrote:

> On 2014-07-26 11:15, Shark8 wrote:
> 
>> On 26-Jul-14 08:13, Victor Porton wrote:
>>> Also: It seems that in Interfaces.C.Strings there is no function which
>>> creates an Ada string of specified length from a chars_ptr (without
>>> checking for NUL).
>> 
>> Such a function cannot exist: to determine the length of a C-style
>> string you *must* scan through it for the terminating NULL. What you
>> describe would be a "substring" method that can read beyond the
>> string-bounds without raising an error... and I see no way that would
>> end well.
> 
> Well the function could exist; it would just require an additional
> parameter to specify how much should be copied. While such an approach
> might be contrary to the sensibilities of Ada programmers, I don't think
> C programmers would find it shocking.
> 
> Of course we are talking about an Ada interface here so adding a
> function that by its nature could easily lead to undefined behave...
> er... erroneous execution probably wouldn't be great.

Jut call this function *_Unchecked or *_Unsafe and it would turn it safe. 
:-)

-- 
Victor Porton - http://portonvictor.org

Re: Troubles with C strings

[Victor Porton]

Victor Porton wrote:

> Peter Chapin wrote:
> 
>> On 2014-07-26 11:15, Shark8 wrote:
>> 
>>> On 26-Jul-14 08:13, Victor Porton wrote:
>>>> Also: It seems that in Interfaces.C.Strings there is no function which
>>>> creates an Ada string of specified length from a chars_ptr (without
>>>> checking for NUL).
>>> 
>>> Such a function cannot exist: to determine the length of a C-style
>>> string you *must* scan through it for the terminating NULL. What you
>>> describe would be a "substring" method that can read beyond the
>>> string-bounds without raising an error... and I see no way that would
>>> end well.
>> 
>> Well the function could exist; it would just require an additional
>> parameter to specify how much should be copied. While such an approach
>> might be contrary to the sensibilities of Ada programmers, I don't think
>> C programmers would find it shocking.
>> 
>> Of course we are talking about an Ada interface here so adding a
>> function that by its nature could easily lead to undefined behave...
>> er... erroneous execution probably wouldn't be great.
> 
> Jut call this function *_Unchecked or *_Unsafe and it would turn it safe.
> :-)

Hey, anyone!

Could we add this *_Unchecked or *_Unsafe to Ada202x?

-- 
Victor Porton - http://portonvictor.org