argpar.{c,h}: fix clang-tidy issues

Fix these issues:

    /home/smarchi/src/argpar/argpar/argpar.h:344:9: warning: macro argument should be enclosed in parentheses [bugprone-macro-parentheses]
      344 |         _item = NULL;                                                                              \
          |         ^
          |         (    )
    argpar.c:525:34: warning: 'iter->tmp_buf.data' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
      525 |             iter->tmp_buf.data = ARGPAR_REALLOC(iter->tmp_buf.data, char, iter->tmp_buf.size);
          |             ~~~~~~~~~~~~~~~~~~   ^
    argpar.c:15:56: note: expanded from macro 'ARGPAR_REALLOC'
       15 | #define ARGPAR_REALLOC(_ptr, _type, _nmemb) ((_type *) realloc(_ptr, (_nmemb) * sizeof(_type)))
          |                                                        ^       ~~~~

Change-Id: I2e42059f8c4c744e10bdbc7c78b2628a53cd60d7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Add clang-tidy configuration file

Copied from:

  https://git.lttng.org/?p=lttng-tools.git;a=blob;f=.clang-tidy;h=75f559c5d961041df8e37280ef27cb0cac8cdd96;hb=20c4b46aee1a984bc558b483826c1078f24d35e9

Then adapted to the project:

 - Remove `HeaderFilterRegex`
 - Put `ARGPAR_ASSERT` for the `AssertMacros` option
 - Remove `CharTypdefsToIgnore` option
 - Fix a . -> , typo

Change-Id: I275b7fa7fbfa324ca8d948712b12d46eb885ab57
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

configure.ac: call `AC_USE_SYSTEM_EXTENSIONS` earlier

When bootstrapping, with autoconf 2.72, I see:

    autoreconf: running: /usr/bin/autoconf
    configure.ac:7: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
    m4/ac_extensions.m4:38: AC_USE_SYSTEM_EXTENSIONS is expanded from...
    configure.ac:7: the top level

Move the call to `AC_USE_SYSTEM_EXTENSIONS` earlier to avoid that.

Change-Id: I836889d9816708530ddbd7c66d8e2c331eadbead
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Add clang-format config file and re-format with clang-format 15

Add a clang-format config file, copied from:

  http://git.efficios.com/?p=babeltrace.git;a=blob;f=.clang-format;h=cba562531157c82aefa5a16f861ef044fa5388e0;hb=a165a5742a2b173e59900e515caa3b37a0afb42f

Adjust it slightly to remove the things that are only relevant in the
context of babeltrace.

Re-format all C files with clang-format 15.

Change-Id: If80c93c139d08fafaf11a8fd8dbca23fb80d4aca
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

argpar.{c,h}: remove `ARGPAR_HIDDEN` from header file

The `ARGPAR_HIDDEN` macro confuses clang-format, and it gives an ugly
result.  Remove it from the header file, it's not useful to have it
exposed anyway.

Change-Id: I7a307144017416fe890d6546eaa61890e0ce217e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

argpar.c: remove stdarg.h include

It is unused.

Change-Id: I266627df766df2cdd51cfd811d57172520f9efc1
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

argpar.c: keep comments within 72 columns

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I4bec9bcad867f7f180dbd5b6b69ed246caa8c49d

tests/test-argpar.c: use fancy bullet points in comments

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7ca5c168822b8fc57769d485f3f5da710387c31d

Add and use type definitions for structures and enumerations

Using the `_t` suffix to avoid changing the current API because `enum
argpar_item_type` has the same name as the argpar_item_type() function.

Using those new type definitions everywhere to make sure they work.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I87bcd2abd40ff91779b9c82b4b9b8a7afb535fb3

argpar.h: make all the functions `noexcept` with C++ ≥ 11

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Id32f6ac1b75fdea7c408a40438577608df48b782

argpar.h: doc: match the style of `README.adoc`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iec00597db1f2f90d13ac2bbe7611d1969e588104

Add long-awaited README

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Idac05a5c1eabaee8c767c8e540a44455e5845dcd

tests: rename `test_argpar.c` -> `test-argpar.c`

Follows the convention of other EfficiOS projects (well of Babeltrace 2
at least, which I also maintain as of this date).

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib25f6e08f728969d7d6a2a9d81d1328c7d503638

Add `extern "C"` to header

Add the necessary declaration to make it possible to use argpar from a
C++ program.

Change-Id: Ifedffb8c636ab9878e7ef6836ce096c1636257e7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Force usage of ARGPAR_ASSERT() condition when NDEBUG is defined

