Today's patches

Matt Seitz (matseitz) matseitz at
Fri May 8 16:57:42 UTC 2015

ISO Standard C says that if an initializer initializes some but not all elements, the additional elements are automatically initialized as if "0" was explicitly given.  This makes it nice to use "={0}" as a default initializer, without having to update the initializer every time the elements in a struct are changed.

Section 6.7.9:

21.  If there are fewer initializers in a brace-enclosed list than there are elements or members
of an aggregate, or fewer characters in a string literal used to initialize an array of known
size than there are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage duration.

Meaning, any items not explicitly initialized will be initialized according to these rules:

10 If an object that has automatic storage duration is not initialized explicitly, its value is
indeterminate. If an object that has static or thread storage duration is not initialized
explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules,
and any padding is initialized to zero bits;
— if it is a union, the first named member is initialized (recursively) according to these
rules, and any padding is initialized to zero bits;

-----Original Message-----
From: inn-workers-bounces at [mailto:inn-workers-bounces at] On Behalf Of Julien ÉLIE
Sent: Friday, May 08, 2015 9:41
To: inn-workers at
Subject: Re: Today's patches

Hi Richard,

gcc warns about the new initialization { 0 }.  Shouldn't the struct be initialized with as many "0" as there are elements in the struct?

art.c:448:24: warning: missing field 'data' initializer
  ARTHANDLE     arth = { 0 };

>>> Subject: [PATCH 2/3] Remove redundant (broken!) code
>>> The check was (i) off by one and (ii) can never happen, given the 
>>> loop condition.
>> At the end of the loop, we have:
>>          parent = &entry->next.recno;
>>          current = *parent;
> Yes - but that is too late for the call to entry_splice(), which is 
> where the user-after-munmap (or use-after-free) would occur.  So 
> parent must be recomputed somehow if a remap occurs.  The conservative 
> way to do it would be just to start again from the top.

Suggestion of patch:

--- tradindexed/tdx-group.c	(révision 9852)
+++ tradindexed/tdx-group.c	(copie de travail)
@@ -359,7 +359,7 @@
        their next entry is entry 0.  We don't want to leave things in this
        state (particularly if this was the first expansion of the index file,
        in which case entry 0 points to entry 0 and our walking functions may
-       go into infinite loops.  Undo the file expansion. */
+       go into infinite loops).  Undo the file expansion. */
     if (!index_map(index)) {
         index->count -= 1024;
         if (ftruncate(index->fd, index_file_size(index->count)) < 0) { @@ -558,11 +558,20 @@
     parent = &index->header->hash[index_bucket(hash)].recno;
     current = *parent;
-    while (current >= 0 && current < index->count) {
+    while (current >= 0) {
         struct group_entry *entry;
-        if (current > index->count && !index_maybe_remap(index, current))
-            return -1;
+        if (current >= index->count) {
+            if (!index_maybe_remap(index, current)) {
+                return -1;
+            }
+            parent = &index->header->hash[index_bucket(hash)].recno;
+            current = *parent;
+            if (current < 0 || current >= index->count) {
+                syswarn("tradindexed: entry %ld out of range", current);
+                return -1;
+            }
+        }
         entry = &index->entries[current];
         if (entry->deleted == 0)
             if (memcmp(&hash, &entry->hash, sizeof(hash)) == 0) {

Julien ÉLIE

« Vinum bonum laetificat cor hominis. »
inn-workers mailing list
inn-workers at

More information about the inn-workers mailing list