Re: [Bug-apl] Assertion failed

[Ala'a Mohammad]

Hi,

I do not know if this is the same cause, but the assertion seems to be the same

in a new session do the following
- write an incorrect name like 'x.y'
- edit a function like 'z'
- save the function
- edit the z function again, and you get the failed assertion

I'm running the latest APL version from svn:
: apl --version
BUILDTAG:
---------
    Project:        GNU APL
    Version / SVN:  1.7 / 1003M
    Build Date:     2017-08-28 18:02:08 UTC
    Build OS:       Linux 3.13.0-37-generic x86_64
    config.status:  'RATIONAL_NUMBERS_WANTED=yes'
    Archive SVN:    989

Here is a session sample:
----------------------------------

      x.y
VALUE ERROR
      x.y
        ^
      ∇z
      ∇z

==============================================================================
Assertion failed: items
in Function:      at
in file:          ../Simple_string.hh:277

Call stack:

----------------------------------------
-- Stack trace at ../Simple_string.hh:277
----------------------------------------
0x7F2ECE271184
0x7F2EC8FF0BDE  connection_loop(void*)
0x7F2EC8FF40FE   NetworkConnection::run()
0x7F2EC8FF30CB    NetworkConnection::process_command(std::string const&)
0x7F2EC8FECCA7     FnCommand::run_command(NetworkConnection&,
std::vector<std::string, std::allocator<std::string> > const&)
0x45EA0F      do_Assert(char const*, char const*, char const*, int)
========================================

SI stack:

Depth:      0
Exec:       0xbaf770
Safe exec:  0
Pmode:      ◊  x.y
PC:         0 (5) 'y
Stat:       x.y
err_code:   0x30001
thrown at:  Symbol.cc:683
e_msg_1:    'VALUE ERROR'
e_msg_2:    '      x.y'
e_msg_3:    '        ^'


==============================================================================
terminate called after throwing an instance of 'ErrorCode'

Process apl aborted


Hope It Helps

Regards,

Ala'a





On Tue, Aug 8, 2017 at 2:18 PM, Elias Mårtenson <address@hidden> wrote:
> If that's the case, then you are indeed right. It's possible that the
> std::string constructor will work, but that would be more out of luck than
> anything else.
>
> Regards,
> Elias
>
> On 8 August 2017 at 18:11, Juergen Sauermann <address@hidden>
> wrote:
>>
>> Hi Elias,
>>
>> correct, except that an UCS8_string is not a string, despite of its name.
>> UCS8_strings have no terminating 0 byte; the 0-byte is only appended if
>> the UCS8_string is converted to a C string with function c_str().
>>
>> /// Jürgen
>>
>>
>> On 08/08/2017 09:28 AM, Elias Mårtenson wrote:
>>
>> Sorry for not replying earlier, I forgot about this message.
>>
>> ucs[0] should be OK for an empty string, as that will still refer to the
>> terminating NUL byte at the end of the string. Note that an empty string is
>> differetn from a NULL pointer (the former is a valid string, and the other
>> is not).
>>
>> Regards,
>> Elias
>>
>> On 1 August 2017 at 19:04, Juergen Sauermann
>> <address@hidden> wrote:
>>>
>>> Hi Elias,
>>>
>>> I don't know what Ala'a did. However, looking at:
>>>
>>> /// return a UTF8 encoded std:string
>>> inline std::string to_string(const UCS_string & ucs)
>>> {
>>>     const UTF8_string utf(ucs);
>>>     return string((const char *)&utf[0], utf.size());
>>> }
>>>
>>> I am not sure what happens if string ucs is empty (in that case ucs[0]
>>> does not
>>> exist and may be makes &ucs[0] also 0. The std::string constructor then
>>> looks
>>> for the terminating 0 character in a 0-pointer. Using
>>> UTF8:string::c_str() might
>>> be better.
>>>
>>> Also converting a UCS or UTF8 string to std::string just for outputting
>>> it with << may be
>>> an overkill, since ostream << often (read: after #include
>>> "PrintOperator.hh") understands
>>> UCF and UCS strings directly.
>>>
>>> /// Jürgen
>>>
>>>
>>> On 07/31/2017 02:31 AM, Elias Mårtenson wrote:
>>>
>>> Can you tell me exactly what you are doing in order to reproduce the
>>> problem?
>>>
>>> Regards,
>>> Elias
>>>
>>>
>>
>>
>