использовать проще; ее аргумент является числом байтов, на которое нужно увеличить адресное пространство. Вызвав ее с приращением 0, можно определить, где в настоящее время заканчивается адресное пространство. Таким образом, чтобы увеличить адресное пространство на 32 байта, используется код следующего вида:
char *p = (char*)sbrk(0); /* получить текущий конец адресного
пространства */
if (brk(p + 32) < 0) {
/* обработать ошибку */
}
/* в противном случае, изменение сработало */
Практически,
вам не нужно непосредственно использовать
brk
. Вместо этого используется исключительно
sbrk
для увеличения (или даже сокращения) адресного пространства. (Вскоре мы покажем, как это делать, в разделе 3.2.5. «Исследование адресного пространства».)
Еще более практично вообще никогда не использовать эти процедуры. Программа, которая их использует, не может затем использовать также и
malloc
, и это создает большую проблему, поскольку многие элементы стандартной библиотеки полагаются на использование
malloc
. Поэтому использование
brk
или
sbrk
может приводить к трудно обнаруживаемым крушениям программы.
Но знать о низкоуровневых механизмах стоит, и конечно же, набор функций
malloc
реализован с помощью
sbrk
и
brk
.
3.2.4. Вызовы ленивых программистов:
alloca
«Опасность, Билл Робинсон! Опасность!»
– Робот -
Есть еще одна дополнительная функция выделения памяти, о которой вам нужно знать. Мы обсуждаем ее лишь для того, чтобы вы поняли ее, когда увидите, но не следует использовать ее в новых программах! Эта функция называется
alloca
; она объявлена следующим образом:
/* Заголовок в GNU/Linux, возможно, не на всех Unix-системах */
#include <alloca.h> /* Обычный */
void *alloca(size_t size);
Функция
alloca
выделяет
size
байтов из стека. Хорошо, что выделенная память исчезает после возвращения из функции. Нет необходимости явным образом освобождать память, поскольку это осуществляется автоматически, как в случае с локальными переменными.
На первый взгляд,
alloca
выглядит чем-то типа панацеи для программистов, можно выделять память, о которой можно вовсе не беспокоиться. Подобно Темной Стороне Силы, это, конечно, привлекает. И подобным же образом этого нужно избегать по следующим причинам:
• Функция не является стандартной; она не включена ни в какой стандарт, ни в ISO, ни в С или POSIX.
• Функция не переносима. Хотя она существует на многих системах Unix и GNU/Linux, она не существует на не-Unix системах. Это проблема, поскольку код часто должен быть многоплатформенным, выходя за пределы просто Linux и Unix.
• На некоторых системах
alloca
невозможно даже реализовать. Весь мир не является ни процессором Intel x86, ни GCC.
зависит от машины и от компилятора. На многих системах ее реализация ошибочна. Ее использование не рекомендуется».
• Снова цитируя справку: «На многих системах
alloca
не может быть использована внутри списка аргументов вызова функции, поскольку резервируемая в стеке при помощи
alloca
память оказалась бы в середине стека в пространстве для аргументов функции».
45
alloca(3) — Примеч. науч. ред.
• Она потворствует неряшливому программированию. Тщательная и корректная работа с памятью не сложна; вам просто нужно подумать о том, что вы делаете, и планировать заранее.
GCC обычно использует встроенную версию функции, которая действует с использованием внутритекстового (inline) кода. В результате есть другие последствия
alloca
. Снова цитируя справку:
Факт, что код является внутритекстовым (inline), означает, что невозможно получить адрес этой функции или изменить ее поведение путем компоновки с другой библиотекой.
Внутритекстовый код часто состоит из одной инструкции, подгоняющей указатель стека, и не проверяет переполнение стека. Поэтому нет возврата
NULL
при ошибке.
Справочная страница не углубляется в описание проблемы со встроенной
alloca
GCC. Если есть переполнение стека, возвращаемое значение является мусором. И у вас нет способа сообщить об этом! Это упущение делает невозможным использование GCC
alloca
в устойчивом коде.
Все это должно убедить вас избегать
alloca
в любом новом коде, который вы пишете. В любом случае, если приходится писать переносимый код с использованием
malloc
и
free
, нет причины в использовании также и
alloca
.
3.2.5. Исследование адресного пространства
Следующая программа,
ch03-memaddr.c
, подводит итог всему, что мы узнали об адресном пространстве. Она делает множество вещей, которые не следует делать на практике, таких, как вызовы
alloca
или непосредственные вызовы
brk
и
sbrk
.
1 /*
2 * ch03-memaddr.с --- Показать адреса секций кода, данных и стека,
3 * а также BSS и динамической памяти.
4 */
5
6 #include <stdio.h>
7 #include <malloc.h> /* для определения ptrdiff_t в GLIBC */
8 #include <unistd.h>
9 #include <alloca.h> /* лишь для демонстрации */
10
11 extern void afunc(void); /* функция, показывающая рост стека */
12
13 int bss_var; /* автоматически инициализируется в 0, должна быть в BSS */
14 int data_var = 42; /* инициализируется в не 0, должна быть
15 в сегменте данных */
16 int
17 main(int argc, char **argv) /* аргументы не используются */