[P&AM Lab] crypti printf questions
Grigoriy A. Sitkarev
sitkarev на komitex.ru
Вт Апр 16 11:37:28 MSK 2013
Борис Липин wrote:
> Я подумал что с такой интерфейс выглядит более стандартным и каноничным.
> В конечном итоге ведь и printf(3) функции могли реализовать как то вроде:
> printf(char *fmt, void *args, int nargs).
Могли бы, но не стали, потому что при передаче аргументов достаточно
поместить их в регистры и/или стек в соответствии с ABI; что,
собственно, и делает компилятор, когда генерирует код передачи
аргументов функции. Если бы мы передавали там args и nargs, то здесь ещё
кто-то должен бы был выделить память для массива, поместить в массив
аргументы. Это существенно бы затруднило переносимость программ и
усложнило бы окружение времени исполнения.
В этом прелесть Си, -- требования к окружению времени выполнения
минимальные и могут быть обрезаны по желанию программиста в соответствии
с требованиями его программ.
> Спасибо за ответ, наверное я действительно немного не прав относительно интерфейса функций.:)
>
> А вообще есть возможность сделать преобразование array -> va_list или запихать массив в функции с переменным количеством параметров *стандартными средствами* или эта ситуация - совсем не то для чего они используются и о таких вопросах не стоит задумываться?
Этого делать не нужно. По сути va_list с его макросами -- это доступ к
кадру стека, где хранятся аргументы. Он не предназначается для хранения
каких-то иных данных и/или ссылок на них. Всё это, конечно, можно
осуществить, на то у нас и ассемблерные вставки есть и Си позволит это
сделать, но тогда нужно реализовывать такой финт для каждого ABI и
аппаратной платформы. Здесь без аппаратных привязок не обойтись. Короче
говоря, не для того он делался. Нужно было сделать переносимые макросы
для доступа к кадру стека и извлечения из него аргументов, вот и всё.
--
Г.А.
Подробная информация о списке рассылки Lab