This preventive fix is added to prevent future `-Wunused` warnings in
`assert()` statement when building with NDEBUG defined. There are
currently no such warning in the argpar project but there used to be
one. Because the LTTng-Tools project currently (commit 4f002736e) uses
an older argpar version I am seeing this warning:
  argpar.c: In function ‘argpar_vasprintf’:
  argpar.c:63:12: error: variable ‘len2’ set but not used [-Werror=unused-but-set-variable]
     63 |  int len1, len2;

Reuse the BT2 approach to force the usage of the assertion condition
even when assert() are removed by the NDEBUG define.

See `BT_USE_EXPR()` macro and documentation in Babeltrace commit[0]:
  commit 1778c2a4134647150b199b2b57130817144446b0
  Author: Philippe Proulx <eeppeliteloop@gmail.com>
  Date:   Tue Apr 21 11:15:42 2020 -0400
  lib: assign a unique ID to each pre/postcond. and report it on failure

0: https://github.com/efficios/babeltrace/commit/1778c2a4134647150b199b2b57130817144446b0

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Id71f1f67013cfcf4799ef95a6830babb2dcea973

argpar/argpar.h: update API documentation

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5f218f4028118945dc89956d9a37680326d2db15

Encode error type in argpar_error

With the current API, when encountering an argument parsing error, the
error type (unknown option, missing option argument, unexpected option
argument) is encoded in the returned argpar_iter_next_status value.
In my experience it would be more useful if that information was encoded
in the argpar_error instead.

Imagine a helper function `format_arg_error` that formats an argument
parsing error based on a particular project's needs.  That function
needs to take the argpar_iter_next_status along with the argpar_error:

    char *format_arg_error(enum argpar_iter_next_status status,
    const struct argpar_error *error);

It would be simpler to have the argpar_error object know what type of
error was returned.  That makes the argpar_error contain all the
necessary information about the error.

So, the proposed changes are:

 - Replace ARGPAR_ITER_NEXT_STATUS_ERROR_* with a single
   ARGPAR_ITER_NEXT_STATUS_ERROR, indicating that an argument parsing
   error happened.
 - Add a new `enum argpar_error_type` type, to represent the 3 argument
   parsing error types.
 - Add a new `type` property to argpar_error, obtained through
   `argpar_error_get_type`.

Note that the argpar_error out parameter of the argpar_iter_next
function is optional.  This means that the user can currently receive an
error status (ARGPAR_ITER_NEXT_STATUS_ERROR_{UNKNOWN_OPT,
UNEXPECTED_OPT_ARG,MISSING_OP_ARG}) but not have any more details about
the error.  I don't think this is really useful, because the user of the
API wouldn't be able to do make a useful error message by knowing the
type of error but not having the corresponding argpar_error object.

API documentation left to Philippe Proulx.

Change-Id: Ice4db8852030ccd3ba9cbdf3717d9850b8ee7935

Remove unused ARGPAR_PRINTF_FORMAT macro

Change-Id: I1072360cc3f806fc8a46904d4cf1aa4263939c0f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Fix unknown option name length computation in set_error

When running the tests with AddressSanitizer enabled, we get:

    ==279682==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000001891 at pc 0x7fefdfa7ae6f bp 0x7ffd66b45560 sp 0x7ffd66b44d08
    WRITE of size 2 at 0x602000001891 thread T0
#0 0x7fefdfa7ae6e in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x55e7163783d8 in set_error (/home/simark/build/argpar/tests/test_argpar+0xe3d8)
#2 0x55e716378d66 in parse_short_opt_group (/home/simark/build/argpar/tests/test_argpar+0xed66)
#3 0x55e71637981c in parse_orig_arg_opt (/home/simark/build/argpar/tests/test_argpar+0xf81c)
#4 0x55e716379eb1 in argpar_iter_next (/home/simark/build/argpar/tests/test_argpar+0xfeb1)
#5 0x55e716374065 in test_fail (/home/simark/build/argpar/tests/test_argpar+0xa065)
#6 0x55e716374c13 in fail_tests (/home/simark/build/argpar/tests/test_argpar+0xac13)
#7 0x55e71637644d in main (/home/simark/build/argpar/tests/test_argpar+0xc44d)
#8 0x7fefdf767b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#9 0x55e71636f3ad in _start (/home/simark/build/argpar/tests/test_argpar+0x53ad)

    0x602000001891 is located 0 bytes to the right of 1-byte region [0x602000001890,0x602000001891)
    allocated by thread T0 here:
