Imagelibrary/binutils-gdb
1
0
Fork 1
mirror of https://github.com/bminor/binutils-gdb.git synced 2025-12-26 01:07:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

gdb, gdbserver, gdbsupport: trim trailing whitespaces

Browse Source 
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled.  I
realized that this is because the .editorconfig file now has

    trim_trailing_whitespace = true

for many file types.  If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files.  Otherwise, people will
always get spurious whitespace changes when editing these files.

I did a mass cleanup using this command:

$ find gdb gdbserver gdbsupport -type f \( \
    -name "*.c" -o \
    -name "*.h" -o \
    -name "*.cc" -o \
    -name "*.texi" -o \
    -name "*.exp" -o \
    -name "*.tcl" -o \
    -name "*.py" -o \
    -name "*.s" -o \
    -name "*.S" -o \
    -name "*.asm" -o \
    -name "*.awk" -o \
    -name "*.ac" -o \
    -name "Makefile*" -o \
    -name "*.sh" -o \
    -name "*.adb" -o \
    -name "*.ads" -o \
    -name "*.d" -o \
    -name "*.go" -o \
    -name "*.F90" -o \
    -name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +

I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.

Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
This commit is contained in:
Simon Marchi
2025-10-10 23:59:32 -04:00
committed by Simon Marchi
parent de49e8229b
commit a5cbe67512
497 changed files with 3067 additions and 3067 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
gdb/bcache.c
View File

@@ -64,7 +64,7 @@ bcache::expand_hash_table ()
{
/* A table of good hash table sizes. Whenever we grow, we pick the
next larger size from this table. sizes[i] is close to 1 << (i+10),
so we roughly double the table size each time. After we fall off
so we roughly double the table size each time. After we fall off
the end of this table, we just double. Don't laugh --- there have
been executables sighted with a gigabyte of debug info. */
static const unsigned long sizes[] = {
@@ -282,7 +282,7 @@ bcache::print_statistics (const char *type)
if (s)
{
occupied_buckets++;
while (s)
{
gdb_assert (b < m_num_buckets);
@@ -343,7 +343,7 @@ bcache::print_statistics (const char *type)
gdb_printf ("%ld\n", m_unique_size / m_unique_count);
else
/* i18n: "Average entry size: (not applicable)". */
gdb_printf (_("(not applicable)\n"));
gdb_printf (_("(not applicable)\n"));
gdb_printf (_(" Median entry size: %d\n"), median_entry_size);
gdb_printf ("\n");
@@ -356,7 +356,7 @@ Total memory used by bcache, including overhead: %ld\n"),
print_percentage (m_total_size - m_structure_size, m_total_size);
gdb_printf ("\n");
gdb_printf (_(" Hash table size: %3d\n"),
gdb_printf (_(" Hash table size: %3d\n"),
m_num_buckets);
gdb_printf (_(" Hash table expands: %lu\n"),
m_expand_count);
@@ -374,7 +374,7 @@ Total memory used by bcache, including overhead: %ld\n"),
else
/* i18n: "Average hash chain length: (not applicable)". */
gdb_printf (_("(not applicable)\n"));
gdb_printf (_(" Maximum hash chain length: %3d\n"),
gdb_printf (_(" Maximum hash chain length: %3d\n"),
max_chain_length);
gdb_printf ("\n");
}