Re: SVN 1704 completely broke libedif

[Dr . Jürgen Sauermann]

    Hi Chris,
    
    wrapping arbitrary (= UTF8-encoded) strings into UTF8_string first
    is
    the proper way to go. Consider the differences between:
    
      1.  UCS_string yyy(UTF8_string(xxx));   // almost proper,
        but ambiguous (most vexing parse error)
      2.  UCS_string yyy(xxx);                // now private: so
        never use it
        3a. UTF8_string utf(xxx);              // really proper
        3b. UCS_string yyy(utf);
        4.  UCS_string
            yyy((UTF8_string(xxx)));   // also proper (this is 1.
            without the most vexing
                parse error)
                5.  UCS_ASCII_string yyy(xxx)
               
    If xxx is entirely ASCII then all of the above are
    equivalent.
    
    Otherwise the difference is that 1. properly decodes UTF8-encoded
    strings while the old 2. (which is now  disabled by private:) did
    not
    (and the compiler has no way to detect an incorrect usage of 2.
    
    Even worse, C++ would sometimes do 2. automatically (and
    incorrectly)
    and without notice. Probably some of the recent Tokenization Errors
    reported on bug-apl were caused by this.
    
    Although 1. was throwing an assertion when used incorrectly, some
    people wrapped a try {} catch {} around it which caused the
    error
    to slip through unnoticed (at least up to the tokenizer).
    
    A somewhat  unfortunate decision in the C++11 ff. standards was to
    resolve yyy in  1. (which is ambiguous at a closer look)
    into a declaration
    of function yyy() and not (as gcc still does) into two
    constructor calls
     UTF8_string(xxx) followed by UCS_string() with the
    first. This problem
    can apparently be avoided by using 4. instead of 1. (note the extra
    pair
    of () which is NOT redundant).
    
    Finally, 5. is a safe replacement for 2. (and the comment in the .hh
    file
    is still valid (so xxx MUST be ASCII), which should
    hopefully avoid the
    automatic use of 2. by the compiler. It is also easier to use with grep
    in order to spot the (still possible) incorrect usage of 5.
    
    Hope this helps,
    Jürgen

On 6/6/23 22:13, Chris Moller wrote:

Yeah, I saw your comment in one of the .hh files.  What I did was wrap all the edif ASCII strings in UTF8_string() calls.  That works, but if it's circumventing what you're trying to do, let me know and I'll think of something else. 

Even after a lot of years, I'm still not sure of the differences between UTF, UCS, Unicode, etc, etc.

--cm

On 6/6/23 15:56, Dr. Jürgen Sauermann wrote:

Hi,

sorry for that. The reason for making it private is to entirely prevent its usage.
The former implementation of of it only worked for ASCII strings. There was
a note about that in the header file, but I have seen quite a few incorrect
usages of it (read: with UTF8-encoded strings) which then caused other, difficult
to find, errors later on.

Best Regards,
Jürgen

On 6/6/23 17:31, Chris Moller wrote:

Hi, Xtian,

Just pushed a fix for edif if you want to give it a try.  Works for me on SVN 1706 and yesterday's SVN 1708.

--cm

On 6/5/23 03:33, Christian Robert wrote:

SVN 1704 completely broke libedif

Juergen made UCS_string (const char *)  a private member of the class
so a lot of compile errors in edif.cc ...

Not sure if this can be fixed. I reverted to SVN 1702 meanwhile. The is no way I'll revert to the "DEL Editor" !


Xtian.