* [PATCH] util/zlib-extra: de-inline gzerror_str
@ 2020-04-27 12:28 David Bremner
2020-04-27 16:54 ` Daniel Kahn Gillmor
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: David Bremner @ 2020-04-27 12:28 UTC (permalink / raw)
To: notmuch
It turns out the behaviour of inline functions in C header files is
not a good idea, and can cause linking problems if the compiler
decides not to inline them. In principle this is solvable by using a
"static inline" declaration, but this potentially makes a copy in
every compilation unit. Since we don't actually care about the
performance of this function, just use a non-inline function.
---
| 7 +++++++
| 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
--git a/util/zlib-extra.c b/util/zlib-extra.c
index 2d2d2414..3a75e504 100644
--- a/util/zlib-extra.c
+++ b/util/zlib-extra.c
@@ -85,3 +85,10 @@ gz_error_string (util_status_t status, gzFile file)
else
return util_error_string (status);
}
+
+const char *
+gzerror_str(gzFile file)
+{
+ int dummy;
+ return gzerror (file, &dummy);
+}
--git a/util/zlib-extra.h b/util/zlib-extra.h
index 296dc914..e9925c98 100644
--- a/util/zlib-extra.h
+++ b/util/zlib-extra.h
@@ -29,8 +29,8 @@ gz_error_string (util_status_t status, gzFile stream);
/* Call gzerror with a dummy errno argument, the docs don't promise to
* support the NULL case */
-inline const char *
-gzerror_str(gzFile file) { int dummy; return gzerror (file, &dummy); }
+const char *
+gzerror_str(gzFile file);
#ifdef __cplusplus
}
--
2.26.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] util/zlib-extra: de-inline gzerror_str
2020-04-27 12:28 [PATCH] util/zlib-extra: de-inline gzerror_str David Bremner
@ 2020-04-27 16:54 ` Daniel Kahn Gillmor
2020-04-27 18:03 ` Tomi Ollila
2020-04-28 13:38 ` David Bremner
2 siblings, 0 replies; 4+ messages in thread
From: Daniel Kahn Gillmor @ 2020-04-27 16:54 UTC (permalink / raw)
To: David Bremner, notmuch
[-- Attachment #1.1: Type: text/plain, Size: 544 bytes --]
On Mon 2020-04-27 09:28:08 -0300, David Bremner wrote:
> It turns out the behaviour of inline functions in C header files is
> not a good idea, and can cause linking problems if the compiler
> decides not to inline them. In principle this is solvable by using a
> "static inline" declaration, but this potentially makes a copy in
> every compilation unit. Since we don't actually care about the
> performance of this function, just use a non-inline function.
LGTM. No need for premature optimization in the error case anyway.
--dkg
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] util/zlib-extra: de-inline gzerror_str
2020-04-27 12:28 [PATCH] util/zlib-extra: de-inline gzerror_str David Bremner
2020-04-27 16:54 ` Daniel Kahn Gillmor
@ 2020-04-27 18:03 ` Tomi Ollila
2020-04-28 13:38 ` David Bremner
2 siblings, 0 replies; 4+ messages in thread
From: Tomi Ollila @ 2020-04-27 18:03 UTC (permalink / raw)
To: David Bremner, notmuch
On Mon, Apr 27 2020, David Bremner wrote:
> It turns out the behaviour of inline functions in C header files is
> not a good idea, and can cause linking problems if the compiler
> decides not to inline them. In principle this is solvable by using a
> "static inline" declaration, but this potentially makes a copy in
> every compilation unit. Since we don't actually care about the
> performance of this function, just use a non-inline function.
LGTM.
Tomi
> ---
> util/zlib-extra.c | 7 +++++++
> util/zlib-extra.h | 4 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/util/zlib-extra.c b/util/zlib-extra.c
> index 2d2d2414..3a75e504 100644
> --- a/util/zlib-extra.c
> +++ b/util/zlib-extra.c
> @@ -85,3 +85,10 @@ gz_error_string (util_status_t status, gzFile file)
> else
> return util_error_string (status);
> }
> +
> +const char *
> +gzerror_str(gzFile file)
> +{
> + int dummy;
> + return gzerror (file, &dummy);
> +}
> diff --git a/util/zlib-extra.h b/util/zlib-extra.h
> index 296dc914..e9925c98 100644
> --- a/util/zlib-extra.h
> +++ b/util/zlib-extra.h
> @@ -29,8 +29,8 @@ gz_error_string (util_status_t status, gzFile stream);
>
> /* Call gzerror with a dummy errno argument, the docs don't promise to
> * support the NULL case */
> -inline const char *
> -gzerror_str(gzFile file) { int dummy; return gzerror (file, &dummy); }
> +const char *
> +gzerror_str(gzFile file);
>
> #ifdef __cplusplus
> }
> --
> 2.26.2
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] util/zlib-extra: de-inline gzerror_str
2020-04-27 12:28 [PATCH] util/zlib-extra: de-inline gzerror_str David Bremner
2020-04-27 16:54 ` Daniel Kahn Gillmor
2020-04-27 18:03 ` Tomi Ollila
@ 2020-04-28 13:38 ` David Bremner
2 siblings, 0 replies; 4+ messages in thread
From: David Bremner @ 2020-04-28 13:38 UTC (permalink / raw)
To: notmuch
David Bremner <david@tethera.net> writes:
> It turns out the behaviour of inline functions in C header files is
> not a good idea, and can cause linking problems if the compiler
> decides not to inline them. In principle this is solvable by using a
> "static inline" declaration, but this potentially makes a copy in
> every compilation unit. Since we don't actually care about the
> performance of this function, just use a non-inline function.
pushed to master, with slightly tweaked commit message
d
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-04-28 13:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-27 12:28 [PATCH] util/zlib-extra: de-inline gzerror_str David Bremner
2020-04-27 16:54 ` Daniel Kahn Gillmor
2020-04-27 18:03 ` Tomi Ollila
2020-04-28 13:38 ` David Bremner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).