From: Guy Harris Date: Tue, 9 Jan 2018 03:23:28 +0000 (-0800) Subject: Update to reflect the name change for Apple's UNIX-for-Macs. X-Git-Tag: libpcap-1.9-bp~293 X-Git-Url: https://git.tcpdump.org/libpcap/commitdiff_plain/7a04be7771d44a2f7e74210cc39e4df0ccef8d97 Update to reflect the name change for Apple's UNIX-for-Macs. Use "macOS" except when referring to versions that came out when it was still called "Mac OS X" or "OS X". Rename README.macosx to README.macos. Update some comments while we're at it. --- diff --git a/INSTALL.txt b/INSTALL.txt index e48353d2..57828444 100644 --- a/INSTALL.txt +++ b/INSTALL.txt @@ -269,7 +269,7 @@ timestamp resolution if it finds it's running on a SS-1). FILES ----- CHANGES - description of differences between releases -ChmodBPF/* - Mac OS X startup item to set ownership and permissions +ChmodBPF/* - macOS startup item to set ownership and permissions on /dev/bpf* CMakeLists.txt - CMake file CONTRIBUTING - guidelines for contributing @@ -282,7 +282,7 @@ README.aix - notes on using libpcap on AIX README.dag - notes on using libpcap to capture on Endace DAG devices README.hpux - notes on using libpcap on HP-UX README.linux - notes on using libpcap on Linux -README.macosx - notes on using libpcap on Mac OS X +README.macos - notes on using libpcap on macOS README.septel - notes on using libpcap to capture on Intel/Septel devices README.sita - notes on using libpcap to capture on SITA devices README.tru64 - notes on using libpcap on Digital/Tru64 UNIX diff --git a/Makefile.in b/Makefile.in index 88cb1474..c3d2a3bd 100644 --- a/Makefile.in +++ b/Makefile.in @@ -242,7 +242,7 @@ EXTRA_DIST = \ README.dag \ README.hpux \ README.linux \ - README.macosx \ + README.macos \ README.septel \ README.sita \ README.tru64 \ @@ -398,14 +398,12 @@ libpcap.so: $(OBJ) # # The following rule succeeds, but the result is untested. # -# In Mac OS X, the libpcap dylib has the name "libpcap.A.dylib", with -# its full path as the install_name, and with the compatibility and -# current version both set to 1. The compatibility version is set to -# 1 so that programs built with a newer version of the library will run -# against older versions; multi-platform software probably will fail if -# it uses APIs added in the newer version, but Mac OS X-specific software -# will use weak linking and check at run time whether those APIs are -# available. +# In macOS, the libpcap dylib has the name "libpcap.A.dylib", with its +# full path as the install_name, and with the compatibility and current +# version both set to 1. The compatibility version is set to 1 so that +# programs built with a newer version of the library will run against +# older versions if they don't use APIs available in the newer version +# but not in the older version. # # We also use "A" as the major version, and 1 as the compatibility version, # but set the current version to the value in VERSION, with any non-numeric diff --git a/README b/README index 2d10376e..24fdc80d 100644 --- a/README +++ b/README @@ -59,11 +59,11 @@ would translate BPF filters into a filter program that is compatible with the underlying kernel subsystem, but this is not yet implemented. BPF is standard in 4.4BSD, BSD/OS, NetBSD, FreeBSD, OpenBSD, DragonFly -BSD, and Mac OS X; an older, modified and undocumented version is -standard in AIX. {DEC OSF/1, Digital UNIX, Tru64 UNIX} uses the -packetfilter interface but has been extended to accept BPF filters -(which libpcap utilizes). Also, you can add BPF filter support to -Ultrix using the kernel source and/or object patches available in: +BSD, and macOS; an older, modified and undocumented version is standard +in AIX. {DEC OSF/1, Digital UNIX, Tru64 UNIX} uses the packetfilter +interface but has been extended to accept BPF filters (which libpcap +utilizes). Also, you can add BPF filter support to Ultrix using the +kernel source and/or object patches available in: https://www.tcpdump.org/other/bpfext42.tar.Z diff --git a/README.macosx b/README.macos similarity index 86% rename from README.macosx rename to README.macos index 3dc92117..3cceb233 100644 --- a/README.macosx +++ b/README.macos @@ -1,5 +1,5 @@ -As with other systems using BPF, Mac OS X allows users with read access -to the BPF devices to capture packets with libpcap and allows users with +As with other systems using BPF, macOS allows users with read access to +the BPF devices to capture packets with libpcap and allows users with write access to the BPF devices to send packets with libpcap. On some systems that use BPF, the BPF devices live on the root file @@ -12,16 +12,16 @@ can be configured to set the permissions and/or ownership of those devices to give users other than root permission to read or write those devices. -On Mac OS X, the BPF devices live on devfs, but the OS X version of -devfs is based on an older (non-default) FreeBSD devfs, and that version -of devfs cannot be configured to set the permissions and/or ownership of +On macOS, the BPF devices live on devfs, but the macOS version of devfs +is based on an older (non-default) FreeBSD devfs, and that version of +devfs cannot be configured to set the permissions and/or ownership of those devices. Therefore, we supply: - a "startup item" for older versions of Mac OS X; + a "startup item" for older versions of macOS; - a launchd daemon for Tiger and later versions of Mac OS X; + a launchd daemon for Tiger and later versions of macOS; Both of them will change the ownership of the BPF devices so that the "admin" group owns them, and will change the permission of the BPF diff --git a/aclocal.m4 b/aclocal.m4 index 4bfb0942..bf5f26fd 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -431,7 +431,7 @@ AC_DEFUN(AC_LBL_SHLIBS_INIT, # On platforms where we build a shared library: # # add options to generate position-independent code, - # if necessary (it's the default in AIX and Darwin/OS X); + # if necessary (it's the default in AIX and Darwin/macOS); # # define option to set the soname of the shared library, # if the OS supports that; @@ -506,7 +506,7 @@ AC_DEFUN(AC_LBL_SHLIBS_INIT, # where we build a shared library: # # add options to generate position-independent code, - # if necessary (it's the default in Darwin/OS X); + # if necessary (it's the default in Darwin/macOS); # # if we generate ".so" shared libraries, define the # appropriate options for building the shared library; diff --git a/chmod_bpf b/chmod_bpf index 0a30d993..946fec37 100755 --- a/chmod_bpf +++ b/chmod_bpf @@ -1,7 +1,7 @@ #! /bin/sh # -# Unfortunately, Mac OS X's devfs is based on the old FreeBSD +# Unfortunately, macOS's devfs is based on the old FreeBSD # one, not the current one, so there's no way to configure it # to create BPF devices with particular owners or groups. # This startup item will make it owned by the admin group, diff --git a/configure b/configure index 26fbf210..082d4e2b 100755 --- a/configure +++ b/configure @@ -3810,7 +3810,7 @@ $as_echo "#define const /**/" >>confdefs.h # On platforms where we build a shared library: # # add options to generate position-independent code, - # if necessary (it's the default in AIX and Darwin/OS X); + # if necessary (it's the default in AIX and Darwin/macOS); # # define option to set the soname of the shared library, # if the OS supports that; @@ -3885,7 +3885,7 @@ $as_echo "#define const /**/" >>confdefs.h # where we build a shared library: # # add options to generate position-independent code, - # if necessary (it's the default in Darwin/OS X); + # if necessary (it's the default in Darwin/macOS); # # if we generate ".so" shared libraries, define the # appropriate options for building the shared library; diff --git a/fad-getad.c b/fad-getad.c index 75797450..7e936a3f 100644 --- a/fad-getad.c +++ b/fad-getad.c @@ -232,7 +232,7 @@ pcap_findalldevs_interfaces(pcap_if_list_t *devlistp, char *errbuf, /* * Note that, on some platforms, ifa_broadaddr and * ifa_dstaddr could be the same field (true on at - * least some versions of *BSD and OS X), so we + * least some versions of *BSD and macOS), so we * can't just check whether the broadcast address * is null and add it if so and check whether the * destination address is null and add it if so. diff --git a/gencode.c b/gencode.c index 8444472d..645d162c 100644 --- a/gencode.c +++ b/gencode.c @@ -3018,7 +3018,7 @@ gen_prevlinkhdr_check(compiler_state_t *cstate) */ #define BSD_AFNUM_INET6_BSD 24 /* NetBSD, OpenBSD, BSD/OS, Npcap */ #define BSD_AFNUM_INET6_FREEBSD 28 /* FreeBSD */ -#define BSD_AFNUM_INET6_DARWIN 30 /* OS X, iOS, other Darwin-based OSes */ +#define BSD_AFNUM_INET6_DARWIN 30 /* macOS, iOS, other Darwin-based OSes */ /* * Generate code to match a particular packet type by matching the diff --git a/pcap-bpf.c b/pcap-bpf.c index fcfc4e24..bb2cbd15 100644 --- a/pcap-bpf.c +++ b/pcap-bpf.c @@ -30,7 +30,7 @@ * defines ioctls, but doesn't include . * * We include as it might be necessary to declare ioctl(); - * at least on *BSD and Mac OS X, it also defines various SIOC ioctls - + * at least on *BSD and macOS, it also defines various SIOC ioctls - * we could include , but if we're already including * , which includes on those platforms, * there's not much point in doing so. @@ -227,8 +227,9 @@ static void remove_802_11(pcap_t *); #endif /* - * On OS X, we don't even get any of the 802.11-plus-radio-header DLT_'s - * defined, even though some of them are used by various Airport drivers. + * In some versions of macOS, we might not even get any of the + * 802.11-plus-radio-header DLT_'s defined, even though some + * of them are used by various Airport drivers in those versions. */ #ifndef DLT_PRISM_HEADER #define DLT_PRISM_HEADER 119 @@ -748,7 +749,7 @@ pcap_can_set_rfmon_bpf(pcap_t *p) #endif /* - * The joys of monitor mode on OS X. + * The joys of monitor mode on Mac OS X/OS X/macOS. * * Prior to 10.4, it's not supported at all. * @@ -1194,13 +1195,13 @@ pcap_inject_bpf(pcap_t *p, const void *buf, size_t size) #ifdef __APPLE__ if (ret == -1 && errno == EAFNOSUPPORT) { /* - * In Mac OS X, there's a bug wherein setting the - * BIOCSHDRCMPLT flag causes writes to fail; see, - * for example: + * In some versions of macOS, there's a bug wherein setting + * the BIOCSHDRCMPLT flag causes writes to fail; see, for + * example: * * http://cerberus.sourcefire.com/~jeff/archives/patches/macosx/BIOCSHDRCMPLT-10.3.3.patch * - * So, if, on OS X, we get EAFNOSUPPORT from the write, we + * So, if, on macOS, we get EAFNOSUPPORT from the write, we * assume it's due to that bug, and turn off that flag * and try again. If we succeed, it either means that * somebody applied the fix from that URL, or other patches @@ -1209,7 +1210,7 @@ pcap_inject_bpf(pcap_t *p, const void *buf, size_t size) * http://cerberus.sourcefire.com/~jeff/archives/patches/macosx/ * * and are running a Darwin kernel with those fixes, or - * that Apple fixed the problem in some OS X release. + * that Apple fixed the problem in some macOS release. */ u_int spoof_eth_src = 0; diff --git a/pcap-common.c b/pcap-common.c index 6f5d44ae..316c8c3f 100644 --- a/pcap-common.c +++ b/pcap-common.c @@ -875,7 +875,7 @@ /* * pfsync output; DLT_PFSYNC is 18, which collides with DLT_CIP in - * SuSE 6.3, on OpenBSD, NetBSD, DragonFly BSD, and Mac OS X, and + * SuSE 6.3, on OpenBSD, NetBSD, DragonFly BSD, and macOS, and * is 121, which collides with DLT_HHDLC, in FreeBSD. We pick a * shiny new link-layer header type value that doesn't collide with * anything, in the hopes that future pfsync savefiles, if any, @@ -972,7 +972,7 @@ * So I'll just give them one; hopefully this will show up in a * libpcap release in time for them to get this into 10.10 Big Sur * or whatever Mavericks' successor is called. LINKTYPE_PKTAP - * will be 258 *even on OS X*; that is *intentional*, so that + * will be 258 *even on macOS*; that is *intentional*, so that * PKTAP files look the same on *all* OSes (different OSes can have * different numerical values for a given DLT_, but *MUST NOT* have * different values for what goes in a file, as files can be moved diff --git a/pcap.3pcap.in b/pcap.3pcap.in index 4cc0530d..29d12872 100644 --- a/pcap.3pcap.in +++ b/pcap.3pcap.in @@ -283,13 +283,13 @@ packet capture on an interface probably requires that either promiscuous-mode or copy-all-mode operation, or both modes of operation, be enabled on that interface. .TP -.B Under BSD (this includes Mac OS X): +.B Under BSD (this includes macOS): You must have read access to .I /dev/bpf* on systems that don't have a cloning BPF device, or to .I /dev/bpf on systems that do. -On BSDs with a devfs (this includes Mac OS X), this might involve more +On BSDs with a devfs (this includes macOS), this might involve more than just having somebody with super-user access setting the ownership or permissions on the BPF devices - it might involve configuring devfs to set the ownership or permissions every time the system is booted, diff --git a/pcap.c b/pcap.c index 663729bd..ba2b37fc 100644 --- a/pcap.c +++ b/pcap.c @@ -586,7 +586,7 @@ get_figure_of_merit(pcap_if_t *dev) * description available, it still might be nice to get some description * string based on the device type or something such as that. * - * In OS X, the System Configuration framework can apparently return + * In macOS, the System Configuration framework can apparently return * names in 10.4 and later. * * It also appears that freedesktop.org's HAL offers an "info.product" diff --git a/pcap/dlt.h b/pcap/dlt.h index 609bcaf9..979293d2 100644 --- a/pcap/dlt.h +++ b/pcap/dlt.h @@ -120,9 +120,9 @@ /* * 18 is used for DLT_PFSYNC in OpenBSD, NetBSD, DragonFly BSD and - * Mac OS X; don't use it for anything else. (FreeBSD uses 121, - * which collides with DLT_HHDLC, even though it doesn't use 18 - * for anything and doesn't appear to have ever used it for anything.) + * macOS; don't use it for anything else. (FreeBSD uses 121, which + * collides with DLT_HHDLC, even though it doesn't use 18 for + * anything and doesn't appear to have ever used it for anything.) * * We define it as 18 on those platforms; it is, unfortunately, used * for DLT_CIP in Suse 6.3, so we don't define it as DLT_PFSYNC @@ -340,7 +340,7 @@ * * FreeBSD's libpcap won't map a link-layer header type of 18 - i.e., * DLT_PFSYNC files from OpenBSD and possibly older versions of NetBSD, - * DragonFly BSD, and OS X - to DLT_PFSYNC, so code built with FreeBSD's + * DragonFly BSD, and macOS - to DLT_PFSYNC, so code built with FreeBSD's * libpcap won't treat those files as DLT_PFSYNC files. * * Other libpcaps won't map a link-layer header type of 121 to DLT_PFSYNC; @@ -1229,7 +1229,7 @@ * So I'll just give them one; hopefully this will show up in a * libpcap release in time for them to get this into 10.10 Big Sur * or whatever Mavericks' successor is called. LINKTYPE_PKTAP - * will be 258 *even on OS X*; that is *intentional*, so that + * will be 258 *even on macOS*; that is *intentional*, so that * PKTAP files look the same on *all* OSes (different OSes can have * different numerical values for a given DLT_, but *MUST NOT* have * different values for what goes in a file, as files can be moved @@ -1241,9 +1241,9 @@ * and that will continue to be DLT_USER2 on Darwin-based OSes. That way, * binary compatibility with Mavericks is preserved for programs using * this version of libpcap. This does mean that if you were using - * DLT_USER2 for some capture device on OS X, you can't do so with + * DLT_USER2 for some capture device on macOS, you can't do so with * this version of libpcap, just as you can't with Apple's libpcap - - * on OS X, they define DLT_PKTAP to be DLT_USER2, so programs won't + * on macOS, they define DLT_PKTAP to be DLT_USER2, so programs won't * be able to distinguish between PKTAP and whatever you were using * DLT_USER2 for. * diff --git a/tests/valgrindtest.c b/tests/valgrindtest.c index f620e739..c2e3d790 100644 --- a/tests/valgrindtest.c +++ b/tests/valgrindtest.c @@ -35,14 +35,14 @@ * * https://bugs.kde.org/show_bug.cgi?id=318203 * - * and valgrind bug 312989 for OS X: + * and valgrind bug 312989 for macOS: * * https://bugs.kde.org/show_bug.cgi?id=312989 * * The fixes for both of those are checked into the official valgrind * repository. * - * The unofficial FreeBSD port has similar issues to the official OS X + * The unofficial FreeBSD port has similar issues to the official macOS * port, for similar reasons. */ #ifndef lint