[PATCH v5 2/4] Add system-wide tunables: cache ld.so.cache

[DJ Delorie]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
> I agree with Yury here that we need to add some tests, at least some
> minimal one that stress the ld.so.cache reload (which is not the usual
> scenario).  I would suggest add test-containts tests that:

Yup, I was thinking the same thing.  One test should be able to test
both good->bad and bad->good as well as changes to paths.

>     1.3. If not modifying the ld.so.cache contents keep the same
>          contents.

I assume this just requires doing two dlopen()'s back to back and making
sure they both work?

>> +  static int copy_old_time = 0;
>
> Maybe use bool here?

Can do.

>> +  /* At this point, NEW_CACHE_FILE_TIME is valid as well as
>> +     CACHE_FILE_TIME, so we compare them.  We list fields in the order
>> +     they're most likely to be different in.  */
>> +  return ((new_cache_file_time.st_mtime != cache_file_time.st_mtime)
>> +	  || (new_cache_file_time.st_ino != cache_file_time.st_ino)
>> +	  || (new_cache_file_time.st_size != cache_file_time.st_size)
>> +	  || (new_cache_file_time.st_dev != cache_file_time.st_dev)
>> +	   );
>
> Maybe only keep the required fields, instead of while stat struct?
> If we use a struct the test could optimized in bulk by the compiler.

Done.  I used this syntax to avoid having to "know" what the struct stat
field types are:

static struct {
  typeof (struct __stat64_t64.st_mtime) mtime;
  typeof (struct __stat64_t64.st_ino) ino;
  typeof (struct __stat64_t64.st_size) size;
  typeof (struct __stat64_t64.st_dev) dev;
} cache_file_time, new_cache_file_time;