POSIX API replacement

[rofl0r]

POSIX API disabled by default for Unix (* Enabled by: configure --enable-posix-api=yes)

hello, i assume POSIX API was disabled by default to prevent clashes with libc's regex.h.

now that the posix api switch has been introduced it's possible to encounter installed oniguruma with and without the functionality.

however it would be interesting to use oniguruma over libc's version because according to this benchmark http://lh3lh3.users.sourceforge.net/reb.shtml it is up to 3x faster than GLIB.

therefore i would suggest that whether POSIX API is turned off or not, it should be made available using function names in the oniguruma namespace but with the POSIX signature, e.g.

     int onig_posix_regcomp(onig_regex_t *restrict preg, const char *restrict pattern,
         int cflags);

and likewise for regexec/regfree.

this would allow a package to have a configure test like
checking whether oniguruma has onig_posix_regcomp()... yes and then set a CPP macro like HAVE_ONIG_REGCOMP and then the code could do something like

#if HAVE_ONIG_REGCOMP 
#include <oniguruma.h>
#define regcomp onig_posix_regcomp
#define regex_t onig_regex_t
#else
#include <regex.h>
#endif

and use regcomp and friends in the code without caring whether behind the scene work is done by libc or oniguruma.

[kkos]

That's a good way to do it, so I thought I would.
But I realized that there was a problem.
This breaks binary compatibility with already compiled applications.

[rofl0r]

This breaks binary compatibility with already compiled applications.

are you refering to applications linked to oniguruma but using the (previous) POSIX API?
to keep those working, the symbols regcomp etc need to be available in the dynamic library (assuming the user/distro compiles oniguruma with --enable-posix-api=yes).
but those could be thin wrappers around the onig_ namespaced symbols, e.g.:

#if POSIX_API_ENABLED
int regcomp(regex_t *restrict preg, const char *restrict pattern,
         int cflags) { return onig_posix_regcomp((void*)preg, pattern, cflags); }
...
#endif 

they could even be weak aliases, for that matter.

[kkos]

Added --enable-binary-compatible-posix-api=[yes/no] to configure.

./configure --enable-binary-compatible-posix-api=yes : Binary level compatible POSIX API
./configure --enable-posix-api=yes : Source level compatible POSIX API
./configure : No POSIX API (default)

Sorry, but I don't want to enable the POSIX API by default anymore.

[rofl0r]

that's great, thanks!

are the macros defined here f7ca475#diff-e6b2ff26a208acb48af0b6ffb093e623R176 still needed though? now that the switch --enable-binary-compatible-posix-api=yes provides those as wrappers?

[rofl0r]

are the macros defined here f7ca475#diff-e6b2ff26a208acb48af0b6ffb093e623R176 still needed though? now that the switch --enable-binary-compatible-posix-api=yes provides those as wrappers?

actually, scrap that. the macros you provide are handy and won't cause any issue as long as libc's regex.h isn't included. the only possible issue is that compiling the abi-compat wrapper funcs the macros get expanded (so one would end up with 2 onig_posix_regcomp in the lib), but i suppose you already checked that case.

the only minor issue i see that's still left is regoff_t being int instead of ssize_t, but you're probably aware of the issues it causes ( http://ewontfix.com/9/ ) and it probably can't be changed anyway due to ABI compat.

thanks again!

[kkos]

You're right about regoff_t, it can't be changed.
There will never be two onig_posix_regcomp() etc., because #undef in the beginning of regposix.c.

[spershin]

@kkos
Hi!
Not sure how to contact you in a better way.
I'm having problems with posix symbols - they seem to be missing from the latest Release 6.9.9:
I'm having these errors:

ld.lld: error: undefined symbol: onig_posix_regcomp
ld.lld: error: undefined symbol: onig_posix_regexec
ld.lld: error: undefined symbol: onig_posix_regfree
ld.lld: error: undefined symbol: onig_posix_regerror

Running
nm libonig.a
does now show any posix functions - they are gone.

Can you advice, please, how to go around this?
Do I need to build libraries with some system variables, flags or something?

Any help is appreciated, thanks!

Update 1:
I have added --enable-posix-api=yes to the configure command and trying that. I assume it would work, but haven't got the results yet as our build process is quite lengthy.

[mtasaka]

@spershin You need --enable-binary-compatible-posix-api=yes as written on 6.9.9 README.md:

oniguruma/README.md

Line 33 in e62a8e5

When using configure script, if you have the POSIX API enabled in an earlier version (disabled by default in 6.9.5) and you need application binary compatibility with the POSIX API, specify "--enable-binary-compatible-posix-api=yes" instead of "--enable-posix-api=yes". Starting in 6.9.6, "--enable-posix-api=yes" only supports source-level compatibility for 6.9.5 and earlier about POSIX API. (Issue #210)

[spershin]

@mtasaka

Thank you for pointing this out.
I was able to successfully build and link with just --enable-posix-api=yes flag.
What is exactly "application binary compatibility with the POSIX API"?
Does this mean the unchanged 100% POSIX-compatible behavior or something else?

Asking because with the new library I have one test failing - apparently it was expecting a failure, but now it actually returns a result:

021+ string(10) "string_val"
022- Warning: mbregex compile err: invalid code point value in %s/mb_ereg_replace_variation1.php on line %d
023- bool(false)
024- 

Update:
Apparently 6.5.0 was failing with patterns '\xd7' and '\xf6', but 6.9.9 is failing only with '\xd7'.
Pattern '\xf6' now passes.
Failure message is "too short multibyte code string".