#3979 Strangely failing [puts]

obsolete: 8.5.2
open
5
2008-04-16
2008-04-16
Kaitzschu
No

Confirmed on Fedora Core 7, OpenSuse 10.2, Windows 2000 and XP.

When running attached script it emits quite a few blankish lines and after that spits out

error writing "stdout": invalid argument

without any apparent reason. And stdout is still writable. In comp.lang.tcl Twylite figured out that [$t get ...] returns not-quite-empty value 0xC3 and considered "some sort of encoding problem" being there.

Drawing widget or changing length of sample text changes snippets behavior, selected category is mostly a guess.

Expected behavior: not giving me errors, naturally .)

Discussion

  • Kaitzschu

    Kaitzschu - 2008-04-16

    Weirdly acting code

     
    Attachments
  • Andreas Kupries

    Andreas Kupries - 2008-04-16

    Logged In: YES
    user_id=75003
    Originator: NO

    Testing this on Linux (SuSe 9), confirmed.

    Notes:
    * Adding a \t to the puts seems to prevent the error, but also seems to cause an infinite loop.
    * Printing information in a separate puts has no influence on either, allowing us to monitor the various variables.
    * Adding \t does cause infinite loop, with $i reaching '2.0' and then staying there forever.
    * Without the \t the reported error occurs when $i is 1.63. This seems to coincide with the a-umlaut character (The char after 'pitki').

    ... It seems that the infinite loop is just a bad end condition
    ... xi = 1.0, 'xi display lineend' comes back as 1.0 as well, and that value is never reached by the loop (starts at 1.82, drops to 1.1, then increments to either 1.63 for error, or 2.0 without).

    * I managed to reduce the string, use 'M a-umlaut u', i.e. just 3 chars, and that is good enough. Having the a-umlaut as first char, or only two chars, i.e. without u makes the problem go away.

    I am suspecting that it is less in puts, and more something in the text widget creating a bad internal string.

     
  • Nobody/Anonymous

    Logged In: NO

    With the current Tcl/Tk HEAD as of today:

    There may be 2 bugs here. 1 seems to be that the TkTextIndex (both of them for the [.t get]) ->linePtr are the same for every iteration, and the other is that the byteIndex advances when it's supposed to be a display line advancement.

    I added this to just before the TextGetText() call in the TEXT_GET path:
    printf("index1Ptr->linePtr %p index1Ptr->byteIndex %d\n", (void *)index1Ptr->linePtr, index1Ptr->byteIndex);
    printf("index2Ptr->linePtr %p index2Ptr->byteIndex %d\n", (void *)index2Ptr->linePtr, index2Ptr->byteIndex);

    ...
    Tcl_Obj *get = TextGetText(textPtr, index1Ptr, index2Ptr, visible);

    Then I added this bit of code:
    {
    char *p;
    int len;
    p = Tcl_GetStringFromObj(get, &len);
    printf("length %d\n%s\n", len, p);
    printf("p[0] = %x\n", p[0] & 0xff);
    }

    index1Ptr->linePtr 0x820aca0 index1Ptr->byteIndex 63
    index2Ptr->linePtr 0x820aca0 index2Ptr->byteIndex 63

    index1Ptr->linePtr 0x820aca0 index1Ptr->byteIndex 64
    index2Ptr->linePtr 0x820aca0 index2Ptr->byteIndex 65
    length 1

    p[0] = c3

    That's the only point that it has a byteIndex > 0, and that's when it produces the error in the puts path. From what I've read 0xc3 is not a valid UTF-8 character. 0xC3,0x83 on the other hand might be. I'm not sure whether the bug is in GetIndex of the text widget (which returns the invalid byteIndex) or TextGetText -- they both may have bugs.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks