Anther

Зачем нужны header guards если в заголовочных файлах мы пишем только объявление функции?

Не всегда мы пишем только объявления. Иногда мы там пишем определения, например определяем структуры, или псевдонимы типов (typedef). Повторное определение таких вещей -- ошибка. Тут ты можешь сказать: "но я подключаю хедер в каждый исходник только один раз". Да, пока проект простой можно это отследить. Но когда одни хедеры начинают подключать другие хедеры это становится делать сложнее. header guards упрощают развитие проекта.
Иногда между хедерами бывают циклические зависимости, header guards позволяют разорвать цикл.

Строковый литерал " ab " находится в особом сегменте данных, который (если процессор и ОС позволяют) только для чтения. А память сегмента данных освободить и сделать «кучей» нельзя.

Если предположить, что текст " ab " находится в «куче» — эта самая куча является сложной структурой данных и память выделяется с выравниванием. Потому функция realloc может (но не обязана) отдать конец или приделать память к концу. Отдать начало будет сложнее, и ни одна известная мне библиотека функций на это не способна.

Кроме того, Си++ придумал объект string_view именно для этого — чтобы передавать строки в функцию, абстрагируясь от выделения памяти и даже от оконечного нуля. Потому у string_view нет функции c_str().

Разумеется, вы можете сделать что-то вроде

char* str2 = str + 2;
str2[2] = '\0';
// А str оставь, уничтожать как-то придётся

Разумеется, если str находится в куче. Сегмент с литералами, напоминаю, только для чтения, и в ОС вроде DOS, где менять можно, такая замена может вызвать нехорошие побочки.

Потому что массив так нельзя вернуть из функции. Сейчас вы просто возвращаете указатель. Пока указатель находится в функции getMas он действительно указывает на массив. Как-только вы вышли из getMas стек схлопнулся (ваш массив находится на стеке) и память, где раньше лежал массив стала не действительной.
После вызова первого printf, та же память на стеке, которую когда-то занимал ваш массив выделилась под нужды printf, и printf заполнила эту память чем-то своим, поэтому в третьем printf у вас фигня.
Программа у вас не вываливается с ошибкой, потому что в стеке память всегда выделена. "Схлопывание стека" - это просто уменьшение/увеличение регистра указателя на стек.

У вас есть 2 вариант.
1. Простой - выделить массив в main, передать его в getMas. Из getMas уже можете ничего не возвращать, только заполняете там массив.
2. Выделяете динамический массив в getMas с помощью malloc. В main не забудьте освободить память, выделенную для массива. Это плохой вариант, т.к. память выделяется на одном уровне программы, а освобождается на другом. Но в вашей простой задаче можно пока на это не обращать внимания.

Хабр всегда делал основную ставку на мобильную версию сайта по адресу https://m.habr.com
Приложение было создано по принципу: "А давайте наша студия вам бесплатно приложение сделает, а вы нам бесплатно корпоративный блог выделите". Со временем эта студия утратила интерес к доработке приложения и в нем накопилось критическое число недоработок. Устаревание сертификата безопасности поставило точку в его существовании.

Разберём pygame.display.set_mode((800, 600)):

• pygame - имя модуля. Модули могут содержать классы, фунции, переменные. Можно прочитать, например, здесь
  
• display (pygame.display) - класс модуля pygame. Обычный класс в каком-то файле модуля. Как из вашего примера про Person и Student
  
• set_mode (pygame.display.set_mode) - функция в этом классе
  

Например, создадим файл test.py:

class Person():   # аналог display
    b = lambda x: x**2
    def count(a):   # аналог set_mode
        return 3 * a

Тогда верна следующая конструкция (для любого файла в той же директории):

import test
print( test.Person.count(2) )  # выведет 6

Так что это работает не так, как вы предложили.
set_mode это функция, а не класс - функция в классе display.