Re: [systemd-devel] PATCH: fix sparse warnings

2012-03-26 Thread Lennart Poettering
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

2012-03-26 Thread Kok, Auke-jan H
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

2012-03-23 Thread Frederic Crozat
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

2012-03-22 Thread Kok, Auke-jan H
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

2012-03-21 Thread Lennart Poettering
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

2012-03-19 Thread Frederic Crozat
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

2012-03-16 Thread Frederic Crozat
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

2012-03-14 Thread Lennart Poettering
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

2012-03-14 Thread Josh Triplett
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

2012-03-07 Thread Frederic Crozat
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

2012-03-05 Thread Lennart Poettering
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

2012-03-05 Thread Frederic Crozat
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

2012-02-29 Thread Frederic Crozat
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

2012-02-29 Thread Frederic Crozat
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