Откуда взялось число 4 ГБ в адресном пространстве 32-битных систем
Что проверяют
Понимаете ли вы, откуда берутся технические лимиты, с которыми сталкиваетесь в работе, и умеете ли вывести число, а не вспомнить его. Для тестировщика это ещё и про граничные значения: почти все известные переполнения растут из тех же степеней двойки.
Как отвечать
Адрес в 32-битной системе это 32 бита, значит разных адресов ровно два в тридцать второй степени, то есть 4 294 967 296. Адресуется байт, поэтому и объём получается четыре гигабайта, диапазон от нуля до 4 294 967 295. Другой причины у числа нет, это просто разрядность указателя.
Дальше стоит уточнить два места, где ответ обычно упрощают.
Первое: это виртуальное адресное пространство процесса, а не объём оперативной памяти. Часть диапазона забирает ядро, и сколько достаётся пользовательской части, зависит от операционной системы и её настроек, у разных систем деление разное. Ещё часть адресов занята под устройства, поэтому на 32-битной системе с четырьмя гигабайтами планок доступно заметно меньше.
Второе: расширения вроде PAE позволяют системе использовать больше физической памяти, но одному процессу всё равно доступно не больше своего 32-битного окна.
Для тестирования отсюда прямо вытекают границы: 2 147 483 647 для знакового четырёхбайтного целого, тот же предел для размера файла в старых интерфейсах, и 2038 год для времени в секундах.
Где спотыкаются
Путают объём памяти с разрядностью данных. Число про размер указателя, а не про то, сколько занимает переменная, и 32-битный процесс на 64-битной системе упрётся в тот же предел.
Называют фиксированное деление адресного пространства между приложением и ядром как универсальное. Оно настраиваемое и в разных системах разное, поэтому одну цифру лучше не выдавать за общее правило.
Не связывают ответ с работой. Вопрос задают не ради арифметики: ждут, что вы вспомните про переполнение счётчика, потолок на размер загружаемого файла или падение 32-битного агента на большой выборке.