From 9022098b6ab0b6597eac3d46f0451815b70351b9 Mon Sep 17 00:00:00 2001
From: Brian Dickens <brian@hostilefork.com>
Date: Mon, 26 Feb 2024 14:50:46 -0500
Subject: [PATCH] Move ALIGN() macro out of %c-enhanced.h

Some code wishes to use %c-enhanced.h that has includes that conflict
with this definition of ALIGN() e.g. MacOS SDK.  There's no good
reason to put it in that file, so move it to %mem-pools.h
---
 src/include/c-enhanced.h | 47 ----------------------------------------
 src/include/mem-pools.h  | 47 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/src/include/c-enhanced.h b/src/include/c-enhanced.h
index a887011e78..5d9327e1d7 100644
--- a/src/include/c-enhanced.h
+++ b/src/include/c-enhanced.h
@@ -655,53 +655,6 @@
 #define blockscope NOOP;
 
 
-//=//// ALIGNMENT SIZE ////////////////////////////////////////////////////=//
-//
-// Data alignment is a complex topic, which has to do with the fact that the
-// following kind of assignment can be slowed down or fail entirely on
-// many platforms:
-//
-//    char *cp = (char*)malloc(sizeof(double) + 1);
-//    double *dp = (double*)(cp + 1);
-//    *dp = 6.28318530718
-//
-// malloc() guarantees that the pointer it returns is aligned to store any
-// fundamental type safely.  But skewing that pointer to not be aligned in
-// a way for that type (e.g. by a byte above) means assignments and reads of
-// types with more demanding alignment will fail.  e.g. a double often needs
-// to read/write to pointers where `((uintptr_t)ptr % sizeof(double)) == 0`
-//
-// (Note: Often, not always.  For instance, Linux systems with System V ABI
-// for i386 are permitted to use 4 byte boundaries instead of 8 byte for
-// doubles unless you use `-malign-double`.  See page 28 of the spec:
-//
-// http://www.uclibc.org/docs/psABI-i386.pdf
-//
-// Windows 32-bit compilers seem to also permit 4 bytes.  WebAssembly does
-// not seem to work when doubles are on 4 byte boundaries, however.)
-//
-// The C standard does not provide a way to know what the largest fundamental
-// type is, even though malloc() must be compatible with it.  So if one is
-// writing one's own allocator to give back memory blocks, it's necessary to
-// guess.  We guess the larger of size of a double and size of a void*, though
-// note this may not be enough for absolutely any type in the compiler:
-//
-//    "In Visual C++, the fundamental alignment is the alignment that's
-//    required for a double, or 8 bytes. In code that targets 64-bit
-//    platforms, it's 16 bytes.)
-//
-
-#define ALIGN_SIZE \
-    (sizeof(double) > sizeof(void*) ? sizeof(double) : sizeof(void*))
-
-#if defined(__HAIKU__)
-    #undef ALIGN
-#endif
-
-#define ALIGN(s,a) \
-    (((s) + (a) - 1) & ~((a) - 1))
-
-
 //=//// C FUNCTION TYPE (__cdecl) /////////////////////////////////////////=//
 //
 // Note that you *CANNOT* cast something like a `void *` to (or from) a
diff --git a/src/include/mem-pools.h b/src/include/mem-pools.h
index 033ea7427f..180b40993c 100644
--- a/src/include/mem-pools.h
+++ b/src/include/mem-pools.h
@@ -32,6 +32,53 @@
 //
 
 
+//=//// ALIGNMENT SIZE ////////////////////////////////////////////////////=//
+//
+// Data alignment is a complex topic, which has to do with the fact that the
+// following kind of assignment can be slowed down or fail entirely on
+// many platforms:
+//
+//    char *cp = (char*)malloc(sizeof(double) + 1);
+//    double *dp = (double*)(cp + 1);
+//    *dp = 6.28318530718
+//
+// malloc() guarantees that the pointer it returns is aligned to store any
+// fundamental type safely.  But skewing that pointer to not be aligned in
+// a way for that type (e.g. by a byte above) means assignments and reads of
+// types with more demanding alignment will fail.  e.g. a double often needs
+// to read/write to pointers where `((uintptr_t)ptr % sizeof(double)) == 0`
+//
+// (Note: Often, not always.  For instance, Linux systems with System V ABI
+// for i386 are permitted to use 4 byte boundaries instead of 8 byte for
+// doubles unless you use `-malign-double`.  See page 28 of the spec:
+//
+// http://www.uclibc.org/docs/psABI-i386.pdf
+//
+// Windows 32-bit compilers seem to also permit 4 bytes.  WebAssembly does
+// not seem to work when doubles are on 4 byte boundaries, however.)
+//
+// The C standard does not provide a way to know what the largest fundamental
+// type is, even though malloc() must be compatible with it.  So if one is
+// writing one's own allocator to give back memory blocks, it's necessary to
+// guess.  We guess the larger of size of a double and size of a void*, though
+// note this may not be enough for absolutely any type in the compiler:
+//
+//    "In Visual C++, the fundamental alignment is the alignment that's
+//    required for a double, or 8 bytes. In code that targets 64-bit
+//    platforms, it's 16 bytes.)
+//
+
+#define ALIGN_SIZE \
+    (sizeof(double) > sizeof(void*) ? sizeof(double) : sizeof(void*))
+
+#if defined(__HAIKU__)
+    #undef ALIGN
+#endif
+
+#define ALIGN(s,a) \
+    (((s) + (a) - 1) & ~((a) - 1))
+
+
 // Linked list of used memory segments
 //
 typedef struct SegmentStruct {