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/)




