From 1731958c64c57365b00597b3678ae4400d433cb4 Mon Sep 17 00:00:00 2001 From: Ivan Maidanski Date: Thu, 25 Nov 2021 21:25:48 +0300 Subject: 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. --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index 8a42ccf6..4db555c4 100644 --- a/README.md +++ b/README.md @@ -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. -- cgit v1.2.1