История изменений
Исправление Vic, (текущая версия) :
Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно
va_list – это как раз кросплатформенно, т.к. все «__синонимы» в конце-концов ведут к встроенной в компилятор фиче, потому что как входные параметры располагаются в бинарном виде зашито в компилятор для конкретной платформы (железа, ОС и пр.). В, условно, «си для arm» действуют одни соглашения, в каком-нибудь «си для STM32» действуют другие соглашения. Более того, даже для ядра и для юзерспэйс могут действовать разные соглашения по расположению входных параметров в функциях, т.к. эту часть в извращениях ни кто не ограничивает (только регламентируют, что бы уж совсем не было бардака).
Я вообще встречал компиляторы, где для передачи параметров используются разные стеки: аппаратный (в процессоре) и программный в ОЗУ (т.к. аппаратный стек мал, но работает быстрее чем ОЗУ).
The system stack is always located in on-chip RAM, which is faster than external RAM but is limited in size.
Относись к va_list как более-менее «стандартному» интерфейсу, который предоставляет компилятор для доступа к каждому входному параметру функции. В принципе, если хочешь, можешь свой изобрести, но кроме тебя его ни кто не поймет.
Исправление Vic, :
Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно
va_list – это как раз кросплатформенно, т.к. все «__синонимы» в конце-концов ведут к встроенной в компилятор фиче, потому что как входные параметры располагаются в бинарном виде зашито в компилятор для конкретной платформы (железа, ОС и пр.). В, условно, «си для arm» действуют одни соглашения, в каком-нибудь «си для STM32» действуют другие соглашения. Более того, даже для ядра и для юзерспэйс могут действовать разные соглашения по расположению входных параметров в функциях, т.к. эту часть в извращениях ни кто не ограничивает (только регламентируют, что бы уж совсем не было бардака).
Я вообще встречал компиляторы, где для передачи параметров используются разные стеки: аппаратный (в процессоре) и программный в ОЗУ (т.к. аппаратный стек мал, но работает быстрее чем ОЗУ).
The system stack is always located in on-chip RAM, which is faster than external RAM but is limited in size.
Относись к va_list как более-менее «стандартному» интерфейсу для доступа к каждому входному параметру. В принципе, если хочешь, можешь свой изобрести, но кроме тебя его ни кто не поймет.
Исправление Vic, :
Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно
va_list – это как раз кросплатформенно, т.к. все «__синонимы» в конце-концов ведут к встроенной в компилятор фиче, потому что как входные параметры располагаются в бинарном виде зашито в компилятор для конкретной платформы (железа, ОС и пр.). В, условно, «си для arm» действуют одни соглашения, в каком-нибудь «си для STM32» действуют другие соглашения. Более того, даже для ядра и для юзерспэйс могут действовать разные соглашения по расположению входных параметров в функциях, т.к. эту часть в извращениях ни кто не ограничивает (только регламентируют, что бы уж совсем не было бардака).
Я вообще встречал компиляторы, где для передачи параметров используются разные стеки: аппаратный (в процессоре) и программный (т.к. аппаратный стек мал).
Относись к va_list как более-менее «стандартному» интерфейсу для доступа к каждому входному параметру. В принципе, если хочешь, можешь свой изобрести, но кроме тебя его ни кто не поймет.
Исправление Vic, :
Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно
va_list – это как раз кросплатформенно, т.к. все «__синонимы» в конце-концов ведут к встроенной в компилятор фиче, потому что как входные параметры располагаются в бинарном виде зашито в компилятор для конкретной платформы (железа, ОС и пр.). В, условно, «си для arm» действуют одни соглашения, в каком-нибудь «си для STM32» действуют другие соглашения. Более того, даже для ядра и для юзерспэйс могут действовать разные соглашения по расположению входных параметров в функциях, т.к. эту часть в извращениях ни кто не ограничивает (только регламентируют, что бы уж совсем не было бардака).
Относись к va_list как более-менее «стандартному» интерфейсу для доступа к каждому входному параметру. В принципе, если хочешь, можешь свой изобрести, но кроме тебя его ни кто не поймет.
Исходная версия Vic, :
Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно
va_list – это как раз кросплатформенно, т.к. все «__синонимы» в конце-концов ведут к встроенной в компилятор фиче, потому что как входные параметры располагаются в бинарном виде зашито компилятор для данной платформы. В, условно, «си для arm» действуют одни соглашения, в каком-нибудь «си для STM32» действуют другие соглашения. Более того, даже для ядра и для юзерспэйс могут действовать разные соглашения по расположению входных параметров в функциях, т.к. эту часть в извращениях ни кто не ограничивает (только регламентируют, что бы уж совсем не было бардака).
Относись к va_list как более-менее «стандартному» интерфейсу для доступа к каждому входному параметру. В принципе, если хочешь, можешь свой изобрести, но кроме тебя его ни кто не поймет.