#0 0x7fefdfaf8459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x55e716378311 in set_error (/home/simark/build/argpar/tests/test_argpar+0xe311)
#2 0x55e716378d66 in parse_short_opt_group (/home/simark/build/argpar/tests/test_argpar+0xed66)
#3 0x55e71637981c in parse_orig_arg_opt (/home/simark/build/argpar/tests/test_argpar+0xf81c)
#4 0x55e716379eb1 in argpar_iter_next (/home/simark/build/argpar/tests/test_argpar+0xfeb1)
#5 0x55e716374065 in test_fail (/home/simark/build/argpar/tests/test_argpar+0xa065)
#6 0x55e716374c13 in fail_tests (/home/simark/build/argpar/tests/test_argpar+0xac13)
#7 0x55e71637644d in main (/home/simark/build/argpar/tests/test_argpar+0xc44d)
#8 0x7fefdf767b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)

This is due to an operator precedence mistake in the modified
expression.

    (gdb) p unknown_opt_name
    $2 = 0x7fffffffd870 "e"
    (gdb) p strlen(unknown_opt_name) + 1 + is_short ? 1 : 2
    $3 = 1

The addition is evaluated before the ternary operator, so we end up
choosing between values 1 and 2.  And we always choose 1, because the
result of the addition is always non-zero.

The intent is in fact to add 1 or 2 to `strlen(unknown_opt_name) + 1`,
depending on whether the short option is used.  Add parenthesis around
the ternary to fix it.

Note that clang is cool enough to provide a diagnostic about this:

    /home/simark/src/argpar/argpar/argpar.c:291:44: error: operator '?:' has lower precedence than '+'; '+' will be evaluated first [-Werror,-Wparentheses]
    strlen(unknown_opt_name) + 1 + is_short ? 1 : 2);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
    /home/simark/src/argpar/argpar/argpar.c:21:21: note: expanded from macro 'ARGPAR_CALLOC'
    ((_type *) calloc((_nmemb), sizeof(_type)))
       ^~~~~~
    /home/simark/src/argpar/argpar/argpar.c:291:44: note: place parentheses around the '+' expression to silence this warning
    strlen(unknown_opt_name) + 1 + is_short ? 1 : 2);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
    /home/simark/src/argpar/argpar/argpar.c:21:21: note: expanded from macro 'ARGPAR_CALLOC'
    ((_type *) calloc((_nmemb), sizeof(_type)))
       ^~~~~~
    /home/simark/src/argpar/argpar/argpar.c:291:44: note: place parentheses around the '?:' expression to evaluate it first
    strlen(unknown_opt_name) + 1 + is_short ? 1 : 2);
   ~~~~~~~~~^~~~~~~
    /home/simark/src/argpar/argpar/argpar.c:21:21: note: expanded from macro 'ARGPAR_CALLOC'
    ((_type *) calloc((_nmemb), sizeof(_type)))
       ^~~~~~

Change-Id: Ibf3a4ac46c16c42a8279ede5f610e7c8797c9aed
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

argpar.c: add comments describing static functions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iaa6372026d3fdc70d977ab2dcbcc79f571f24a48

struct argpar_iter: put user data under nested structure

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5cbeddbf688a36b46b0cd715d292daec6b402cb4

enum argpar_iter_next_status: assign negative integral values to errors

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Idd77c0b08296a150b9f771d06fbaf3415e1c2cc9

Add parsing error API

This patch adds the `struct argpar_error` type which contains details
about a parsing error. Get said details with the new dedicated property
getters:

argpar_error_orig_index():
    Returns the index of the original argument for which the error
    occurred.

argpar_error_unknown_opt_name():
    Returns the name of the unknown option for which the error occurred.

argpar_error_opt_descr():
    Returns the descriptor of the option for which the error occurred.

    Also sets an output boolean parameter to whether said option is
    short or long.

Destroy a parsing error with argpar_error_destroy().

argpar_iter_next() now sets such a parsing error object on parsing error
instead of an error string. You can build a corresponding error string
from the properties of the parsing error object.

See the updated user documentation in `argpar.h` for more details.

In `test_argpar.c`, test_fail() now ensures that argpar_iter_next() sets
an parsing error object and that, depending on the returned status code,
its properties have expected values. I moved the "unknown option" tests
from succeed_tests() to fail_tests() as this was a vestige of the
`fail_on_unknown_opt` parameter of argpar_parse().

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7b988253f653f96e6bf6859ae1b48bbcf6fb406d

configure.ac: set the version of the project to 0.1.0

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ia33d275682d17d1dc63c2a1e5d03c62eda48865b

