[Guy Harris <guy@xxxxxxxxxx>]

> On my Debian Linux system, in order for <time.h> to define
> strptime(), one has to define _XOPEN_SOURCE.

The joys of namespace pollution; I guess the theory is that an
applicatin that defines its own function that happens to be named
"strptime()" shouldn't be rudely surprised by having it declared
differently in <time.h>.

"epan/ftypes/ftype-time.c" defines __USE_XOPEN instead; I don't know
what the "right" #define is.  There might be some information at

	http://www.unix-systems.org/

(an Open Group site, including various UNIX specs), and the page at

	http://sources.redhat.com/ml/glibc-linux/1999-q3/msg00006.html

is part of a thread that appears to be discussing _GNU_SOURCE vs.
_XOPEN_SOURCE vs. __USE_UNIX98.  However, a Google search for

	__USE_UNIX98 -glibc -linux -gnu -"red hat" -debian

finds very little, which suggests to me that it might be a glibc-ism.

_GNU_SOURCE is presumably a glibc-ism/GNUism, from the name.

Searching for

	__USE_XOPEN -glibc -linux -gnu -"red hat" -debian -suse -redhat

doesn't find a lot - 22 or so items - so I wouldn't be surprised if
__USE_XOPEN weren't also a glibc-ism.

The Solaris 8 <time.h> file declares "strptime()" if

#if (__STDC__ == 0 && !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || \
        (defined(_XOPEN_SOURCE) && _XOPEN_VERSION - 0 >= 4) || \
        defined(__EXTENSIONS__)

which I read as implying that, among other things, defining
_XOPEN_SOURCE might be the right answer.  (At least with Sun's C
compiler, __STDC__ is, as I remember, defined as 0 if the compiler is
told to compile "ANSI C plus extensions that might pollute the namespace
and thus cause some ANSI C programs not to compile".)

However, the messages at

	http://mail-index.netbsd.org/tech-toolchain/1998/02/15/0000.html

and

	http://mail-index.netbsd.org/tech-toolchain/1998/02/15/0001.html

suggest that, on some platforms, defining _XOPEN_SOURCE *prevents* some
things from being declared; I have the impression that at least some of
those macros are intended to mean "if this is defined, do *NOT* pollute
the name space with stuff not in thus-and-such a standard" rather than
"pollute the name space with stuff not in thus-and-stuch a standard only
if this is defined".

Then again, the page at

	http://www.opengroup.org/onlinepubs/7908799/xns/compilation.html

says

	Applications should ensure that the feature test macro
	_XOPEN_SOURCE is defined with the value 500 before inclusion of
	any header.  This is needed to enable the functionality
	described in this document, and possibly to enable functionality
	defined elsewhere in the Common Applications Environment.

which indicates that it *enables* features.

The problem may be that it's supposed to both enable *and* disable stuff
- enable stuff in the Single UNIX Specification but not in pre-Austin
Group POSIX specs or the ANSI C standard, and *DISABLE* stuff that's not
in the Single UNIX Specification, so you have an environment that has
all names defined in the SUS but no names not defined there.  The page
at

	http://www.opengroup.org/onlinepubs/7908799/xns/namespace.html

suggests so:

	When _XOPEN_SOURCE is defined, each header defines or declares
	some identifiers, potentially conflicting with identifiers used
	by the application.  The set of identifiers visible to the
	application consists of precisely those identifiers from the
				^^^^^^^^^
	header pages of the included headers, as well as additional
	identifiers reserved for the implementation.  In addition, some
	headers may make visible identifiers from other headers as
	indicated on the relevant header pages.

where "precisely" may mean "has everything in the headers, plus
reserved identifiers, but *nothing else*".

For now, I'd be inclined to, in all Ethereal source files that use
"strptime()", if _XOPEN_SOURCE isn't defined, define it as 500; the
files in question include "epan/ftypes/ftype-time.c" and "text2pcap.c".