(ну как, поддерживали на момент нормальной поддержки ++11 в трех мейнстримных компилях)

Так они его стандартизировали? Не знал

нет, оно до сих пор в лимбо

стандарно де факто, но не де юре

Слова не мальчика, но Джона Лакоса, но не все и не всегда так делают, могут делать или даже хотят делать.

И еще момент
Зачем в gcc отравили
malloc и calloc

Они как-то переназначены?
Я не нашел этой инфы закостылил сам

Могу предположить что т.к. gcc собирается плюсовым компилятором и частично имеет плюсовый код, они боятся что кто-то не вызовет конструктор при работе через malloc. Ну либо просто вычищают сишные рудименты (не уверен что с той стороны заходят, но им виднее)

они же идут из  libc

Вот да, даже общая часть
gcc/c-family/ частично на плюсах написана
И по стандарту он все g++ собирает
Есть ли возможность писать на чистом С или такая возможность только в linux kernel разработке осталась?

И что это значит?

что их предоставляет libc

а что значит “зачем отравили”?

Нельзя их использовать......

*попытка использовать выбивает
attempt to use poisoned malloc/calloc

ну объяснение выше вполне логичноее,  чтобы не ломать RAII

А вот и решение прямо из сорцов гцц


/* As the last action in this file, we poison the identifiers that
  shouldn't be used.  Note, luckily gcc-3.0's token-based integrated
  preprocessor won't trip on poisoned identifiers that arrive from
  the expansion of macros.  E.g. #define strrchr rindex, won't error
  if rindex is poisoned after this directive is issued and later on
  strrchr is called.
  Note: We define bypass macros for the few cases where we really
  want to use the libc memory allocation routines.  Otherwise we
  insist you use the "x" versions from libiberty.  */

#define really_call_malloc malloc
#define really_call_calloc calloc
#define really_call_realloc realloc

нужно всего лишь напрячься чуть-чуть

Та пока так и сделал
Просто хотел узнать
Зачем было его отравлять...

документация гцц как обычно очень детально и с примерами описывает гребаное ничего