Page MenuHomePhabricator

Add ability to set a return code from efl_exit()
Closed, ResolvedPublic

Description

Currently the return code is set by the loop exiting but there is no binding to override that code.
For a simple EFL app it would be important to be able to set exit.
Suggest efl_exit_code(int) or similar..?

cedric added a comment.EditedOct 17 2017, 10:18 AM

This was an oversight and fully planned from the beginning. Will commit a patch shortly.

Sorry, but why is this an unsigned char instead of an int?

The logic is that the exit_code match the 8bits status that WEXITSTATUS return in the parent process doing the wait.

But isn't that a bit too POSIX-specific? The C standards (§5.1.2.2.1) states it shall be an int. since int is compatible with unsigned char, why not being closer than the C standard rather than a specific implementation?

Do you know system that can handle return bigger than an int and that would not break a lot of software including efl itself ?

Bigger than an int, I'm not sure, since it is against the C standard. But my point here is that systems may (and do) return bigger than unsigned char.
Windows does (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683189(v=vs.85).aspx).

ah, sorry, indeed in meant bigger than an unsigned char. This open a good question. How would efl behave with this ? Hum, will have to think. I am still leaning toward the smallest common denominator, but that might be a wrong things. Need to think about it.

jayji reopened this task as Open.Oct 19 2017, 12:44 PM

While you are thinking, I re-open the issue, just so it does not get forgotten ;)

jpeg added a comment.Oct 19 2017, 11:07 PM

All OS will support uchar but not int. Thus IMHO we should only expose the common denominator here, i.e. uchar. This doesn't really prevent people from returning int on Windows (write the main() yourself or call exit()), but this shows that only uchar really might be supported. I think the C specification has nothing to do with this, since we target multiple languages. Anyway, this is just my opinion. :)

Still seems weird to me. We (EFL) don't do anything with this value, I think this is really up to the user to pass whatever it wants. So int _seems_ more appropriate to me.
If we want to support anything, why not pass a void*? (this is a real suggesion) So one can do this (in python for instance):

python
efl.exit("Bye, world") # same than sys.exit("Bye, workd")

or in C:

c
efl_exit("Bye, world");
/* .... */
main() {
  const char *const ret = efl_run();
  if (ret) fprintf(stderr, "E: %s\n", ret);
  return (ret) ? EXIT_FAILURE : EXIT_SUCCESS;
}

And even (gross, but that's just for the picture):

c
#define EFL_EXIT_CODE(Code) ((void*)(Code))

efl_exit(EFL_EXIT_CODE(0xffff));
/* .... */
main() {
  const int code = (int)(efl_run());
  return ret;
}

@jayji: we couldn't return pass a void* it doesn't work for binding. We could go with an Eina_Value (which has also an error type). Sounds fun to me, but seems quite over engineering. Maybe we want the complex version along with an helper. The helper would take an unsigned char and automatically build an Eina_Value. efl_run would return the Eina_Value and it would be the binding job to know what to do. In C, it would check the type (string, error, int, ...) and have an appropriate behavior then (exit with 0 for string and friends, exit with -1 for error and with the value for all the numerical version).

What do you think ?

jayji added a comment.Oct 28 2017, 6:55 AM

I can roll with that. A helper to sort out just the exit code would be nice.

jpeg added a comment.Oct 29 2017, 6:29 PM

Interesting approach!