The default standards-compliance level for the
Compaq/HP compiler defines the assert macro using the
if statement (if...then) rather than the ternary if
expression (?:). As a result, when Python is configured
--with-pydebug (so NDEBUG is not defined), the macro
Py_SAFE_DOWNCAST expands to illegal C (containing a
statement inside an expression).

This can be fixed by asserting the -std switch to the
vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS
indicates that there is no bad side effect to asserting
-std. 

I hope to develop a fix for this in configure.in
sometime in the next couple of days. When I have done
so, I will attach it to this bug.

For the record, here are the variations of the -std
switch on the vendor compiler:

  -std0
      Selects the K & R language mode. This is the
default.  Enforces the K &
      R programming style, with certain ANSI extensions
in areas where the K
      & R behavior is undefined or ambiguous. In
general, -std0 compiles most
      pre-ANSI C programs and produces expected
results.  The -std0 option
      causes the __STDC__ macro to be undefined.


  -std
      Selects the relaxed ANSI language mode. Enforces
the ANSI C standard,
      but allows some common programming practices
disallowed by the stan-
      dard.

      This option does not restrict the Tru64 UNIX name
space (for example,
      the names defined in system header files).  To
restrict that name space
      so that only ANSI C reserved names are visible
from the ANSI C header
      files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.

      This option causes the macro __STDC_ to be
defined to 0.

  -std1
      Selects the strict ANSI language mode. Strictly
enforces the ANSI C
      standard and all its prohibitions (such as those
that apply to the han-
      dling of void types, the definition of lvalues in
expressions, the mix-
      ing of integrals and pointers, and the
modification of rvalues).

      This option does not restrict the Tru64 UNIX name
space (for example,
      the names defined in system header files).  To
restrict that name space
      so that only ANSI C reserved names are visible
from the ANSI C header
      files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.

      This option causes the macro __STDC_ to be
defined to 1. Note that this
      option also affects linker-defined symbols.  See
ld(1) for more infor-
      mation.

      This option turns on ANSI aliasing rules
(-ansi_alias option).

Logged In: YES 
user_id=246063

Attached to this bug is a patch to configure.in and configure. I
believe pretty much all of the three decisions I made need
review :)

1. I put the -std flag in BASECFLAGS an OSF1-specific case
in the
non-gcc branch. Should there be some other check here that
we're using
the vendor C compiler? If so, can anyone point me at an example?

2. Upon testing, I found that the getpgrp function has a
different
signature when compiled with -std than without. As a result, the
posixmodule didn't build. My solution was to change the
definition of
CC in configure.in to be "$CC $BASECFLAGS $OPT" after the
last change
to OPT and BASECFLAGS. My thinking is that we ought to be
running
feature and behavior tests with the flags that we'll be
using to build
the interpreter. However, if this goes against the spirit or
policy of
autoconf, we should do something else!

3. I happened to notice an XXX about Monterey, so I did a little
investigation and added to the note. Hopefully this is not a
gaffe.

I have tested the changes to configure.in on Tru64 4.0F both
with and
without the --with-pydebug flag to configure. The test suite
behaved
the same in each case as before my mods.

I also tested the changes --with-pydebug on a Red Hat 7
system; they
seemed good there too.

If I should have put this patch in the Patch Manager rather than
attaching to the bug directly, I apologize and promise never
to do it
wrongly again :)

Please let me know by posting a followup here or via email
if there is
anything else I should do for this bug. 

Logged In: YES 
user_id=33168

This problem has a tentative solution.  Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line.  Thanks.

Logged In: YES 
user_id=33168

Checked in as:
 * configure 1.402
 * configure.in 1.413

Please test the current CVS.  It was a little different from
the patch here.  I think it should work though.

Logged In: YES 
user_id=246063

I'll try the fix tomorrow when I am at work and have access to a Tru64 
machine.

Logged In: YES 
user_id=246063

The good news is that unicodeobject.c now builds properly,
because of the -std flag to the compiler.

Unfortunately, there is still a problem with
getpgrp/setpgrp. Here is the error:

cc: Error: ./Modules/posixmodule.c, line 2730: In this
statement, "getpgrp" expects 0 arguments, but 1 are
supplied. (toomanyargs)
        return PyInt_FromLong((long)getpgrp(0));
------------------------------------^

This is problem (2) from my followup of 2-27-2003. The
apparent problem is that HP's Tru64 compiler gives a
different signature to getpgrp depending on whether or not
-std is asserted; when the test for what signature is
expected is done without -std, but the actual build of
posixmodule is done with -std, then there is a mismatch.
What I had suggested before was changing the compiler used
for subsequent tests to include all the flags that we had
discovered were needed, so that tests were done with the
same flags that would be used during build. If this is too
radical, perhaps just the test for getpgrp's signature could
use this technique?