3

I'm working on a malloc implementation as a school exercise, using mmap.

I would like to compute the size of my block of memory, in my free list, by using the address of the metadata.

But I am not sure this solution would be well-defined inside the C standard, I didn't find a reference on whether or not the mmap allocated region is considered an "object" in the meaning of that part of the C standard :

§6.5.8.5 (quote taken from that answer to a somewhat related question) :

When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object or incomplete types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. In all other cases, the behavior is undefined.

In other words, can I consider the mmap region as a array of bytes (or char) within the standard ?

VannTen
  • 441
  • 2
  • 12
  • You can look at emacs' garbage collector to see how it implemented allocation internally. It uses a red black tree and each node is a segment of 8K. The pointers to each segment are compared in GC process. – alinsoar Mar 12 '19 at 13:11

2 Answers2

1

Yes you can do so reasonably, as an object of having initially no effective type - as otherwise the mmap system call would be completely useless and one could expect that a C compiler targetting a POSIX system should not render mmap useless...

1

The C Standard only describes the semantics of pointers formed in certain ways. Implementations are free to assign whatever semantics they see fit to pointers formed in other ways. According to the authors of the Standard, the Spirit of C includes the fundamental principle "Don't prevent the programmer from doing what needs to be done", and they presumably intended that quality implementation intended to be suitable for various tasks should avoid imposing needless obstacles to programmers attempting to accomplish those tasks. That would suggest that if a quality implementation defines ways of creating pointers to regions of storage that are not associated with objects of static, automatic, or allocated duration, it should process such pointers usefully even though the Standard would not require it to do so.

Unfortunately, compiler writers are not always clear about the range of purposes for which their compilers are designed to be suitable when configured in various ways. There are many situations where compilers will describe the behavior of a category of actions in more detail than required by the Standard, but the Standard will characterize an overlapping category of actions as invoking UB. Some compiler writers think that UB merely means that the Standard imposes no requirements, but behavioral descriptions that go beyond those required by the Standard should be unaffected. Others view the fact that an action invokes UB as overriding all other behavioral descriptions.

Actions involving addresses that are allocated in ways that the implementations don't understand are only going to be defined to the extent described by the implementations. On some implementations, the fact that the Standard would characterize e.g. comparisons involving unrelated pointers as UB should be viewed as irrelevant, since the Standard doesn't say anything about how such pointers will behave. On others, the fact that the standard characterizes some actions as UB would dominate, however. Unfortunately, it's hard to know which scenario would apply in any particular situation.

supercat
  • 77,689
  • 9
  • 166
  • 211