Re: [pcre-dev] size of pcre_uint32 and pcre_int32

Thank you ZoltanThis is good news.  API should be same API for all!
I would recommend (and actually strongly ask) that any exposed API of PCRE (or PCRE2) should always stick with fixed length for integer type variables (i.e. when you say 8, it is absolutely 8, 16 is absolutely 16 and 32 is absolutely 32... and when the time come 64 should be absolutely 64 and 128 absolutely 128).  Note that I emphasized 'exposed' API.  I am much less concerned about internal processing.The reason for that is, as I've explained, that there are languages which might be less flexible than C (such as COBOL) and the size of the variable is etched in stone (err, in the code) and is not a subject for implementation or environment.  When interfacing with such languages, they do not have a clue, and do not care for the environment.  All they want is a deterministic size of the parameter.
My counter example is as mentioned before, the GNU implementation of regex.h that in its zeal to be flexible would cause the structures to be of different characteristics, depending on environment (32 bits OS, 64 bits OS, implementation [how C interpret int vs. long int] and so on) and would not play nice as far as the API is concerned. Ze'ev Atlas

Zoltan wroteyes, pcre_int32 and pcre_uint32 are always 32 bit long. However, there are other types: int_fast32_t / int_least32_t which might be more than 32 bit long and provides faster 32 bit computation. PCRE does not use them (at the moment). 

Ze'ev wrotePCRE in my opinion is well written in that it does not leave too much to chance and the header files explicitly specify types such as pcre_int8, pcre_uint8, etc.  My specific question is about the types pcre_int32 and pcre_uint32.  I looked at the pcre_internal.h and with my less then optimal knowledge of C, I could not determine the answer.  So explicitly, are those types guaranteed to always be 32 bits, no matter what, or could they be 64 bits on some occasions?  I hope that they are 32 bits no matter what.