diff options
author | Ivan Maidanski <ivmai@mail.ru> | 2021-11-25 21:25:48 +0300 |
---|---|---|
committer | Ivan Maidanski <ivmai@mail.ru> | 2021-11-25 21:25:48 +0300 |
commit | 1731958c64c57365b00597b3678ae4400d433cb4 (patch) | |
tree | f3b362665a893ca25eb878aa1901a7a57485e72a | |
parent | dff23b50b747cba4b46285b1f2ad257f52662f20 (diff) | |
download | bdwgc-1731958c64c57365b00597b3678ae4400d433cb4.tar.gz |
Quote all mentioned header files in README.md and debugging.md
* README.md (The C Interface to the Allocator,
The C++ Interface to the Allocator): Wrap all (remaining) mentioned .h
files in apostrophes.
* doc/debugging.md (Unexpectedly Large Heap): Likewise.
-rw-r--r-- | README.md | 6 | ||||
-rw-r--r-- | doc/debugging.md | 4 |
2 files changed, 5 insertions, 5 deletions
@@ -384,7 +384,7 @@ If only `GC_malloc` is intended to be used, it might be appropriate to define: #define malloc(n) GC_malloc(n) #define calloc(m,n) GC_malloc((m)*(n)) -For small pieces of VERY allocation intensive code, gc_inline.h includes +For small pieces of VERY allocation intensive code, `gc_inline.h` includes some allocation macros that may be used in place of `GC_malloc` and friends. @@ -393,7 +393,7 @@ To avoid name conflicts, client code should avoid this prefix, except when accessing garbage collector routines. There are provisions for allocation with explicit type information. -This is rarely necessary. Details can be found in gc_typed.h. +This is rarely necessary. Details can be found in `gc_typed.h`. ## The C++ Interface to the Allocator @@ -410,7 +410,7 @@ first (gccpp) or the second one (gctba), but not both. See gc_cpp.h and This interface tries to approximate the Ellis-Detlefs C++ garbage collection proposal without compiler changes. -Very often it will also be necessary to use gc_allocator.h and the +Very often it will also be necessary to use `gc_allocator.h` and the allocator declared there to construct STL data structures. Otherwise subobjects of STL data structures will be allocated using a system allocator, and objects they refer to may be prematurely collected. diff --git a/doc/debugging.md b/doc/debugging.md index c43c355c..a377f3b6 100644 --- a/doc/debugging.md +++ b/doc/debugging.md @@ -144,8 +144,8 @@ Growing data structures can usually be identified by: be identified by their allocation site, 3. Running the application long enough so that most of the heap is composed of "leaked" memory, and - 4. Then calling `GC_generate_random_backtrace` from gc_backptr.h a few times - to determine why some randomly sampled objects in the heap are being + 4. Then calling `GC_generate_random_backtrace` from `gc_backptr.h` a few + times to determine why some randomly sampled objects in the heap are being retained. The same technique can often be used to identify problems with false pointers, |