procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add lmalloc commentary and tweak laligned

Browse source 
* src/alloc.c (laligned): Help compiler in a tiny way by putting
the more-commonly-failing disjunct first.
This commit is contained in:
Paul Eggert 2016-02-09 13:43:13 -08:00
parent 7777e8089f
commit f65ef80fed
1 changed files with 11 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/alloc.c
View file

@ -1375,8 +1375,8 @@ lisp_align_free (void *block)
static bool
laligned (void *p, size_t size)
{
return (MALLOC_IS_GC_ALIGNED || size % GCALIGNMENT != 0
|| (intptr_t) p % GCALIGNMENT == 0);
return (MALLOC_IS_GC_ALIGNED || (intptr_t) p % GCALIGNMENT == 0
|| size % GCALIGNMENT != 0);
}
/* Like malloc and realloc except that if SIZE is Lisp-aligned, make
@ -1385,7 +1385,15 @@ laligned (void *p, size_t size)
Lisp-aligned pointer. Code that needs to allocate C heap memory
for a Lisp object should use one of these functions to obtain a
pointer P; that way, if T is an enum Lisp_Type value and L ==
make_lisp_ptr (P, T), then XPNTR (L) == P and XTYPE (L) == T. */
make_lisp_ptr (P, T), then XPNTR (L) == P and XTYPE (L) == T.
On typical modern platforms these functions' loops do not iterate.
On now-rare (and perhaps nonexistent) platforms, the loops in
theory could repeat forever. If an infinite loop is possible on a
platform, a build would surely loop and the builder can then send
us a bug report. Adding a counter to try to detect any such loop
would complicate the code (and possibly introduce bugs, in code
that's never really exercised) for little benefit. */
static void *
lmalloc (size_t size)