Hi Mark,
Thank you for your reply.
It seems to me that it's better to implement own strtok_s for MS VC
2003 in order not to change library sources and don't assume that library
will not rely on stored states.
Pavel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Crispin
Sent: Friday, April 06, 2007 1:43 PM
To: Pavel Zakharov
Cc: [email protected]
Subject: Re: [Imap-uw] MS Visual Studio 2003 compilation problems
On Fri, 6 Apr 2007, Pavel Zakharov wrote:
> Whenever you try to build latest version of IMAP library using MS Visual
> Studio 2003 you get problems with latest changes. 'strtok' changed to
> 'strtok_r' which doesn't exist in VS 2003. in VS 2005 strtok_s appeared,
> which is the same as strtok_r. Do IMAP still support VS 2003?
In general, we do NOT support older versions of Microsoft Visual Studio.
It isn't so much a compiler or C library issue (although it is in this
case) as it is the Platform SDK. The Platform SDK changes frequently, and
often newer versions of Windows require using definitions from newer
versions of the Platform SDK (it is possible to download the newest
Platform SDK from Microsoft's web site for free).
Put another way, if you use an older version of VS and it builds OK, good
for you; but if it doesn't build, the answer will be "upgrade your version
of VS".
> On win32 if
> multithreaded version of C library used it is thread safe and usage of
> strtok should be enough.
Yes, Microsoft did the intelligent thing; they made functions such as
strtok() be thread-safe by maintaining per-thread strtok() state.
Unfortunately, the developers of the GNU C library did not. This software
is compiled far more frequently by the GNU C compiler than by Microsoft
Visual Studio; and after many years I was finally forced to conceed that
the GNU C library developers will never see change this.
Even without the threading issue, there is always the possibility that
some application may use strtok() in the main program level and expect the
strtok() state to remain unmolested across c-client calls.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
