Some error about loki compiling.

Developers
maliku
2009-12-07
2013-04-08
  • 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

     
  • 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?

    Cheers,

    Rich

      : http://loki-lib.svn.sourceforge.net/viewvc/loki-lib/trunk/include/loki/StrongPtr.h?view=markup&sortby=rev&pathrev=1052

     
  • 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.

     
  • 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.