[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

--- Comment #7 from Markus Elfring  ---
(In reply to Philip Hazel from comment #6)
> Old habits die hard!

How much does the use of enumerations belong to good development practices when
they are directly supported also by the C programming language for a while?


> It is indeed too late

I hope that more occasions will appear to improve the corresponding software
situation a bit more.


> Without changing pcre2_config() etc. there is no point in changing
> the #defines to an enum.

I have got an other view about this implementation detail.
Does anybody insist to use the affected symbols still as preprocessor macros?


> I am going to close this issue "wontfix",

Would an other tag be more appropriate?


> but I have noted the issue on the long-term wish-list so that it
> won't be entirely forgotten if there ever is another API/ABI break.

I am curious on how this application programming interface will evolve further.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

Philip Hazel  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #6 from Philip Hazel  ---
(In reply to Giuseppe D'Angelo from comment #4)
> 
> The right way to do this is using enums:
> 
> enum pcre2_config_what { pcre2_config_this, pcre2_config_that };
> int pcre2_config(enum pcre2_config_what, void *where);
> /* now I must pass exactly one of the enumerators or the code doesn't
> compile */

Thank you for the full explanation. The problem is that I am too old. I came to
C from BCPL, and always considered enums to be like BCPL's "manifest" (which is
really like #define) instead of being a special kind of type. Old habits die
hard!

> Of course it's too late to do this now. This is an API and ABI break. Maybe
> for PCRE3? :P

It is indeed too late - and it's been like this in PCRE1 since it was first
released in 1997 without anybody pointing out this issue. No wonder I just
copied it over to PCRE2. Without changing pcre2_config() etc. there is no point
in changing the #defines to an enum. I am going to close this issue "wontfix",
but I have noted the issue on the long-term wish-list so that it won't be
entirely forgotten if there ever is another API/ABI break.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

--- Comment #5 from Markus Elfring  ---
(In reply to Philip Hazel from comment #3)

* How do you think about to move some information from the C preprocessor to
higher level data structures?

* Would you like to provide a few more reusable data types for the users of
your programming interfaces?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

Giuseppe D'Angelo  changed:

   What|Removed |Added

 CC||dange...@gmail.com

--- Comment #4 from Giuseppe D'Angelo  ---
The advantage at using enums rather than #defines is to make it a compile-time
error (warning?) if you pass an invalid value for a given API call.

To elaborate: right now we have

   int pcre2_config(uint32_t what, void *where);

and a bunch of #defines for symbolic constants you can pass to "what". 

The problem is that this is has loose typing, so you can happily pass *any*
integer, in particular integers obtained by using the wrong #define.

/* PCRE2_CASELESS is for pcre2_compile, not for pcre2_config! */
pcre2_config(PCRE2_CASELESS, ...);

What's worse, this may or may not result in a runtime error, depending on
whether you accidentally passed a valid value (albeit obtained through the
wrong define, which should still be reported to the programmer as a potential
problem!).

The right way to do this is using enums:

enum pcre2_config_what { pcre2_config_this, pcre2_config_that };
int pcre2_config(enum pcre2_config_what, void *where);
/* now I must pass exactly one of the enumerators or the code doesn't
compile */

Of course it's too late to do this now. This is an API and ABI break. Maybe for
PCRE3? :P

Last, but not least: unfortunately C has not a type-safe solution for bitmasks.
(C++ has.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

--- Comment #3 from Philip Hazel  ---
Those #defined values appear only in "case" labels in the code. I do not
understand how changing them to enums can help with debugging.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

--- Comment #2 from Markus Elfring  ---
(In reply to Philip Hazel from comment #1)

Can the use of enumerations support better debugging also around your software?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1918] #define ⇒ enum?

[admin]

https://bugs.exim.org/show_bug.cgi?id=1918

--- Comment #1 from Philip Hazel  ---
What is the advantage? The PCRE2_CONFIG and PCRE2_INFO values are not required
to be consecutive numbers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev