1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2025-01-20 14:03:39 +03:00
Hannu Lounento 4a2dbd9952 man: fix sd_journal_*_with_location's func argument
`sd_journal_print_with_location` and similar functions behave
inconsistently compared to their documentation, which says:

    sd_journal_print_with_location(), sd_journal_printv_with_location(),
    sd_journal_send_with_location(), sd_journal_sendv_with_location(),
    and sd_journal_perror_with_location() [...] accept additional
    parameters to explicitly set the source file name, function, and
    line. Those arguments must contain valid journal entries including
    the variable name, e.g. "CODE_FILE=src/foo.c", "CODE_LINE=666",
    "CODE_FUNC=myfunc".

Calling e.g. `sd_journal_sendv_with_location` with
`CODE_FUNC=myfunction` as the value of the argument `func` results in

    "CODE_FUNC" : "CODE_FUNC=myfunction"

because `sd_journal_*_with_location` implicitly prefix the argument
`func` with `CODE_FUNC=`. For example:

    _public_ int sd_journal_sendv_with_location(
                    const char *file, const char *line,
                    const char *func,
                    const struct iovec *iov, int n) {
            [...]
            char *f;
            [...]
            niov = newa(struct iovec, n + 3);
            [...]
            ALLOCA_CODE_FUNC(f, func);
            [...]
            niov[n++] = IOVEC_MAKE_STRING(f);

            return sd_journal_sendv(niov, n);
    }

where `ALLOCA_CODE_FUNC` is:

    #define ALLOCA_CODE_FUNC(f, func)                 \
            do {                                      \
                    size_t _fl;                       \
                    const char *_func = (func);       \
                    char **_f = &(f);                 \
                    _fl = strlen(_func) + 1;          \
                    *_f = newa(char, _fl + 10);       \
                    memcpy(*_f, "CODE_FUNC=", 10);    \
                    memcpy(*_f + 10, _func, _fl);     \
            } while (false)

The arguments `file` and `line` are _not_ prefixed similarly but
expected to be prefixed already with `CODE_FILE=` and `CODE_LINE=`
respectively and sent as is like the documentation describes.

That is, the argument `func` is treated differently and behaves
inconsistently compared to the arguments `file` and `line`. The behavior
seems still intentional:

    _public_ int sd_journal_printv_with_location(int priority, const char *file, const char *line, const char *func, const char *format, va_list ap) {
            [...]
            /* func is initialized from __func__ which is not a macro, but
            * a static const char[], hence cannot easily be prefixed with
            * CODE_FUNC=, hence let's do it manually here. */
            ALLOCA_CODE_FUNC(f, func);
            [...]
    }

Thus, change the documentation to match the actual behavior.

Note: `sd_journal_{print,send}` and `sd_journal_{print,send}v` work as
expected as they only pass the function name (i.e. without `CODE_FUNC=`)
to the `func` argument of the `sd_journal_*_with_location` functions
they call. For example:

    #define sd_journal_print(priority, ...) sd_journal_print_with_location(priority, "CODE_FILE=" __FILE__, "CODE_LINE=" _SD_STRINGIFY(__LINE__), __func__, __VA_ARGS__)

(cherry picked from commit 673ed95966c741807f993f7fd6b5d93bbc504458)
(cherry picked from commit 121bbb59f3075a07c571dca9f7c628eb7433a99b)
(cherry picked from commit 2d2ec1eea4468dfb2e4ccc07ae43aa451e0e2cd2)
2023-07-10 22:01:38 +01:00
..
2022-05-05 12:30:06 +02:00
2022-01-07 17:37:37 +01:00
2021-10-07 22:13:12 +02:00
2023-04-29 11:36:49 +01:00
2021-08-11 09:34:45 +02:00
2021-08-18 13:36:14 +02:00
2022-05-07 15:17:56 +09:00
2022-08-08 10:27:45 +02:00
2022-03-07 15:32:22 +09:00
2023-04-29 11:36:49 +01:00
2021-01-04 11:01:17 +00:00
2021-06-30 23:33:00 +09:00
2021-01-04 11:01:17 +00:00
2022-01-06 22:20:11 +09:00
2021-11-30 13:54:27 +01:00
2021-08-20 11:09:47 +02:00
2021-04-19 23:16:02 +02:00
2022-04-12 11:02:16 +02:00
2022-04-25 10:06:08 +09:00
2022-03-21 20:06:13 +00:00
2022-04-12 11:02:16 +02:00
2022-05-16 14:54:43 +02:00
2020-11-09 13:23:58 +09:00
2022-03-13 18:30:57 +00:00
2020-12-16 17:21:48 +01:00
2022-05-11 19:12:24 +01:00