[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