size_t __cdecl fread (
void *buffer,
size_t size,
size_t count,
FILE *stream
)
{
size_t retval;

_lock_str(stream); /* lock stream */
__try {
/* do the read */
retval = _fread_lk(buffer, size, count, stream);
}
__finally {
_unlock_str(stream); /* unlock stream */
}

return retval;
}

Това работеше идеално(fread) допреди година когато го предадох.От две седмици взе да се обажда обаче - _fread_lk хвърля изключение по някаква причина.Смених кода със стандартни функции но ми е интересно какво може да е станало

Още по интересно че това е само при мен - не са ми казвали за такъв проблем а кода работи на доста места ... хм

Съдържаниет е скрито
Влезте за да го видите

Редактирано от 3мeй на 02.05.08 13:22.

Ми кечни го, де.
Кви са тия извратени конструкции дето ги ползваш? Тва __finally неква жабария. Начи C++ мъжете прават така:

class ReadLocker

{

public:

  ReadLocker(File*stream)

: _stream(stream)

  {

    _lock_str(_stream); /* lock stream */

  }

  ~ReadLocker()

  {

    _unlock_str(_stream); /* unlock stream */ 

  }



private:

 FILE* _stream;



};





size_t __cdecl fread ( 

    void *buffer, 

    size_t size, 

    size_t count, 

    FILE *stream ) 

{ 

  size_t retval = 0; 



  try {

    ReadLocker(stream);

   

    /* do the read */ 

    retval = _fread_lk(buffer, size, count, stream); 

  } 

  catch(const exception& e){ 

    e;

  } 



  return retval; 

}

Редактирано от Colombino на 02.05.08 13:55.

Това е стандартната имплементация на fread

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Бе заеби тая работа да е стандартна, щом имаш try без catch. Некой си е оставил ръцете и ти копипействаш без мисъл. Щом мета требе да се обработва грешка. Ако не ти пука от грешка поне не връщай боклуци (както правиш), а 0.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

__try/__finally e windows SEH а не C++ EH

Ако правя аналогия с изключенинята в Буилдера, то __finally се изпълнява винаги, независимо от върнатия резултат от _fread_lk() и не би трябвало да хвърли изключение. Ако има грешка при четенето, feof() и ferror() би трябвало да ти дадат причината за нея - защо има по-малко прочетени байтове от очакваното - дали е достигнат края на файла - feof(), или наистина има дискова грешка - ferror().


... for a brief moment it seemed that rock 'n roll would inherit the earth.

Така, като се позамисля (не много) ми се струва, че причината да гръмне е някоя от следните:

- buffer == NULL или сочи към недостъпна област от паметта
- count > действителния размер на buffer
- stream е от различна имплементация на fopen (различна от тази на _fread_lk),
да речем едното от msvcrt, другото от crtdll. Малко вероятно ама де да знаеш.
- stdio-то ти има различни дефиниции за _M_M68K или _M_MPPC (_INTERNAL_BUFSIZ & BUFSIZ)

Не че разбирам много от C, ама може ли да е свързано с многопроцесорна машина а ти да си тествал на един само? Само предположение...

Благодаря на всички за ценните идеи но се изясни къде е проблема.Когато има нарушение на достъпа дебъгера поставя показалеца на реда на извикване след този на функцията в който е станало това.В случая беше правилно.А причината беше че трябва да се пази принтерски контекст и когато се прочете несъществуващо устройство(от отсрещния принтер) CreateDC прави нарушение на достъпа
Извинения за подвеждането(аз също се подведох)

Съдържаниет е скрито
Влезте за да го видите