diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-10-11 14:39:37 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-10-12 13:58:19 +0100 |
commit | 241f29fba6ab4c584eeb4e7f53302aa92d2c11f4 (patch) | |
tree | fab24539e0523b0279ed3c056d432bfcc0e5a402 /bfd/bfd-in2.h | |
parent | 4b41a55fe53ce2da4823ffa3a5b94bd09bf2ab0d (diff) | |
download | fsf-binutils-gdb-241f29fba6ab4c584eeb4e7f53302aa92d2c11f4.zip fsf-binutils-gdb-241f29fba6ab4c584eeb4e7f53302aa92d2c11f4.tar.gz fsf-binutils-gdb-241f29fba6ab4c584eeb4e7f53302aa92d2c11f4.tar.bz2 |
bfd/cache: change type used to track cached BFDs from int to unsigned
Within bfd/cache.c change the type for max_open_files and open_files
variables from int to unsigned. As a consequence of this, the return
type for bfd_cache_max_open() is also changed from int to unsigned.
Within bfd_cache_max_open I've left the local 'max' variable as an
int, this should ensure that if the sysconf call fails, and returns
-1, then the computed max value will be less than 10, which means
max_open_files will be set to 10. If 'max' was changed to unsigned
then, should the sysconf call fail, we'd end up with max becoming a
very large positive number ... which is clearly not what we want.
And, while I was auditing how open_files is used, I added an assert
within bfd_cache_delete to ensure that we don't try to reduce
open_files below zero.
There should be no user visible change with this commit.
Diffstat (limited to 'bfd/bfd-in2.h')
0 files changed, 0 insertions, 0 deletions