Some error about loki compiling.

  • maliku

    maliku - 2009-12-07

    Hi,I found some error when the latest version of svn  trunk compiling:
    ../../include/loki/StrongPtr.h:1: error: stray ‘\357’ in program
    ../../include/loki/StrongPtr.h:1: error: stray ‘\273’ in program
    ../../include/loki/StrongPtr.h:1: error: stray ‘\277’ in program

    I take the type of file which named StrongPtr.h by used 'file' command:

    $ file StrongPtr.h

    StrongPtr.h: Unicode text, UTF-8

    and other files are ASCII:

    $ file ./SmallObj.h

    SmallObj.h: ASCII C++ program text

    after that I get the log of svn, and export the old version of StrongPtr.h, I found the StrongPtr.h was ASCII until rev-1052.

    The problem also in ForEachType.h and so on.

  • maliku

    maliku - 2009-12-07

    by the way, version of my gcc is 4.2.4

  • Richard Sposato

    Richard Sposato - 2009-12-08

    Sorry you came across this problem.  I looked into it, but could not duplicate the error message you reported.

    I looked at my copies of StrongPtr.h and SmallObj.h to see if there were any non-ascii chars, but I saw none.  I even got fresh copies from subversion, but again saw no strange characters in the files.

    However, I did check the online history of StrongPtr.h and the annotated view of this file.  ()  The bottom of the webpage shows strange characters - but those are not in the file I received from subversion.  I suspect the problem is only in how the file is displayed when browsing through the code online - but not part of the actual file when you download it from Loki's subversion repository.

    Did you get this file by downloading directly from the code-browsing feature or did use the "svn checkout" command?




  • maliku

    maliku - 2009-12-14

    Thanks for your reply. Firstly, I am much sure that I use the "svn checkout" command to get copies. Secondly, I discovered that ‘\357’ ‘\273’ ‘\277’ are the BOM (byte order mark) of UTF-8 for Windows which are "EF BB BF" by hexadecimal.
    I suspect your soure files was edited by some Windows editor, because I know many Windows programs add BOMs to UTF-8 files by default. However, in Linux this pratice is not recommanded.

    Thanks and best regards.

  • Peter Kuemmel

    Peter Kuemmel - 2009-12-14

    Thanks! Good to know "no BOMbs on Linux" ;)

    Does it work for you now?

    Just for the records, this tools (not complete)  could be used under Linux:
    - vim with :set nobomb
    - Editor geany (there is a BOM menu entry)

  • maliku

    maliku - 2009-12-15

    It dose work after I updated the trunk.
    Thanks a lot.

  • maliku

    maliku - 2009-12-15

    It does work after I updated the trunk. Thanks a lot.

  • Richard Sposato

    Richard Sposato - 2009-12-17

    If the ‘\357’ ‘\273’ and ‘\277’ byte order marks were added by a Windows editor that uses UTF-8 encoding, then that was likely done by me.  I've been using various editors when working on source code from my different computers.  I'll check the editors and change the settings if necessary.

    Sorry about any inconvenience that caused you.

  • Pong

    Pong - 2010-03-28

    I also found this error. It came from the copyright text at the beginning of some files. These files have the copyright message to "Peter Kummel". Actually, the second letter of his surname is not an English character (it is "u" with 2 dots above it). Therefore, if you edited these files, the editor may force you to save them using UTF format instead of ASCII.


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks