libbb: GETOPT_RESET macro

Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Kaarle Ritvanen
2017-04-12 00:58:46 +03:00
committed by Denys Vlasenko
parent c5496d3585
commit 835ad3a984
6 changed files with 28 additions and 52 deletions

View File

@ -1178,6 +1178,28 @@ extern uint32_t option_mask32;
extern uint32_t getopt32(char **argv, const char *applet_opts, ...) FAST_FUNC;
/* BSD-derived getopt() functions require that optind be set to 1 in
* order to reset getopt() state. This used to be generally accepted
* way of resetting getopt(). However, glibc's getopt()
* has additional getopt() state beyond optind (specifically, glibc
* extensions ('+' and '-' at the start of the string), and requires
* that optind be set to zero to reset its state. BSD-derived versions
* of getopt() misbehaved if optind is set to 0 in order to reset getopt(),
* and glibc's getopt() used to coredump if optind is set 1 in order
* to reset getopt().
* Then BSD introduced additional variable "optreset" which
* be set to 1 in order to reset getopt(). Sigh. Standards, anyone?
*
* By ~2008, OpenBSD 3.4 was changed to survive glibc-like optind = 0
* (to interpret it as if optreset was set).
*/
#ifdef __GLIBC__
#define GETOPT_RESET() (optind = 0)
#else /* BSD style */
#define GETOPT_RESET() (optind = 1)
#endif
/* Having next pointer as a first member allows easy creation
* of "llist-compatible" structs, and using llist_FOO functions
* on them.