argpar.h: Doxygenize

This patch documents the argpar API with Doxygen, reusing most of the
existing unformatted documentation, and adding more details.

The configuration script generates `Doxyfile` from `Doxyfile.in` to
include the version number of the project.

If you have the Doxygen tool, you can then generate the HTML
documentation as such:

    $ doxygen

The output is `api-doc/html/index.html`.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I73e5edf4adb5e0d4af8ecd08417362b9df4d53db

argpar.c: use the "short option group" terminology throughout

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I10911a0ae0fa019d5be99893323311d4be3ff4c3

Remove the argpar_parse() API

Since the introduction of the iterator API, argpar_parse() is considered
a subset of what the iterator API can do, only adding a conditional (for
`fail_on_unknown_opt`) and creating an array of parsing items for the
user.

Therefore, as you can trivially implement an argpar_parse() equivalent
outside argpar, I see no interest in keeping it in the project.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I73857fef62de052457c9c7c4b0aab66187e81c27

Remove "invalid argument" statuses

This patch removes the only remaining "invalid argument" status, which
parse_long_opt() sets when the length of the name of a long option is
greater than the size of its temporary buffer.

To deal with this, `struct argpar_iter` contains a temporary buffer to
contain the long option name in parse_long_opt(). This temporary buffer
only grows.

`test_argpar.c` contains a new test which exercise the parsers with a
700-character, hipster-themed long option name.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ia5adcfc2bdd978d81841a19ceea4a02f44559eed

Parse `-` and `--` as non-option arguments

The `-` and `--` arguments are common in many Unix command-line tools.
`--` often means "end of options" while `-` often means "read from
standard input". Depending on the application, they can have different
meanings.

This patch makes argpar_iter_next() specifically parse `-` and `--`
arguments as non-options.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I3b3f1670863992a17a7edfabdc48c921f71cd4b6

argpar.h: argpar_iter_create(): add iterator lifetime details

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I57be39db6b3b5dd149ccdb82a5971fffa3c68264

argpar.h: move argpar_item_destroy() close to other item functions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I444f39d5bbdc8498eaeff09c1b6c1f992bf36665

Rename argpar_iter_get_ingested_orig_args() -> argpar_iter_ingested_orig_args()

Personal preference when naming property getters.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I8bb454da0bc12ce638bdea55d1eb9a4eb3fdfff7

Rename argpar_iter_parse_next() -> argpar_iter_next()

Also rename `enum argpar_iter_parse_next_status` to `enum
argpar_iter_next_status` and `ARGPAR_ITER_PARSE_NEXT_STATUS_*` to
`ARGPAR_ITER_NEXT_STATUS_*`.

Personal preference.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5e93bb9abe5e77e7e83622b3f868003a4fafb888

Add error enumerators to `enum argpar_iter_parse_next_status`

This patch adds all the possible reasons for a failure of
argpar_iter_parse_next() as error enumerators to
`enum argpar_iter_parse_next_status`.

This will make it possible to convert the `error` parameter of
argpar_iter_parse_next() to a rich error, without any formatted error
message.

In `test_argpar.c`, test_fail() now accepts an expected
argpar_iter_parse_next() status which it forwards to
test_fail_argpar_iter() which ensures that argpar_iter_parse_next()
returns the expected error status.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I9e8e91dea6066bd2ee935d6ca465569a6fd379aa

argpar.c: add error enumerators to `enum parse_orig_arg_opt_ret`

This patch changes `enum parse_orig_arg_opt_ret` to add

* `PARSE_ORIG_ARG_OPT_RET_ERROR_MISSING_OPT_ARG`
* `PARSE_ORIG_ARG_OPT_RET_ERROR_INVALID_OPT`
* `PARSE_ORIG_ARG_OPT_RET_ERROR_UNEXPECTED_OPT_ARG`
* `PARSE_ORIG_ARG_OPT_RET_ERROR_MEMORY`

and remove the general `PARSE_ORIG_ARG_OPT_RET_ERROR`.

No functional changes intended.

This will make it easier to switch to rich error reporting instead of
a formatted error string.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2e68bea8b14ea1c0b16433df0cb8c01c1252283d

argpar_iter_parse_next(): make the `error` parameter optional

You don't want to know the details of the error? No problemo.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I82f024f3cc78554f5eaa8a72998e9226c5195a4b

Make `struct argpar_item` opaque

This patch improves the encapsulation of argpar by making `struct
argpar_item` opaque, and publicly removing `struct argpar_item_opt` and
`struct argpar_item_non_opt`.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I37ef6c386593e2bb8f817bf4d2bb464e9004615e

