Hey,
I notice that there is a FEprogram_error and a FEprogram_error_noreturn in src/c/error.d; however, it looks like these functions are identical aside from their names.
I copied these to different files and diff'd them:
--- test 2017-06-28 15:39:32.199877688 -0500 +++ test2 2017-06-28 15:39:32.199877688 -0500 @@ -1,5 +1,5 @@ void -FEprogram_error(const char *s, int narg, ...) +FEprogram_error_noreturn(const char *s, int narg, ...) { cl_object real_args, text; ecl_va_list args;
FEprogram_error_noreturn was added in commit 7d9fb8bb. I think it was added because FEprogram_error didn't have the noreturn attribute, so FEprogram_error_noreturn was introduced with this attribute. However, it looks like FEprogram_error (and others) got this attribute in commit 790d466c. (This all happened in Feb 2010.)
Currently in src/h/external.h:
extern ECL_API void FEprogram_error(const char *s, int narg, ...) ecl_attr_noreturn; extern ECL_API void FEprogram_error_noreturn(const char *s, int narg, ...) ecl_attr_noreturn;
They are both used throughout src/c.
It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn.
If these changes are desired, then I can open up a new Merge Request with these changes after my currently open Merge Request is done (to avoid conflicts).
Cheers, Kris Katterjohn
Il giorno 29 giu 2017, alle ore 10:25, Daniel Kochmański daniel@turtleware.eu ha scritto:
It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn.
If they do the same then yes, please remove one of them.
I'm not sure if that is an internal or is part of the public interface.
In case of the latter would it make sense to #define the one we are going to remove just to be on the safe side as backward compatibility?
Regards, Daniel
They are exported for sake of the transpiled CL code. We could provide such define though, for instance in legacy.h header, if there might be code using it. I would keep it removed though unless somebody complains, then we will add it back in form of define.
On 01.07.2017 00:11, Fabrizio Fabbri wrote:
Il giorno 29 giu 2017, alle ore 10:25, Daniel Kochmański daniel@turtleware.eu ha scritto:
It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn.
If they do the same then yes, please remove one of them.
I'm not sure if that is an internal or is part of the public interface.
In case of the latter would it make sense to #define the one we are going to remove just to be on the safe side as backward compatibility?
Regards, Daniel