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.
  
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

Reply via email to