sprintf Опции

[sergey sva]

Где можно посмотреть исходник sprintf, библиотечная работает, только с целыми значениями, а если нужно %f зависает все ,где искать причину не знаю?

[ReAl]

У avr-gcc, насколько я помню, поначалу тоже с malloc был. На стеке выделялся только буфер для преобразований целых чисел, а для плавающих форматов буфер длиннее и его по malloc выделяли.

[defunct]

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

Вначале писали извращенцы, асболютно не представляющие что такое МК. Потом за дело взялись нормальные люди и сделали правильно.
Я все никак не могу взять в толк почему некоторые делают маленький стек, и большой heap, а потом в коде начинают появляться воистину дебильные и тормозные конструции типа:

Код

foo()
{
    U8 *buf = (U8 *)malloc(256);
    /*
        malloc при поиске подходящего блока проходит километровую цепочку heap descriptor'ов.
        процесс прохода дескрипторов необходимо защитить локом либо другим sync примитивом,
        для обеспечения атомарности доступа,
        а значит прерывания могут быть запрещены на ОЧЕНЬ ДОЛГО.
    */
    ...



    free( buf );
    /*
        проходит через процесс объединения текущего блока со свободными,
        хоть этот процесс и быстрее чем выделение,
        но всяко медленнее чем одна команда "SUB SP, 256"
      
        в этом процессе требуется обеспечить атомарность при обращении к heap дескрипторам,
        а значит прерывания и здесь могут быть запрещены на относительно длительное время
    */
}

что мешает млин heap уменьшить на 256 байт, а стек на те же 256 байт увеличить? Чтобы было просто

Код

foo()
{
    buf[ 256 ];  // память выделена мгновенно

    // и освобождена автоматически
}

[rezident]

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

ИМХО потому, что у кучи есть менеджер, а стек он неконтролируемый. Наползание стека на данные это одна из самых трудновылавливаемых ошибок при программировании МК.

[defunct]

Наползание стека на данные это одна из самых трудновылавливаемых ошибок при программировании МК.

Дык возникает она потому что

делают маленький стек

В отличие от Heap'а и его проблем фрагментации, для стека где фрагментация впринципе невозможна (по природе LIFO) - объем можно оценить еще до run-time.
Помножить это число на два, и будет щастье. Если посчитать заранее тяжело - заполнение стек памяти патерном, прогон программы с последующим дампом памяти для оценки использования стека в run-time тоже никто не отменял.

Много ли толку от менеджера, когда в heap нет блока требуемого объема и менеджер возвращает NULL? А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать?

[demiurg_spb]

А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать?

Да, да. Я читал где-то что по современным веяниям проверять на NULL malloc и иже с ним - моветон.
Причём и с аргументациеё всё вроде как чики-поки... Но всё это естественно в контексте ПО под ПК.