Jak sprawdzić, czy wskaźnik jest prawidłowy?

Dobrze zdaję sobie sprawę z brzydoty tego pytania, nadal chciałbym wiedzieć, czy jest to możliwe:Jak sprawdzić, czy wskaźnik jest prawidłowy?

Gdy program próbuje odczytać/zapisać do niepoprawnego wskaźnika (okna NULL, nieprzydzielone, itp.) powoduje awarię aplikacji z wyjątkiem wyjątku dotyczącego naruszenia dostępu.

Pytanie brzmi, czy istnieje sposób sprawdzenia, czy wskaźnik ten wygeneruje wyjątek przed próbą jego użycia, czy też istnieje sposób na złapanie tego wyjątku?

Źródło

2009-06-14 Anonymous

Podobny do http://stackoverflow.com/questions/683059/how-to-validate-lpvoid-to-bad-ptr/683085#683085 – Michael

Podobny do http://stackoverflow.com/search?q=IsBadReadptr – ChrisW

Najlepszym jeśli trzeba użyć surowych wskaźników jest upewnienie się, że jest to albo ważny wskaźnik lub NULL. Następnie możesz sprawdzić, czy jest poprawny, sprawdzając, czy jest równy NULL.

Ale aby odpowiedzieć na twoje pytanie, możesz złapać tego rodzaju rzeczy za pomocą structured exception handling (SEH).

To powiedziawszy, SEH is a bad idea.

Źródło

2009-06-14 18:04:59

Nie wiem o systemie Windows, ale w * nix można zainstalować program obsługi sygnału SIGSEGV, aby przechwycić wyjątek.

Źródło

2009-06-14 17:55:04 PaV

W systemie Windows można zakodować obiekt obsługi wyjątków Structured Exception, aby przechwycić wyjątek. – ChrisW

Obsługa sygnału nie jest * specyficzna dla nix: jest częścią standardowej biblioteki ISO-C – Christoph

To niewiele pomaga: po zakończeniu procedury obsługi SIGSEGV wykonanie programu powraca dokładnie w tej samej pozycji, w której pierwotna przyczyna sygnału pochodzi z . Dopóki nie wyjdziesz z wnętrza obsługi sygnału, utworzysz nieskończoną pętlę. Dlatego generalnie złym pomysłem jest złapanie SIGSEGV. – lumpidu

IsBadReadPointer/IsBadWritePointer

Źródło

2009-06-14 17:55:17 RichieHindle

Wiem, że istnieją IsBadRead/WritePtr, nie można znaleźć poprawnych wersji. Jednak MSDN mówi, że są one obsolette –

@Hammer: Przepraszam, miałem na myśli "zły", teraz rozwiązany. Uważane są za złą formę, ponieważ nie są bezpieczne dla wątków, ale są najbliżej tego, o co prosi OP. – RichieHindle

Istnieją funkcje IsBadReadPtr i IsBadWritePtr że może robić co chcesz. Istnieje również an article, który wyjaśnia, dlaczego nie powinieneś ich używać.

Źródło

2009-06-14 17:55:41 avakar

Od MSDN: "Ważne: ta funkcja jest przestarzała i nie powinna być używana Pomimo swojej nazwy nie gwarantuje ona, że wskaźnik jest ważny lub że wskazana pamięć jest bezpieczna w użyciu." –

Młotek, tak, są one oznaczone jako przestarzałe, a artykuł, do którego linkowałem, wyjaśnia dlaczego. Co zresztą próbujesz osiągnąć? – avakar

Myślę, że szukasz czegoś takiego jak IsBadReadPtr.

Dokumentacja:

http://msdn.microsoft.com/en-us/library/aa366713(VS.85).aspx

Źródło

2009-06-14 17:56:45

Można oczywiście sprawdzić, czy wskaźnik jest NULL!

if (ptr == NULL) { 
    // don't use it 
}

To jedyny test przenośny, który możesz wykonać. System Windows udostępnia różne interfejsy API do testowania wskaźników, ale, jak wskazali inni, używanie ich może być problematyczne.

Źródło

2009-06-14 17:59:11

Złapanie tego rodzaju błędów dotyczy objawów, a nie przyczyny źródłowej.

następujące idiomy będzie działać na każdej platformie:

zainicjować wszystkie wskaźniki do zera
jeśli nie możemy zagwarantować, wskaźnik jest ważny, sprawdź, czy nie jest 0 przed indirecting go
podczas usuwania obiektów, ustaw kursor na 0 po usunięciu
uważać kwestie własności obiektu przy przejściu odnośniki do innych funkcji

Źródło

2009-06-14 18:00:24 laalto

Jak sprawdzić, czy wskaźnik jest prawidłowy?

Odpowiedz

Powiązane problemy