Ни о какой безапелляционности в моих высказываниях не может быть и речи!

Первая задача достаточно проста.

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

From:

Да, это верно. Давайте предположим, что все аргументы передаются через стек. Update: думаю, что на практике это можно навязать с помощью volatile.

Edited Date: 2009-09-17 09:48 am (UTC)

From:

Да, все правильно, согласен также с использованием вызова функции (его можно устроить рекурсивным, если хочется). Полагаться на порядок расположения локальных переменных не хочется.

From:

1. тривиально (см ответ первого ответившего)
2. от локальных автоматических переменных всегда сама функция,
от переданных параметров всегда тот, кто вызывает (если речь идет о C).
Догадайтесь почему, и еще догадайтесь, зачем параметры пихаются
в обратном порядке :)

From:

kcmamu.livejournal.com

А разве невозможны архитектура и компилятор, обходящиеся вообще без стека?

From:

Вторая вообще не загадка, поскольку может быть
только один вариант (догадайтесь почему)

From:

http://www.google.com/search?hl=en&q=stdcall

From:

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

From:

да, а "очищает" я имел в виду от аргументов, а не локальных переменных - добавил это в условие, чтобы не было неясности.

From:

По любому, это не стандартный C'шный вызов,
для функции с переменным чистом аргументов он
использован быть не может. Более того
обычный C не требует прототипов вызываемых функуций,
а stdcall без прототипов не возможен.
Так что речь о "pure С" не идёт.

From:

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

Из-за возможного разнобоя в количестве параметров стек либо должен чиститься вызывающей функцией, либо в стеке должен передаваться объем блока параметров (и тогда его может чистить вызванная функция). Различить эти два поведения программой на языке С невозможно: дополнительные поля в стековом кадре могут использоваться и для целей, не связанных с передачей параметров (например, сохраненные регистры или exception handlers в VMS/OS/2/Win32)

From:

Это паскалевское соглашение о вызовах, а не cшное.

From:

уже написал :)

From:

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

From:

http://avva.livejournal.com/2137625.html?thread=64932121#t64932121

Скажем, в VMS (не только на ваксе) в блоке параметров всегда передается его размер.

Впрочем, в VMS, насколько я помню, стек всегда чистится вызывающей функцией, но по другой причине - там аргументы могут быть вообще не в стеке. :)

From:

Я знаю что такое stdcall и еще помню времена, когда вместо этого слова использовалось слово PASCAL. :)

From:

mgar.livejournal.com

Не просто не хочется, а будет неправильным - встречались мне компайлеры, которые тасовали переменные как хотели.

From:

Вторая ссылка гугля:
stdcall

The stdcall[1] calling convention is a variation on the pascal calling convention in which parameters are passed on the stack, pushed right-to-left. Registers EAX, ECX, and EDX are designated for use within the function. Return values are stored in the EAX register. The callee is responsible for cleanup of the stack.

Stdcall is the standard calling convention for the Microsoft Win32 API.

From:

cmm.livejournal.com

1. ну понятно
2. единственное что приходит в голову — это проверить работает ли хвостовая рекурсия для функций с постоянным количеством аргументов. если работает, значит функции чистят за собой сами; если нет, то либо копилятор не фонтан, либо чистит зовущий. :)

From:

pascal и stdcall в разном порядке толкают аргументы в стек.

From:

Это не "паскалевское соглашение", как вы написали, а cоглашение, использующееся в c/c++ под windows, и являющееся гибридом паскалевского и cdecl. Я не понимаю, о чем идет спор. Если вы знаете, что под windows (например), функции могут быть скомпилированы как в cdecl, так и в stdcall, и на практике используются оба соглашения, то почему бы не подумать, как я предлагаю, о том, можно ли написать код, различающий эти два случая? К чему весь этот срач в стиле "я знаю о C больше, чем ты"?

I can't believe I'm participating in this jerkfest. Sheesh.

From:

mgar.livejournal.com

1 - элементарно,

2 - делаем следующим образом. Первым делом пишем две функции - первая возвращает current stack (адрес локальной переменной), вторая - dummy function без параметров.

Теперь делаем так - запоминаем current stack, затем вызываем dummy, которую кастингом приводим к функции с одним параметром. Затем снова вызываем current stack. Если оба раза стэк одинаков = мы его и чистим. Если стэк вырос - мы положились на вызываемую функцию.

Теперь осталось только подчистить за собой стек во втором случае.

(Метод не чистый, потому что посередине у нас есть участок кода, где стек не валидный, и теопретически это может нас грохнуть, но по идее там ничего нам из стека не надо...)

PS. А по идее, обе функции - current stack и dummy - могут быть одной и той же.

From: (Anonymous)

2. При вызове сишной функции (то есть такой, которая объявлена без pascal, inline, fastcall и т. д.) стек всегда очищает вызывающий. Иначе бы вот такой (законный) код

int f(...) { return 0; }

int main() { f(1); f(1, 2); f(1, 2, 3); return 0; }

нельзя было бы корректно откомпилировать.

From: