Искам да споделя на какво се натъкнах преди малко и да попитам къде е грешката.
Компилатора е С18 на микрочеп. Пиша си аз, и си тествам поотделно - всичко е ок. Но...

Тази процедура трябва да ми изведе на графичен дисплей променливата "min".


Какво се получава!? Нищо не излиза на дисплея. Пуснах симулатора и видях какъв е проблема - много тъп...
Втората процедура си разполага локалните променливи върху резултата от първата Да нямаше свободно място в стека - разбирам, но от него се ползва най-много 10%. Цяла банка е.
Въпроса ми е, дали проблема е в програмиста или в компилатора? И има ли някакъв начин да се избегне това?
Избегнах го, разбира се, като ползвам за първата процедура "глобален" буфер, но едва ли това е правилният начин!

нещо не мога да схвана смисъла на питането ти - но няма и един ред код (само "...") - как да ти помогне човек

и много ми е интересно какво има в:
char * ubtoa (unsigned char n)
{
char *p;
char buf[5];
.
.
.

return p;
}

особенно поинтера дето го връща

понеже виждам че се съмняваш в компилатор - бъди сигурен че е 99.999999% от случаите - проблема е в теб !
(не ползвам пикове - тъй че не познавам компилатора - просто интуиция )

Обикновенно се оказва, че предмониторното устройство греши .

Ако връщаш указател към нещо във ф-ята, което не е обявено като static, няма да работи никога.

Точно това е. Не се сетих когато трябваше Сега всичко е ок. Благодаря
@ps66, не сметнах за нужно да поствам целия код за да стане ясно какъв е проблема. Не, че е някаква тайна.

Това е, само дето буфера не беше деклариран като static.

по-горе съм ти написал: "особенно поинтера дето го връща " - щото имах големи съмнения че сочи към "намайнатаси+12" - ама как да съм сигурен без кода
по-принцип при връщане на указател трябва да си абсолютно наясно къде сочи!

може да съм бил малко по-рязък за което се извинявам, но пиша на C/C++ и асемблер от 20г и почти никога не съм си позволявал да търся проблема в компилатора (с малки изключения и то предимно в библиотеките!) - и понеже видях няколко теми дето "скапания компилатор бил виновен" пуснати от хора дето тепърва се учат ... и ъъъ. не се сдържах ...

Значи не си работил с майкрочипския компилатор. Лично аз съм открил (и рипортвал) 5 или 6 бъга. Просто няма как да направиш такава сложна програма като компилатор без бъгове. То иначе нямаше да излизат по 20 версии на един и същи компилатор.....

Но принципно си прав, в 95% от случаите проблема е в юзера.

вярно е - както съм писал по-горе с пик съм работил преди 10-на год. (някаква въшка 16ц??), но продължавам да твърдя че компилаторите са последното нещо в което трябва да се съмнява човек!
реда (на бързо):
1) моя код (всичко което се сети човек )
2) хедър файлове
3) ключове (#дефине / #иф ..)
4) библиотеки
..
N) компилатор

винаги можеш да си генерираш асм. листинг на кода и да видиш причината за проблема (е .. трябва да знаеш асм поне )

само за куриоз:
преди 10-на дена си получих нотбука Dell M65 с Core2duo и Vista (поръчан преди 40 дни ) и смятах да го направя ост. работна среда (в замяна на стария си Latitude D600+XP) ... обаче ... компилатора ми не щеше да работи ... по точно линкера (ilink32.exe) понякога даваше "access violation", генерираното exe имаше странно поведение (проекта ми е огромен: 1200 файла C++ 24+МБ ...)
съмних се че нещо компилатора (vista problem!?) не е наред (BDS2006/BCB10 работи на старите ми D5000e и D600) ... пробвах какво ли не - с ... частичен успех.
излезе hotfix12 за компилатора - и пак нищо ... в същия ден излезе ъпдате на биоса - оказа се че Core2duo си има сериозен проблем оправен от интел в микрокода - и сега всичко си е наред (без каквито и да били промени в софт.)

http://support.euro.dell.com/support/downloads/download.aspx?c=bg&l=en&s=bsd&releaseid=R152939&SystemID=LATITUDE%20PRECISION%20M65&servicetag=%20&os=WLH&osl=en&deviceid=10435&devlib=0&typecnt=0&vercnt=6&catid=-1&impid=-1&formatcnt=1&libid=1&fileid=203805
малко по-въпроса от интел:
http://download.intel.com/design/mobile/SPECUPDT/31407908.pdf
http://download.intel.com/design/processor/specupdt/31327910.pdf

ако си начинаещ - последния в който трябва да се съмняваш е компилатора !

значи бъг няма, но претупване на работата може би има. сериозните компилери сигнализират тази ситуация със предупреждение. ето какво дава микрософтския компилер
C:\programi\probi\probi.cpp(12) : warning C4172: returning address of local variable or temporary

компилатора може да сигнализира ако върнеш адрес на локална променива дирекнто, но не и ако връщаш променлива поинтер - щото тя може да сочи където си иска!

принтер:
{
char szB[5];
...
return szB; // комп. вижда локален адрес
}

{
char szB[5];
char *p = szB;
...
return p; // р може да сочи където си иска - няма как комп. да предупреди
}