Problem with "make check"

Developers
Matt Beard
2004-11-05
2013-04-25
  • Matt Beard
    Matt Beard
    2004-11-05

    Original post by stuart_hc, moved from the "lock" thread.

    The "make check" target on the Develop-EssenceRead branch hangs (under Linux and WIN32) when it gets to the mxfsplit test. Do you have a fix for this? If not, I can look into it.

     
    • Matt Beard
      Matt Beard
      2004-11-05

      Please do look into this.

      Matt

       
    • The cause of the hang is mxfsplit's use of getchar() where it attempts to read input from the terminal.  When running under the autotest framework of "make check" it will never receive terminal input.

      The getchar() calls were removed from mxfsplit for the large portability fixes which went into mxflib-alpha-0.4.0, but were reinstated by terabrit shortly after the last release.  Not only is there no portable way to test a program reading from the terminal, the getchar() function also causes compile failures on other platforms.

      I'm reluctant to check in a fix for this if the offending code is going to be promptly reinstated.

       
      • Oliver Morgan
        Oliver Morgan
        2004-11-05

        I don't mind changes in operational or functional behaviour that are:
        (a) discussed beforehand
        (b) isolated from other changes by placing them in separate checkins
        (c) documented by explicit checkin comments.

         
      • Matt Beard
        Matt Beard
        2004-11-06

        My understanding is that getchar() is standard C++ (or at least C++ compatible C) - indeed Stroustrup suggests its use in "The C++ Programming Language" and it doesn't get much more pukka than that!!

        Command-line option "-q" will set mxfstrip into quiet mode and prevent any calls to getchar()

        I will attempt to add "-q" for make check.

         
        • getchar() is ISO C and C++ (and IEEE 1003.1 & POSIX by reference).  Alas, not all compilers adhere to the standards.

          The 2nd mxfsplit test was intended to test verbose output of mxfsplit so that regressions would be caught.  If -q is used, only a few lines are output.  If we keep the getchar() reading from terminal behaviour for default args, we would need another flag to turn off the read-from-terminal behaviour.  Or, we could simply drop the read-from-terminal behaviour - I cannot see what benefit it provides since it occurs immediately before program exit.