Нечетное поведение vsnprintf на AVR ATmega2560

Question

Я работаю над платформой AVR. avr-libc не предоставляет asprintf(). Мне нужна библиотека, которую я пытаюсь внести в мой проект. Полезно, что эта же библиотека включает реализацию (ниже). К сожалению, это дает нечетные результаты. В частности, я определил, что код возврата vsnprintf() никогда не верен; а не случайные результаты, я, кажется, всегда вижу одинаковое прогрессирование неправильных значений (5, 1 и т. д.) при последовательных вызовах.

Звонок этой функции: asprintf(&str, "%s[%d]", name, val);. str - это char* в стеке в вызывающей функции. name - простой короткий текстовый дескриптор, который я проверил, не является нулевым, а не нулевым. val - простой индекс, который увеличивается в цикле, который вызывает asprintf(). Результирующая строка, создаваемая этим вызовом, должна содержать 7 символов (не считая нулевого терминатора). asprintf() называется во всей библиотеке. Мое использование содержащейся библиотеки выполняется только в этом одиночном цикле (дважды). Библиотека выполняет свою работу, как ожидалось, если я удалю этот вызов и заменим результаты фиктивными значениями. Выполнение, казалось бы, сбой при назначении буфера разыменованному ret указателю в рамках реализации asprintf().

Несмотря на множество экспериментов с буферами, разыменование указателя и управление var args, я не могу заставить эту функцию работать должным образом. Однако, скомпилированный на OS X, он работает отлично.

Я знаю, что поведение vsnprintf() не обязательно идентично для всех платформ. Тем не менее, насколько я могу судить, это использование должно работать так, как ожидалось.

Любые идеи? Может ли это быть вне самой функции? Какой-то вариант инициализации stdio или библиотеки библиотек, вызывающий проблемы?

int asprintf(char **ret, const char *fmt, ...) { 
    va_list ap1; 
    va_list ap2; 
    int count; 

    va_start(ap1, fmt); 
    va_copy(ap2, ap1); 
    count = vsnprintf(NULL, 0, fmt, ap1); 
    va_end(ap1); 

    if(count > 0) { 
    char* buffer; 

    if (!(buffer = (char*)malloc(count+1))) { 
     return -1; 
    } 
    count = vsnprintf(buffer, count+1, fmt, ap2); 
    *ret = buffer; 
    } 
    va_end(ap2); 
    return count; 
} 

Answer 1

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

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

Это упоминается, например, в Are prototypes required for all functions in C89, C90 or C99?.

любой вызов к VARIADIC функции (например, Printf или зсапЕ) должны иметь видимый Prototype

некоторое представление о том, чтобы "почему" дается в comp.lang.c FAQ list - Question 15.1.

Q: Я слышал, что вы должны #include <stdio.h> перед вызовом Printf. Зачем?

A: Для того чтобы прототип printf был в полном объеме.

Компилятор может использовать другую последовательность вызовов для функций, которые принимают списки аргументов переменной длины. (Это может быть сделано, если вызовы с использованием списков аргументов переменной длины были менее эффективными, чем те, которые используют фиксированную длину.) Поэтому прототип (указывающий, используя эллипсовую нотацию «...», что список аргументов имеет переменную длина) должна быть в области видимости всякий раз, когда вызывается функция varargs, поэтому компилятор знает, как использовать механизм вызова varargs.

Answer 2

Вы проверили определение

va_start 

макрос?

Возможно, это может вызвать проблему, поскольку адрес параметра может указывать где-то «за» указателем формата, если он не определен правильно. Если все в порядке, как вы говорите, проблема может быть в реализации vsnprintf, чем.

Answer 3

Нет стандартной инициализации, необходимой для stdio. Если ваша реализация требует инициализации, эта информация, мы надеемся, будет в документации.

Если vnsprintf сломана, вы можете использовать vsprintf. Вот версия списаны из FreeTDS:

int 
vasprintf(char **ret, const char *fmt, va_list ap) 
{ 
    FILE *fp; 
    if ((fp = fopen(_PATH_DEVNULL, "w")) == NULL) 
      return -1; 
    if ((fp == NULL) && ((fp = fopen(_PATH_DEVNULL, "w")) == NULL)) 
      return -1; 

    len = vfprintf(fp, fmt, ap); 

    if (fclose(fp) != 0) 
      return -1; 

    if (len < 0) 
      return len; 

    if ((buf = malloc(len + 1)) == NULL) { 
      errno = ENOMEM; 
      return -1; 
    } 
    if (vsprintf(buf, fmt, ap) != len) 
      return -1; 
    *ret = buf; 
    return len; 
} 

В зависимости от ваших потребностей, вы можете быть в состоянии повторно использовать дескриптор файла.

Answer 4

Я столкнулся с этим только сегодня, и, как ответил dxiv, ключ является видимым прототипом. Но я хотел бы расширить это: это не просто вариационные аргументы, которые не будут работать должным образом. В моем случае проект был создан, и функция была вызвана, но ни один из аргументов не работал должным образом. Вот очень простой пример для демонстрации. (Функция uprintf() является пользовательской функцией для распечатки через UART.)

void log_console( const char * fmtstring,...) 
{ 
    uprintf("Start of log_console\n"); 
    uprintf(fmtstring); 
} 

Вызов из основных() с прототипом скрытый:

//void log_console( char const * fmtstring,...); 
log_console("Test message to console =======\n"); 
uprintf("After test message to console\n"); 

В этом случае выход:

Start of log_console 
After test message to console 

Это показывает, что функция вызывается, но fmtstring не правильно определены. Но с прототипом видимым:

void log_console( char const * fmtstring,...); 
log_console("Test message to console =======\n"); 
uprintf("After test message to console\n"); 

функция теперь имеет доступ к входящему аргументу и строки, написанные в UART являются, как ожидалось:

Start of log_console 
Test message to console ======= 
After test message to console 

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