tests/test_argpar.c: fix coding style

Add missing `const`, clarify comments, harmonize test messages.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie0f4ca02786b1cc1167c0f2aa4be86d7a9e1a45b

argpar.h: `BABELTRACE_ARGPAR_H` -> `ARGPAR_ARGPAR_H`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Id85bcf2f4910af8f83a48333f0f04dd62970951b

argpar/argpar.{c,h}: fix coding style

Add missing `const`, use uppercase macro names, fix comments, fix names
of local functions.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I18c7a2b1d5572f6b696c72f0cfa12b68c1c5f949

Add iterator-style API

The current API of argpar does not give the user control on when to stop
parsing the arguments.  It either stops at the end of the argument list
or at the first unknown option, if using `fail_on_unknown_opt`.

To make it more convenient to implement "multi-level" command line
interfaces, add an iterator-style API where the user repeatedly calls a
function to get the next item.

By "multi-level" CLI, I mean something like git, where the top-level
command and a subcommand have their own set of options.

    $ top-level --hello there sub-command --hello

For most cases, we could probably work something out by using the
`fail_on_unknown_opt` option combined with the
`argpar_item_non_opt::orig_index` field.  Even if the parsing of the
top-level command goes too far, we can resume the parsing at the index
of the sub-command + 1.  But the example above shows a corner case where
top-level's `--hello` option takes an argument but sub-command's
`--hello` doesn't.  I don't think we could handle this today.

In any case, I think that it's simpler in the end to give a bit more
control to the user and let her get items one by one.  I think it
results in code that is easier to follow.

Using the proposed API, the user starts by creating an argpar_iter
object using argpar_iter_create.  It then calls argpar_iter_parse_next
as much as needed to get one argpar_item at a time.  The returned
argpar_items must be freed with argpar_item_destroy.  In the end, the
argpar_iter must be freed with argpar_iter_destroy.

Testing-wise, I adapted the existing tests to be executed with both
APIs, so the coverage should be pretty good.

Change-Id: I82685672977fbfa96f96bcc678a3e05c6adab76c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Import warning flags and tap from Babeltrace

Since we are going to use this code in Babeltrace, lttng-tools, and
perhaps other projects, I think it would be useful to use warning flags
at least as strict here as we do in these other projects, so we don't
have bad surprises when importing the code there.

Start by importing the warning flag checking system from Babeltrace, and
the list of warning flags used there.

Import the tap code as well, since the current tap code would generate
some errors with the new warning flags.

Change-Id: I86bf5a18bcbce35b887d3ef3285d5566b3f7c69f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Use SPDX-style license header

This is copied from the lttng-tools repo.  In that repo, the comment is
above the header include guard, so I put it at the same place here.

Change-Id: If71e76e78fe2d4347b5ef24d37126ce7f33fb0a1
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Fix: Error out when passing an argument to long option that takes no argument

If the user defines a long option `--foo` and passes `--foo=arg`, the
current behavior is that the option foo is recognized and the argument
is ignored.  Change that to be an error.

It is currently not possible to pass arguments to short options using an
equal sign, so this doesn't apply to short options.

Change-Id: I4b0c50398161aebc81789fdb3fce19a80a5f6646
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Add format attributes to functions with format strings

Compiling with -Wsuggest-attribute=format shows that these functions
could use a format attribute, which helps the compiler validate format
strings.  This patch adds them.

Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: I2884d13b08d9ea67680289e59fb40ebdfecdc3d4

Add missing va_end in argpar_vasprintf

args2 is currently leaked, we need to call va_end on it.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Remove bt_/BT_ prefixes throughout

Since this is not longer part of Babeltrace, remove the bt_/BT_
prefixes.  This was done mechanically using:

    sed -i -e 's/BT_ARGPAR/ARGPAR/g' -e 's/bt_argpar/argpar/g'

Hopefully there isn't too much collateral damage.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Fix comments in bt_argpar_item_array, data -> items

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Strip trailing spaces

Add bootstrap script

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Add .gitignore

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Add build system, remove dependency on glib, add TAP library

This commit...

 * adds an automake-based system.
 * removes glib dependencies from the library code (i.e. not from the tests),
   replacing them with home-grown code.
 * sets up the tests to run using the TAP library [1].

[1] https://github.com/shlomif/libtap-prev

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>

Initial commit

Copy source and tests from the babeltrace repository, commit:

    23256fd15c8ac7d1faaa3e37d0df2e225e90a6c6
    bt2: reverse order of printed causes in _Error.__str__

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>