Re: [systemd-devel] PATCH: fix sparse warnings
On Thu, 22.03.12 10:32, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Wed, Mar 21, 2012 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? I'd suggest including this in some 'make test' type target only, but note that most of the stuff sparse throws our are warnings, and so any form of automation isn't really helpful with sparse. Sparse checking is great, just like many other tools like valgrind, etc. , but, skilled eyes are required to make sense of the output. Sure, I use llvm-analyze and valgrind all the time on systemd. I am just curious what the best way to use sparse on it is. Just setting CC=cgcc results in a lot of spew, that I can't make sense of, such as the XML output being misdirected. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Mon, Mar 26, 2012 at 10:43 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 22.03.12 10:32, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Wed, Mar 21, 2012 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? I'd suggest including this in some 'make test' type target only, but note that most of the stuff sparse throws our are warnings, and so any form of automation isn't really helpful with sparse. Sparse checking is great, just like many other tools like valgrind, etc. , but, skilled eyes are required to make sense of the output. Sure, I use llvm-analyze and valgrind all the time on systemd. I am just curious what the best way to use sparse on it is. Just setting CC=cgcc results in a lot of spew, that I can't make sense of, such as the XML output being misdirected. I don't think we can avoid that unless we either limit the stuff being passed to sparse, or run sparse manually instead of through pipelining it in the normal compile chain, which is what causes the garbage output being dumped. Unfortunately I've never used sparse in that matter - it should be possible though. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le jeudi 22 mars 2012 à 10:32 -0700, Kok, Auke-jan H a écrit : On Wed, Mar 21, 2012 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? I'd suggest including this in some 'make test' type target only, but note that most of the stuff sparse throws our are warnings, and so any form of automation isn't really helpful with sparse. agreed. And be sure to run a git sparse, I'm sent some fixes regarding some barrier code which is used by systemd. Sparse checking is great, just like many other tools like valgrind, etc. , but, skilled eyes are required to make sense of the output. Yep. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Wed, Mar 21, 2012 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? I'd suggest including this in some 'make test' type target only, but note that most of the stuff sparse throws our are warnings, and so any form of automation isn't really helpful with sparse. Sparse checking is great, just like many other tools like valgrind, etc. , but, skilled eyes are required to make sense of the output. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Fri, 16.03.12 14:32, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 14 mars 2012 à 11:36 -0700, Josh Triplett a écrit : On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? Thanks for your work, much appreciated Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le vendredi 16 mars 2012 à 14:32 +0100, Frederic Crozat a écrit : Le mercredi 14 mars 2012 à 11:36 -0700, Josh Triplett a écrit : On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Quick follow-up on this patch : I've tested patched systemd on both x86 and ppc, reading journals generated from one platform on the other and vice-versa and it worked fine. So, with this patch, it seems we fixed the last endianness issue in journal code. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 14 mars 2012 à 11:36 -0700, Josh Triplett a écrit : On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. -- Frederic Crozat fcro...@suse.com SUSE From 87859f428ec7927e5a423fa6df46c6b6a54e7817 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Fri, 16 Mar 2012 11:59:04 +0100 Subject: [PATCH] add sparse support to detect endianness bug le16/32/64_t type should be used when storing little-endian value header to integrate with sparse from Josh Triplett j...@joshtriplett.org --- src/journal/journal-def.h | 74 +- src/journal/journal-file.c | 15 --- src/journal/journal-file.h |1 + src/journal/journal-internal.h |2 +- src/journal/journald.c |5 +- src/journal/sd-journal.c | 10 +++-- src/journal/sparse-endian.h| 87 7 files changed, 143 insertions(+), 51 deletions(-) create mode 100644 src/journal/sparse-endian.h diff --git a/src/journal/journal-def.h b/src/journal/journal-def.h index 964e0c2..9cb8051 100644 --- a/src/journal/journal-def.h +++ b/src/journal/journal-def.h @@ -22,7 +22,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. ***/ -#include inttypes.h +#include sparse-endian.h #include systemd/sd-id128.h @@ -60,48 +60,48 @@ _packed_ struct ObjectHeader { uint8_t type; uint8_t flags; uint8_t reserved[6]; -uint64_t size; +le64_t size; uint8_t payload[]; }; _packed_ struct DataObject { ObjectHeader object; -uint64_t hash; -uint64_t next_hash_offset; -uint64_t next_field_offset; -uint64_t entry_offset; /* the first array entry we store inline */ -uint64_t entry_array_offset; -uint64_t n_entries; +le64_t hash; +le64_t next_hash_offset; +le64_t next_field_offset; +le64_t entry_offset; /* the first array entry we store inline */ +le64_t entry_array_offset; +le64_t n_entries; uint8_t payload[]; }; _packed_ struct FieldObject { ObjectHeader object; -uint64_t hash; -uint64_t next_hash_offset; -uint64_t head_data_offset; -uint64_t tail_data_offset; +le64_t hash; +le64_t next_hash_offset; +le64_t head_data_offset; +le64_t tail_data_offset; uint8_t payload[]; }; _packed_ struct EntryItem { -uint64_t object_offset; -uint64_t hash; +le64_t object_offset; +le64_t hash; }; _packed_ struct EntryObject { ObjectHeader object; -uint64_t seqnum; -uint64_t realtime; -uint64_t monotonic; +le64_t seqnum; +le64_t realtime; +le64_t monotonic; sd_id128_t boot_id; -uint64_t xor_hash; +le64_t xor_hash; EntryItem items[]; }; _packed_ struct HashItem { -uint64_t head_hash_offset; -uint64_t tail_hash_offset; +le64_t head_hash_offset; +le64_t tail_hash_offset; }; _packed_ struct HashTableObject { @@ -111,8 +111,8 @@ _packed_ struct HashTableObject { _packed_ struct EntryArrayObject { ObjectHeader object; -uint64_t next_entry_array_offset; -uint64_t items[]; +le64_t next_entry_array_offset; +le64_t items[]; }; union Object { @@ -145,21
Re: [systemd-devel] PATCH: fix sparse warnings
On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. (and also, emacs' recognizes this and highlights it differently ;-)) Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h (and also, emacs' recognizes this and highlights it differently ;-)) I just checked with emacs -q, and at least on my system emacs seems to correctly identify and highlight all six of those names as types by default, in all the contexts I can think of where a type can appear. Take a look at https://www.gnu.org/software/emacs/manual/html_node/ccmode/Font-Locking-Preliminaries.html ; you may want to make sure you have your font-lock level set sufficiently high. Thanks! No problem; I look forward to seeing what endianness bugs you can squash with this. :) - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 07 mars 2012 à 06:34 -0800, Josh Triplett a écrit : On Mon, Mar 05, 2012 at 03:21:12PM +0100, Frederic Crozat wrote: Le lundi 05 mars 2012 ? 15:10 +0100, Lennart Poettering a ?crit : I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Well, I spend almost a day trying to get sparse to spot endian-ness errors but couldn't get it to work properly :( The idea would be to replace any uint64_t type with __le64 (from /usr/include/linux/types.h) in data structures written on disk and make sure only function returning __le64 are used to modify those variables. Unfortunately, I wasn't able to teach sparse about htole64 / le64toh. Help welcome ;) Sparse's endianness support works via the attribute bitwise, which applies to an integral type and creates a new incompatible type every time you use it. Thus, if you write: typedef uint64_t __attribute__((bitwise)) le64; typedef uint64_t __attribute__((bitwise)) be64; then you have types le64 and be64 which Sparse considers incompatible with uint64_t. (The odd name bitwise refers to what you can do with such a type: you can do bitwise operations with two values of the same bitwise type, but you can't do arithmetic or similar.) The corresponding __attribute__((force)) should appear on a type used in a cast, to make that cast suppress warnings (including those about bitwise). The conversion functions should use these casts to convert the type, in addition to actually doing any necessary byteswapping. In order to do that, I'd suggest actually using static inline functions with real types, rather than macros that have no types. (You can use hacks to do typechecking in macros, but you'll end up with something much worse than just defining a function, and more importantly your warning messages won't look as clear.) One of these days, I'd love to see glibc add built-in support for Sparse-style endian-specific types, but for now, you'll have to write your own functions. Assuming that you don't want to change the names of all the byteswapping functions, I'd suggest defining your own set of static inlines with the same names; unfortunately that means #undef-ing all the ones defined by endian.h. Sparse defines the preprocessor symbol __CHECKER__, which you can use to detect Sparse and use Sparse-specific attributes. include/linux/compiler.h in the kernel uses this to define macros like __bitwise and __force which wrap the corresponding Sparse attributes, and which become no-ops when compiling with GCC. I'd recommend following that approach. I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. Thanks Josh, I tried to do something similar to your header and failed (but I'm not sparse expert), so I'll test it and report the results. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Wed, 29.02.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings Looks all good. Applied. I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le lundi 05 mars 2012 à 15:10 +0100, Lennart Poettering a écrit : On Wed, 29.02.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings Looks all good. Applied. I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Well, I spend almost a day trying to get sparse to spot endian-ness errors but couldn't get it to work properly :( The idea would be to replace any uint64_t type with __le64 (from /usr/include/linux/types.h) in data structures written on disk and make sure only function returning __le64 are used to modify those variables. Unfortunately, I wasn't able to teach sparse about htole64 / le64toh. Help welcome ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix sparse warnings
Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). -- Frederic Crozat fcro...@novell.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) -- Frederic Crozat fcro...@suse.com SUSE From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings --- src/getty-generator.c |2 +- src/hashmap.c |4 ++-- src/log.c |4 ++-- src/macro.h |1 + src/mount.c |2 +- src/util.c|4 ++-- 6 files changed, 9 insertions(+), 8 deletions(-) diff --git a/src/getty-generator.c b/src/getty-generator.c index 1263785..7fac43a 100644 --- a/src/getty-generator.c +++ b/src/getty-generator.c @@ -28,7 +28,7 @@ #include unit-name.h #include virt.h -const char *arg_dest = /tmp; +static const char *arg_dest = /tmp; static int add_symlink(const char *fservice, const char *tservice) { char *from = NULL, *to = NULL; diff --git a/src/hashmap.c b/src/hashmap.c index 7ef8097..6928118 100644 --- a/src/hashmap.c +++ b/src/hashmap.c @@ -55,10 +55,10 @@ struct pool { unsigned n_used; }; -struct pool *first_hashmap_pool = NULL; +static struct pool *first_hashmap_pool = NULL; static void *first_hashmap_tile = NULL; -struct pool *first_entry_pool = NULL; +static struct pool *first_entry_pool = NULL; static void *first_entry_tile = NULL; static void* allocate_tile(struct pool **first_pool, void **first_tile, size_t tile_size) { diff --git a/src/log.c b/src/log.c index c37ab22..e1f511c 100644 --- a/src/log.c +++ b/src/log.c @@ -625,11 +625,11 @@ _noreturn_ static void log_assert(const char *text, const char *file, int line, } #pragma GCC diagnostic pop -void log_assert_failed(const char *text, const char *file, int line, const char *func) { +_noreturn_ void log_assert_failed(const char *text, const char *file, int line, const char *func) { log_assert(text, file, line, func, Assertion '%s' failed at %s:%u, function %s(). Aborting.); } -void log_assert_failed_unreachable(const char *text, const char *file, int line, const char *func) { +_noreturn_ void log_assert_failed_unreachable(const char *text, const char *file, int line, const char *func) { log_assert(text, file, line, func, Code should not be reached '%s' at %s:%u, function %s(). Aborting.); } diff --git a/src/macro.h b/src/macro.h index 58de001..19f259e 100644 --- a/src/macro.h +++ b/src/macro.h @@ -23,6 +23,7 @@ ***/ #include assert.h +#include sys/param.h #include sys/types.h #include sys/uio.h #include inttypes.h diff --git a/src/mount.c b/src/mount.c index 0ae964b..f80fcf5 100644 --- a/src/mount.c +++ b/src/mount.c @@ -271,7 +271,7 @@ static char* mount_test_option(const char *haystack, const char *needle) { * struct mntent */ if (!haystack) -return false; +return NULL; zero(me); me.mnt_opts = (char*) haystack; diff --git a/src/util.c b/src/util.c index e9869ea..bf22f57 100644 --- a/src/util.c +++ b/src/util.c @@ -892,7 +892,7 @@ int load_env_file( char ***rl) { FILE *f; -char **m = 0; +char **m = NULL; int r; assert(fname); @@ -4177,7 +4177,7 @@ int wait_for_terminate_and_warn(const char *name, pid_t pid) { } -void freeze(void) { +_noreturn_ void freeze(void) { /* Make sure nobody waits for us on a socket anymore */ close_all_fds(NULL, 0); -- 1.7.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel