tokenizer.c crashes in 2.1b1

[Alex Martelli]

"Owen F. Ransen" <ransen_spam_me_not at nemo.it> wrote in message
news:3aa5d493.5922346 at news.newsguy.com...
> On 06 Mar 2001 12:54:06 -0800, Ben Hutchings
> <ben.hutchings at roundpoint.com> wrote:
>
> >> The debugger points to the guilty party:
> >> tokenizer.c, the fgets call at line 247 fails.
> >> My VC project uses Multithreaded Debug compiler settings,
> >> as does the Pythoncore project.
    [snip]
> Debug Multithreaded in my MFC app make settings
> Debug Multithreaded DLL in the Pythoncore DLL make settings
>
> Is this wrong?

Yes: VC++ puts strong constraints on the way you can
build modules (EXE's and DLL's) which you want to
interoperate "normally" (via the linker and loader).

In particular, they must use IDENTICAL settings for
the "Project/Settings.../C/C++/Code Generation/Use
run-time library" dropdown.  Otherwise, you'll run
into frequent, deep trouble -- different instances
of the C/C++ runtime libraries will be working at
the same time (it's technically possible to survive
that, if it never happens that something is allocated
by one module and freed by the other, no I/O happens
on the same file from both modules, etc, etc, but in
practice that is out of your control [particularly if
constructors/destructors, etc, enter the picture], so,
think of it as an amusing oddity if and when two
modules with mismatched runtime libraries happen
to work without crashing, and NEVER rely on it!-).

[As an aside, that's part of what's so USEFUL about
COM -- among other things, it freeds you from all
such constraints -- COM-interoperating modules may be
built any which way, including in completely different
languages/compiler releases/runtime library settings/
etc, because COM specifies exactly what's to happen
on the interface between them, _at a binary level_;
these COM constraints *on the language implementors*
turn into freedom *for the application programmers*!-)]


Alex