Guten Tag Thorsten Schöning,
am Freitag, 3. Dezember 2010 um 11:58 schrieben Sie:
> Any ideas on what might be the problem? Do you think of any
> circumstances in which pcre_exec could behave like I tried to
> describe?
Hello,
I finally found the solution: I knew that BCB provides it's own, much
older pcre-library and that it's always present in the main BCB libs,
but I thought that if I add my own library as a lib to the project in
the intended way, BCB handles everything right and my code is used as
needed. The signatures of pcre_exec in the old BCb version and the
newer ones differ, too, and sometimes it did work. But only sometimes
and whenever I get an access violation, BCB linked my code to use the
old pcre_exec-function with the different signature than the new ones.
The old signature is as follows, it has the argument for startpos less
and where the new pcre_exec-version needs to get options, the old one
expects a pointer. That's where my access violation occurs.
int pcre_exec(const pcre *code, "const pcre_extra *extra," "const char *subject," int length, int options, int *ovector, int ovecsize);
vs.
int pcre_exec(const pcre *code, const pcre_extra *extra, const char *subject, int length, int startoffset, int options, int *ovector, int ovecsize);
The only solution I know of is to hard code the own pcre-lib to get
linked before the BCB-own libs and don't use the project management at
least for pcre. pcrecpp is not provided by BCB and therefore can be
added using the project functions.
<ALLLIB value="cg32.lib $(LIBFILES) $(LIBRARIES) import32.lib libpcre.lib cp32mt.lib"/>
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@???
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
