Функции - передача параметров

[220Volt]

Изучал передачу параметров в функции через стек и остался очень удивленным (может баг компилятора?). Я считал что порядок аргументов в стеке строго регламентирован (__cdecl, __stdcall, ...) и стек растет квантами по 4 байта, т.е. для 5 байтовый массив займет в стеке 8 байт. Следующий код разрушил все мои представления:

#include <stdio.h>

// Запускал у себя, gcc 4.8.1
void __cdecl fn(char c1, char c2)
{
    printf( "char args: %d\n", int((long long)&c1 - (long long)&c2) );
}

void __cdecl fn2(int c1, int c2)
{
    printf( "int args: %d\n", int((long long)&c1 - (long long)&c2) );
}

int main ()
{
    fn(2,3);
    fn2(2,3);
  
    return 0;
}
// char args: 4
// int args: -4

clang 3.4:

char args: 1
int args: 4

MSVC:

char args: -4
int args: -4

Не соблюдается ни порядок аргументов ни одинаковые принципы роста стека под аргументы. В принципе не проблема если все компилировать одним компилятором, но как писать библиотеки?

[_Bers]

Сообщение от 220Volt

Не соблюдается ни порядок аргументов ни одинаковые принципы роста стека под аргументы. В принципе не проблема если все компилировать одним компилятором, но как писать библиотеки?

Порядок вычисления аргументов функции это - US (unspecified behavior).

Это означает "хер знает, как именно компилятор их там пакует и вычисляет, но проблемы мы не ожидаем".

На практике проблемы начинаются при попытке сишными хаками пытаться дотянуться до аргументов прямо на стеке функции (да да, именно так, как это сделали вы - нельзя).

Какие нибудь константные аргументы он вообще может закинуть куда нибудь в регистры только чтения и попытка взять адрес завершится аварией.

К слову: я када то пробовал исследовать входные аргументы на стеке функции компилятором мелкомягких, методом научного тыка установил - в зависимости от различных типов аргументов функции, они могут располагаться по самым разным адресам. И далеко не факт, что это будет непрерывный блок памяти.

void Foo(int v, int po)
{
    int* p = &v;
    ++p;

    int b = *p; //<--- думаете попали на переменную po? А это далеко не факт.
}

Что бы лазить по стеку существует православный сишный костыль - макросы: va_list, va_start, va_end

//пример использования
int my_printf(const char * format,...) {
    va_list arg_list;
    int result;
    va_start( arg_list, format );
    result = vprintf(format, arg_list);
    va_end( arg_list );
    return result;
}

#define debug(format, ...)  printf(stderr, format, __VA_ARGS__) //ISO C 1999.
#define debug(format, args...)  printf(stderr, format, args) //расширение гцц
#define debug(format, ...)  printf(stderr, format, ## __VA_ARGS__)  //расширение гцц

[220Volt]

Это какая-то магия )). Подключил к приложению написанному на MSVC dll (написанную на gcc), думал будут какие-нибудь косяки с аргументами. Не знаю как, но все правильно связалось.

[Son Of Pain]

Сообщение от _Bers

Порядок вычисления аргументов функции это - US (unspecified behavior).

Дело не в порядке вычисления, а в порядке складывания аргументов в стек. И он как раз четко задан в calling convention. cdecl значит "никаких констант в регистрах, все только в стеке, справа налево".

По теме:
1) Майкрософтовский компилятор сделал все предсказуемо (4 байта разницы, как и должно быть при выравнивании на 4).
2) gcc в первой функции зачем-то сделал так:

                mov     edx, [ebp+a]
                mov     eax, [ebp+b]
                mov     [ebp+var_C], dl
                mov     [ebp+var_10], al
                lea     edx, [ebp+var_10]
                lea     eax, [ebp+var_C]
                sub     edx, eax
                mov     eax, edx
                mov     [esp+18h+var_14], eax
                mov     [esp+18h+var_18], offset aCharArgsD ; "char args: %d\n"
                call    printf

т.е. сначала положил переданные значения во временные переменные, и потом уже сравнил их адреса. При этом порядок оригиналов в стеке и их выравнивание такие же, как у msvc; потому, очевидно, дллка и прилинковалась без проблем - ей-то без разницы, что там внутри функции происходит, лишь бы cdecl соблюдался.
У гцц много подобных идиосинкразий в кодогенераторе, потому не ищи в этом смысла. Если собрать со включенной оптимизацией - результат станет правильным (-4 -4).

