From: Julian Seward Date: Thu, 23 Jan 2020 09:53:36 +0000 (+0100) Subject: Fix some spelling errors found by Lintian. Patch from Alessandro Ghedini . --- diff --git a/VEX/priv/ir_defs.c b/VEX/priv/ir_defs.c index 7b6e847fdb..176ca9b286 100644 --- a/VEX/priv/ir_defs.c +++ b/VEX/priv/ir_defs.c @@ -5198,7 +5198,7 @@ void sanityCheckIRSB ( const IRSB* bb, const HChar* caller, if (bb->stmts_used < 0 || bb->stmts_size < 8 || bb->stmts_used > bb->stmts_size) /* this BB is so strange we can't even print it */ - vpanic("sanityCheckIRSB: stmts array limits wierd"); + vpanic("sanityCheckIRSB: stmts array limits weird"); /* Ensure each temp has a plausible type. */ for (i = 0; i < n_temps; i++) { diff --git a/callgrind/docs/cl-manual.xml b/callgrind/docs/cl-manual.xml index 31fcbaabd8..38dc73d90a 100644 --- a/callgrind/docs/cl-manual.xml +++ b/callgrind/docs/cl-manual.xml @@ -363,7 +363,7 @@ callgrind.out.pid.part-threa Afterwards, instrumentation can be controlled in two ways: first, interactively with: callgrind_control -i on (and switching off again by specifying "off" instead of "on"). Second, - instrumentation state can be programatically changed with the + instrumentation state can be programmatically changed with the macros ; and ;. @@ -371,7 +371,7 @@ callgrind.out.pid.part-threa Similarly, the collection state at program start can be switched off by . During - execution, it can be controlled programatically with the + execution, it can be controlled programmatically with the macro CALLGRIND_TOGGLE_COLLECT;. Further, you can limit event collection to a specific function by using . @@ -723,7 +723,7 @@ Also see . Note that the resulting call graph will most probably not contain main, but will contain all the functions executed after instrumentation was enabled. - Instrumentation can also programatically enabled/disabled. See the + Instrumentation can also be programmatically enabled/disabled. See the Callgrind include file callgrind.h for the macro you have to use in your source code. For cache diff --git a/coregrind/m_commandline.c b/coregrind/m_commandline.c index e34d0f0b4e..27c53ba705 100644 --- a/coregrind/m_commandline.c +++ b/coregrind/m_commandline.c @@ -66,7 +66,7 @@ static HChar* read_dot_valgrindrc ( const HChar* dir ) if ( !sr_isError(fd) ) { Int res = VG_(fstat)( sr_Res(fd), &stat_buf ); /* Ignore if not owned by the current user, or is not a regular file, - or is world writeable (CVE-2008-4865). */ + or is world writable (CVE-2008-4865). */ if (res == 0 && stat_buf.uid == VG_(geteuid)() && VKI_S_ISREG(stat_buf.mode) diff --git a/coregrind/m_gdbserver/server.c b/coregrind/m_gdbserver/server.c index a2cb2b2971..cc809a8b63 100644 --- a/coregrind/m_gdbserver/server.c +++ b/coregrind/m_gdbserver/server.c @@ -258,7 +258,7 @@ int handle_gdb_valgrind_command (char *mon, OutputSink *sink_wanted_at_return) " Valgrind internal host status/memory\n" " v.translate [] : debug translation of with \n" " (default traceflags 0b00100000 : show after instrumentation)\n" -" An additional flag 0b100000000 allows to show gdbserver instrumentation\n"); +" An additional flag 0b100000000 allows one to show gdbserver instrumentation\n"); } break; case 1: /* v.set */ diff --git a/coregrind/m_hashtable.c b/coregrind/m_hashtable.c index 4d53cf2c2c..19c604d3a6 100644 --- a/coregrind/m_hashtable.c +++ b/coregrind/m_hashtable.c @@ -296,7 +296,7 @@ void VG_(HT_print_stats) ( const VgHashTable *table, HT_Cmp_t cmp ) } VG_(message)(Vg_DebugMsg, - "nr occurences of" + "nr occurrences of" " chains of len N," " N-plicated keys," " N-plicated elts\n"); diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c index a60bba817f..77f78ebbc7 100644 --- a/coregrind/m_scheduler/scheduler.c +++ b/coregrind/m_scheduler/scheduler.c @@ -2245,7 +2245,7 @@ void do_client_request ( ThreadId tid ) "to recompile such code, using the header files from this version of\n" "Valgrind, and not any previous version.\n" "\n" - "If you see this mesage in any other circumstances, it is probably\n" + "If you see this message in any other circumstances, it is probably\n" "a bug in Valgrind. In this case, please file a bug report at\n" "\n" " http://www.valgrind.org/support/bug_reports.html\n" diff --git a/coregrind/m_xtree.c b/coregrind/m_xtree.c index 078edc5660..16635ebb62 100644 --- a/coregrind/m_xtree.c +++ b/coregrind/m_xtree.c @@ -977,7 +977,7 @@ void VG_(XT_massif_print) FP("n%u: %llu %s\n", n_groups, top_total, header->top_node_desc); /* Output depth 0 groups. */ - DMSG(1, "XT_massif_print outputing %u depth 0 groups\n", n_groups); + DMSG(1, "XT_massif_print outputting %u depth 0 groups\n", n_groups); for (i = 0; i < n_groups; i++) ms_output_group(fp, 0, 0, &groups[i], sig_sz, header->sig_threshold); diff --git a/drd/docs/drd-manual.xml b/drd/docs/drd-manual.xml index 7692dacea4..8e28e96e26 100644 --- a/drd/docs/drd-manual.xml +++ b/drd/docs/drd-manual.xml @@ -356,7 +356,7 @@ behavior of the DRD tool itself: Data races that occur between a statement at the end of one thread and another thread can be missed if memory access information is discarded immediately after a thread has been joined. This option - allows to specify for how many joined threads memory access information + allows one to specify for how many joined threads memory access information should be retained. @@ -455,7 +455,7 @@ behavior of the DRD tool itself: Perform segment merging only after the specified number of new segments have been created. This is an advanced configuration option - that allows to choose whether to minimize DRD's memory usage by + that allows one to choose whether to minimize DRD's memory usage by choosing a low value or to let DRD run faster by choosing a slightly higher value. The optimal value for this parameter depends on the program being analyzed. The default value works well for most programs. @@ -1028,7 +1028,7 @@ available macros and client requests are: applications contain intentional races. There exist e.g. applications where the same value is assigned to a shared variable from two different threads. It may be more convenient to suppress such races than to solve - these. This client request allows to suppress such races. + these. This client request allows one to suppress such races. @@ -1069,7 +1069,7 @@ available macros and client requests are: The client request VG_USERREQ__DRD_START_TRACE_ADDR, - which allows to trace all load and store activity for the specified + which allows one to trace all load and store activity for the specified address range. @@ -1393,7 +1393,7 @@ More information about Boost.Thread can be found here: OpenMP stands for Open Multi-Processing. The OpenMP standard consists of a set of compiler directives for C, C++ and Fortran programs that allows a compiler to transform a sequential program into a -parallel program. OpenMP is well suited for HPC applications and allows to +parallel program. OpenMP is well suited for HPC applications and allows one to work at a higher level compared to direct use of the POSIX threads API. While OpenMP ensures that the POSIX API is used correctly, OpenMP programs can still contain data races. So it definitely makes sense to verify OpenMP programs diff --git a/gdbserver_tests/mchelp.stdoutB.exp b/gdbserver_tests/mchelp.stdoutB.exp index d962e67870..f8582de345 100644 --- a/gdbserver_tests/mchelp.stdoutB.exp +++ b/gdbserver_tests/mchelp.stdoutB.exp @@ -87,7 +87,7 @@ debugging valgrind internals monitor commands: Valgrind internal host status/memory v.translate [] : debug translation of with (default traceflags 0b00100000 : show after instrumentation) - An additional flag 0b100000000 allows to show gdbserver instrumentation + An additional flag 0b100000000 allows one to show gdbserver instrumentation memcheck monitor commands: xb [] prints validity bits for (or 1) bytes at