Re: [pcre-dev] Unknown C construct

Góra strony
Delete this message
Autor: ph10
Data:  
Dla: Ze'ev Atlas
CC: Pcre-dev
Temat: Re: [pcre-dev] Unknown C construct
On Sun, 16 Sep 2018, Ze'ev Atlas via Pcre-dev wrote:

> This is NOT a bug per se, but my C compiler does not really recognize this construct


> <snip>


What you have quoted is from pcre2.h.in, which gets transformed by
"configure" or CMake into pcre2.h.

> my compiler will recognize that  PCRE2_HAVE_STDINT_H is defined but I
> do not know about any way to set the value to zero or one.  Remember
> that I do not have any MAKE, CMAKE etc. on the classic z/OS.


How did you manage with the other settings in the past? There have
always been

#define PCRE2_MAJOR           @PCRE2_MAJOR@
#define PCRE2_MINOR           @PCRE2_MINOR@
#define PCRE2_PRERELEASE      @PCRE2_PRERELEASE@
#define PCRE2_DATE            @PCRE2_DATE@


at the start of pcre2.h.in.

> I could set macros and compile options outside the source code (the
> equivalent of Dmacroname or Umacroname and compiler options).  But the
> construct


> #define macroname   @externalvalue@is not part of it


> I could manually remove these lines from pcre2.h and set the values externally but there should be a better way.  The IBM C compiler does adhere with the latest concept so there should be an equivalent.In short, when you accommodated systems without stdint.h or inttypes.h (I have both,) you have created a problem for systems without CMake!


But this is not a new problem, as I've pointed out above. However, I can
see that previously using pcre2.h.generic would have worked, but now it
does contain

#define PCRE2_HAVE_STDINT_H 1
#define PCRE2_HAVE_INTTYPES_H 1

that is, it assumes the presence of those headers. This change was made
at a user's request in order to make life easier for ancient or
non-standard environments. Standard environments should have stdint.h,
so perhaps just using pcre2.h.generic is the answer.

Philip

--
Philip Hazel