3) Ну а шланга у меня под рукой нет. Подозреваю, что он поступил как и gcc.

p. s. Дизассемблер - очень полезная штука в таких случаях, да.

[220Volt]

Спасибо, теперь ясно. Я уже подумал что соглашения о вызовах отменили ))

[Пепел Феникса]

Сообщение от Son Of Pain

Дело не в порядке вычисления, а в порядке складывания аргументов в стек. И он как раз четко задан в calling convention. cdecl значит "никаких констант в регистрах, все только в стеке, справа налево".

компилятор не обязан вам отдавать адреса аргументов.
он может создать временные переменные для применения аргументов.

[_Bers]

Сообщение от Son Of Pain

Дело не в порядке вычисления, а в порядке складывания аргументов в стек. И он как раз четко задан в calling convention. cdecl значит "никаких констант в регистрах, все только в стеке, справа налево".

Создайте кортеж с самыми разнообразными типами данных: инты, указатели, классы, и тп.

А потом попытайтесь вытащить эти типы со стека:

void Foo(std::tuple<int,int*,some, void()>& tuple)
{
     char* ptr =  (char*)&tuple)); //<--- зацепили адрес первого аргумента

     int a1 = *((int*)ptr); //вытащили первый аргумент
   
     //сможете вытащить все остальное?
}

Так, что бы это работало и в релизе тоже. И что бы это было гарантированно валидно.

Я когда то (с++03) изготавливал делегаты.

Одно из требований к дизайну было - простота использования.
Поэтому делегат был не шаблонном класса, а обычным.

Все факты использования шаблонов прятались за счет вывода типов аргументов из аргументов функций:

//внешне пользователь даже и не замечает, что имеет дело с шаблонами
Connector connnect(obj, &some::method, a1,a2);

...

connnect(); //запуск эквивалентен: obj.method(a1,a2);

struct Connector
{

   template<class C, class F, class A1, class A2>
   Connector(C& obj, F method, A1& a1, A2& a2)
   {       //(считайте это псевдокодом)

       //здесь мне известен объект от имени которого будет запуск
       //известен метод, который нужно запустить
       //и аргументы, с которыми нужно сделать запуск

       //я передаю ему указатель на самый первый аргумент в стеке
       //вместо того, что бы передавать все аргументы
       mConnector = new TConnector<C,F,A1,A2>(&obj); 

   }
};

Я не буду сейчас приводить всю схему. Смысл в том, что в шаблоно-конструкторе инстанцировался класса,экземпляр которого будет отвечать собственно за запуски функций-целей, и ему нужно было передавать ссылку на объект, на метод, на все аргументы.

Там под капотом аргументы могут пройти по целой цепочке функций, пока дойдут до окончательного шаблоно-исполнителя.

Вопрос: как это сделать так, что бы по возможности избежать лишних копирований аргументов?


Я думал, что проще просто передать адрес, откуда якобы начинается самый первый аргумент функции.

Конечный исполнитель зная точно с какими типами данных он работает, мог бы вытряхнуть все остальные данные прямо со стека функции.

И это действительно работало. Правда только в дебаг-версии, и то - далеко не всегда. Если все аргументы инты - вроде бы работало.
Стоит подмешать туда какой нибудь указатель, и вместо него при извлечении получался мусор.

Про релиз версию вообще молчу.


Я так и не разобрался до конца с этим вопросом.
Мой тимлид мне порекомендовал не пытаться оптимизировать на спичках, изготавливая мутные и потенциально небезопасные хаки на грани UB

А вместо этого сделать так:

struct Connector
{

   template<class C, class F, class A1, class A2>
   Connector(C& obj, F method, A1& a1, A2& a2)
   {      
       //не заниматься херней
       mConnector = new TConnector<C,F,A1,A2>(&obj, method,a1,a2); 

   }
};

Впрочем, я изучая этот вопрос, я читал о функциях-элипсах:

void Foo( ... );

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

Поэтому, собственно, я бросил заниматься этой ерундой и больше никогда не пытался сишными хаками долбать стек.

[waleri]

Сообщение от 220Volt

Я уже подумал что соглашения о вызовах отменили

Их никогда и не было - это все извраты отдельных компиляторов.