[sdcc-devel] [ sdcc-Bugs-1504689 ] SDCC not always reporing error to calling system

[SourceForge.net <no...@so...>]

Bugs item #1504689, was opened at 2006-06-12 13:07
Message generated for change (Settings changed) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1504689&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steven Borley (sjborley)
>Assigned to: Maarten Brock (maartenbrock)
Summary: SDCC not always reporing error to calling system 

Initial Comment:
Normal practice is for applications to return a non-
zero value on error.  SDCC does not always do this 
(correctly) for all systems.

eg. on MinGW

$ sdcc -mx test.c
-:0: error 131: cannot generate code for target 'x'
$ echo $?
1

However,
$ sdcc -o
-:0: error 148: Option -o requires an argument.
$ echo $?
0

The above are trivial example, easy to replicate. 
However I have seen this problem in other
non-trivial code errors (such as validateLink errors -
 see bug 1503239  for example code).

A consequence is that the make program does not spot 
the error and will blindly continue. On a large 
project it's easy for the user to miss this, 
especially if an old object file still remains in the 
build directory to keep the linker quiet.

Looking through the source code I notice that the 
problem appears to be related to where
exit(-1) is used, rather than exit(1).

The treatment of exit() might be system dependent. 
I'm using MinGW. However, the man pages I have 
consulted do suggest that EXIT_SUCCESS and 
EXIT_FAILURE are the only valid values for exit() to 
retain portability. 

My guess is that this is the cause of the problem 
(and the way MinGW is handling the exit value).

I accept this is could be a considered a bug with the 
MinGW, but for sake of portability please consider 
implementing a fix for this problem.

$ sdcc -v
#SDCC : 
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/
ds400/hc08 2.5.6 #4214 (Jun 11 2006) (MINGW32)



----------------------------------------------------------------------

>Comment By: Maarten Brock (maartenbrock)
Date: 2006-06-12 23:24

Message:
Logged In: YES 
user_id=888171

Fixed in SDCC 2.5.6 #4222 by replacing all exit(-1) by exit
(EXIT_FAILURE).

----------------------------------------------------------------------

Comment By: Steven Borley (sjborley)
Date: 2006-06-12 23:06

Message:
Logged In: YES 
user_id=1270801

I can confirm this is MacOSX not affected. Cygwin too seems okay. Not tested 
linux. Only seems a problem with MinGW.

I  can also confirm that changing exit(-1) to exit(EXIT_FAILURE) fixes this 
problem on MinGW.  There are quite a few occations where exit(-1) occurs in 
the code - I only tested one location in SDCCMain.c that gets triggered for 
may example above.

I would post a patch, but this now seem a design issue - change to useing 
EXIT_SUCCESS and EXIT_FAILURE or just change exit(-1) to exit(EXIT_FAILURE) 
(or even exit(1)), or some other combinations.

The other reason why I am reluctant tp post a patch is that I cannot SDCC to 
fully compile on MinGW - so I cannot test it properly. Today I just got enough 
compiled to do the test. (but that's another issue).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1504689&group_id=599