So, I discovered it is possible to cause Lex scanner to call exit() when instead of a file, for input, it is given a directory. It then will print input in flex scanner failed and will exit the program... This is... very unexpected behavior for a library code, to put mildly.
Thus, the question: is there any way to preclude Lex code from ever exiting the program? I mean, there's no reason yyparse or yypush_parse or their friends not report this in their exit code... why should they terminate the whole program? I was looking for options to specify in *.l file and such... but so far all web search hits suggest I just check myself for all possible conditions under which Lex will terminate the program and catch them before they get to Lex.
That's correct, and it is a bit ugly. Flex scanners die ungracefully on I/O errors, and there is no simple option to prevent that.
Flex scanners will also call exit() if there is a memory allocation error (including cases where buffers cannot be dynamically reallocated) and a variety of internal errors.
You can avoid the issue with I/O errors by implementing your own definition of YY_INPUT which doesn't call exit(), but there is no mechanism for the YY_INPUT macro to report an error, in part because there is no way for yylex to return an error indication to the parser. You could use some clumsy workaround like setting a flag and returning EOF (i.e. 0), but it isn't very clean.
Looking at the Flex skeleton file, it appears that you could define the macro YY_FATAL_ERROR(msg), which wraps the call to exit(). However, it is not entirely clear what you could actually do to report the error condition. You can't just return because some of the invocations of YY_FATAL_ERROR are not in the main yylex function. About the only possibility I can see would be a longjmp (unless you're using C++, in which casr you could throw an exception).