Может ли реализация структуры данных узнать, находится ли она в куче или нет?

Вот простая функция is_on_stack (addr):

int *stack_start = nullptr;

bool is_on_stack(void* ptr) {
  int stack_probe;  
  if( stack_start < &stack_probe  )
    return stack_start < ptr && ptr < &stack_probe; // stack grows upwards;
  else 
    return &stack_probe < ptr && ptr < stack_start; // stack grows downwards;
}

int main() {
  int stack_probe = 0;
  stack_start = &stack_probe;

  int dummy;

  bool r1 = is_on_stack(&dummy); // shall be true

  int* heap_thing = (int*)malloc(sizeof(int));

  bool r2 = is_on_stack(heap_thing); // shall be false         
}

Ключевым моментом здесь являются следующие строки в начале функции main ():

  int stack_probe = 0;
  stack_start = &stack_probe;

Реализация структуры данных на C не должна ничего освобождать, если это не было явно сказано. Типичная реализация связанного списка может иметь такие функции, как «создать узел», «вставить узел в список здесь», «удалить узел из списка» и «уничтожить узел». Ни один из них не требует проверки стека или кучи. Обычно единственное, что может быть в стеке, - это указатели на начало и конец всего списка; даже то, что вы также можете выделять и освобождать функции API, которые вы разрабатываете (и использовать кучу).

Если вы действительно хотите создать навязчивый связанный список, в котором узлы могут храниться в стеке, мы могли бы поговорить и об этом, но, учитывая информацию, которую вы опубликовали, я сомневаюсь, что это так.

В любом случае нет портативного решения, чтобы узнать, есть ли что-то в стеке или куче, но есть некоторые специфические для платформы уловки, которые вы можете увидеть здесь: Как узнать, указывает ли указатель на кучу или стек? - обратите внимание, что для Назначение класса крайне маловероятно, что вам понадобится что-либо из этого.

... Я не могу передать что-то (isOnHeap), чтобы указать, поместил ли вызывающий объект память в кучу

Это время от времени возникает, но не совсем в этом контексте. Проблема обычно проявляется из-за разных версий библиотеки времени выполнения. Проблема в том, что библиотека выделяет блок, который вызывающий должен освободить.

Пример проблемы можно увидеть в функциях Windows Net API. Например, предположим, что вы вызываете NetGroupEnum функция для перечисления групп. Библиотека выделит структуру GROUP_INFO_*. После того, как вызывающая сторона завершит работу со структурой, ее обязанность вызвать библиотеку функция NetApiBufferFree.

В этом случае в проекте должны быть предусмотрены функции распределения и удаления. Тогда ваши подпрограммы просто распределяются с подпрограммами, предоставленными кем-то другим; а затем удаляет с помощью подпрограмм, когда объект больше не нужен.

И чтобы ответить на исходный вопрос, обычно можно выяснить, где было сделано распределение. Но стек по сравнению с кучей обычно не имеет значения.

Обычно узлы связанного списка создаются динамически и размещаются в куче. Однако, если вы решите поместить узел, уже находящийся в стеке, в список, вы нарушите это предположение. Я предполагаю, что вы задаетесь этой ситуацией.

Затем, в зависимости от реализации библиотеки, free может ничего не делать, а просто регистрировать доступную память, если она находится в куче. И если память окажется в стеке, она может сделать что угодно. Или может выдать ошибку и выйти. Но это не определено.