wasm-demo/demo/ermis-f/python_m/cur/0061

54 lines
2.0 KiB
Plaintext

From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Sat, 10 Apr 1999 00:07:16 -0400
Subject: Possible problem with timemodule.c [1.5.2c1]
In-Reply-To: Your message of "Fri, 09 Apr 1999 21:40:18 EDT."
<199904100140.VAA11860@python.org>
References: <199904100140.VAA11860@python.org>
Message-ID: <199904100407.AAA02004@eric.cnri.reston.va.us>
Content-Length: 1567
X-UID: 61
[Andy Dustman wrote]
> [I decided not to bug Guido directly with this...]
Hehe, I scan the newsgroup digests for the string "1.5.2" so I found
your post anyway :-)
> My compile is completely clean except for Modules/timemodule.c:
>
> ./timemodule.c: In function `time_strptime':
> ./timemodule.c:429: warning: assignment makes pointer from integer without
> a cast
>
> This is in time_strptime(), naturally. The code immediately before this
> is:
>
> #ifdef HAVE_STRPTIME
> /* extern char *strptime(); /* Enable this if it's not declared in <time.h> */
>
> On Linux, strptime() IS declared in <time.h>. However, I find nothing in
> timemodule.c that would cause <time.h> to be included for Linux. configure
> does find strptime and does cause HAVE_STRPTIME to be defined in config.h.
Rest assured, <time.h> is included, indirectly, by mytime.h or myselect.h.
> This is unlikely to be a "showstopper", but I thought I would point it
> out. This may simply be a Linux (RedHat 5.2) problem. The more I look at
> <time.h>, the more I lean towards thie conclusion. The prototype for
> strptime() is not defined unless __USE_XOPEN is defined. The solution,
> however, is not obvious.
This analysis sounds right to me. (Can't test it -- the only Linux
box we have here on the network was powered down because it was
overheating. Too much press attention for Open Source I guess :-)
Perhaps __USE_XOPEN could be defined somewhere by the configure
script? Anybody suggest a good spot to do this?
--Guido van Rossum (home page: http://www.python.org/~guido/)