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.
Please do look into this.
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.
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.
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.