size_t vs. uintptr_t

Standard C gwarantuje, że size_tjest to typ, który może przechowywać dowolny indeks tablicy. Oznacza to, że logicznie size_tpowinno być w stanie pomieścić dowolny typ wskaźnika. Czytałem na niektórych stronach, które znalazłem w Googles, że jest to legalne i / lub powinno zawsze działać:

void *v = malloc(10);
size_t s = (size_t) v;

Zatem w C99 standard wprowadził typy intptr_ti uintptr_t, które są podpisane, a typy niepodpisane gwarantują, że będą mogły przechowywać wskaźniki:

uintptr_t p = (size_t) v;

Jaka jest różnica między używaniem size_ta uintptr_t? Oba są niepodpisane i oba powinny być w stanie pomieścić dowolny typ wskaźnika, więc wydają się funkcjonalnie identyczne. Czy istnieje jakiś naprawdę ważny powód, aby używać uintptr_t(lub jeszcze lepiej: a void *) zamiast a size_t, innego niż jasność? Czy w nieprzejrzystej strukturze, w której pole będzie obsługiwane tylko przez funkcje wewnętrzne, czy jest jakiś powód, aby tego nie robić?

Z tego samego powodu, ptrdiff_tczy był typem podpisanym zdolnym do utrzymywania różnic kursorów, a zatem zdolnym do utrzymywania większości wskaźników, więc czym się różni intptr_t?

Czy wszystkie te typy nie służą w zasadzie trywialnie różnym wersjom tej samej funkcji? Jeśli nie to dlaczego? Co nie mogę zrobić z jednym z nich, czego nie mogę zrobić z innym? Jeśli tak, to dlaczego C99 dodał dwa zasadniczo zbędne typy do języka?

Jestem gotów zignorować wskaźniki funkcji, ponieważ nie dotyczą one obecnego problemu, ale śmiało mogę o nich wspomnieć, ponieważ mam podejrzenia, że ​​będą kluczowe dla „poprawnej” odpowiedzi.

size_tjest typem, który może przechowywać dowolny indeks tablicy. Oznacza to, że logicznie rozmiar_t powinien być w stanie pomieścić dowolny typ wskaźnika

Niekoniecznie! Wróćmy na przykład do czasów segmentowanych architektur 16-bitowych: tablica może być ograniczona do jednego segmentu (tak size_tby zrobił 16-bitowy ) ALE możesz mieć wiele segmentów (więc intptr_tdo wybrania musiałby być typ 32-bitowy segment oraz przesunięcie w nim). Wiem, że te rzeczy brzmią dziwnie w czasach jednolicie adresowalnych niesegmentowanych architektur, ale standardowy MUSI zaspokoić szerszą gamę niż „co jest normalne w 2009 roku”, wiesz!)

Jeśli chodzi o twoje oświadczenie:

„Standard C gwarantuje, że size_tjest to typ, który może przechowywać dowolny indeks tablicy. Oznacza to, że logicznie size_tpowinien być w stanie przechowywać dowolny typ wskaźnika”.

Jest to w rzeczywistości błąd (nieporozumienie wynikające z niewłaściwego rozumowania) ^(a) . Możesz myśleć, że to drugie wynika z pierwszego, ale tak nie jest.

Wskaźniki i indeksy tablicowe to nie to samo. Można sobie wyobrazić zgodną implementację, która ogranicza tablice do 65536 elementów, ale pozwala wskaźnikom na adresowanie dowolnej wartości w ogromnej 128-bitowej przestrzeni adresowej.

C99 stwierdza, że ​​górna granica size_tzmiennej jest zdefiniowana przez SIZE_MAXi może wynosić nawet 65535 (patrz C99 TR3, 7.18.3, niezmieniony w C11). Wskaźniki byłyby dość ograniczone, gdyby były ograniczone do tego zakresu w nowoczesnych systemach.

W praktyce prawdopodobnie okaże się, że twoje założenie się utrzymuje, ale nie dlatego, że standard to gwarantuje. Ponieważ tak naprawdę to nie gwarantuje.

^(a) Nawiasem mówiąc, nie jest to jakaś forma osobistego ataku, tylko stwierdzenie, dlaczego twoje wypowiedzi są błędne w kontekście krytycznego myślenia. Na przykład następujące rozumowanie jest również nieprawidłowe:

Wszystkie szczenięta są słodkie. To jest słodkie. Dlatego to musi być szczeniak.

Bystry lub inny charakter szczeniąt nie ma tutaj znaczenia, wszystko, co stwierdzam, to fakt, że dwa fakty nie prowadzą do wniosku, ponieważ dwa pierwsze zdania pozwalają na istnienie uroczych rzeczy, które nie są szczeniętami.

Jest to podobne do pierwszego stwierdzenia, które niekoniecznie nakazuje drugie.

Pozwolę, aby wszystkie pozostałe odpowiedzi były uzasadnione ograniczeniami segmentów, egzotycznymi architekturami i tak dalej.

Czy prosta różnica w nazwach nie jest wystarczającym powodem, aby użyć właściwego typu dla właściwej rzeczy?

Jeśli przechowujesz rozmiar, użyj size_t. Jeśli przechowujesz wskaźnik, użyj intptr_t. Osoba czytająca Twój kod od razu wie, że „aha, to jest rozmiar czegoś, prawdopodobnie w bajtach”, i „och, z jakiegoś powodu tutaj jest przechowywana wartość wskaźnika jako liczba całkowita”.

W przeciwnym razie możesz po prostu użyć unsigned long(lub, w dzisiejszych czasach, unsigned long long) wszystkiego. Rozmiar to nie wszystko, nazwy typów mają znaczenie, które jest przydatne, ponieważ pomaga opisać program.

Możliwe, że rozmiar największej tablicy jest mniejszy niż wskaźnik. Pomyśl o architekturach podzielonych na segmenty - wskaźniki mogą być 32-bitowe, ale pojedynczy segment może być w stanie adresować tylko 64 KB (na przykład stara architektura 8086 w trybie rzeczywistym).

Chociaż nie są one już powszechnie używane w komputerach stacjonarnych, standard C ma obsługiwać nawet małe, wyspecjalizowane architektury. Nadal rozwijane są systemy na przykład z 8 lub 16 bitowymi procesorami.

Wyobrażam sobie (i dotyczy to wszystkich nazw typów), że lepiej oddaje twoje intencje w kodzie.

Na przykład, mimo że unsigned shorti wchar_tsą tego samego rozmiaru w systemie Windows (myślę), użycie wchar_tzamiast unsigned shortpokazuje zamiar użycia go do przechowywania szerokiego znaku, a nie tylko dowolnej liczby.

Patrząc zarówno do tyłu, jak i do przodu, i przypominając sobie, że różne architektury dziwaków były rozproszone po krajobrazie, jestem prawie pewien, że próbowali zawinąć wszystkie istniejące systemy, a także zapewnić wszystkie możliwe przyszłe systemy.

Tak więc, w sposób ustalony, do tej pory nie potrzebowaliśmy tak wielu typów.

Ale nawet w LP64, dość powszechnym paradygmacie, potrzebowaliśmy size_t i ssize_t dla interfejsu wywołania systemowego. Można sobie wyobrazić bardziej ograniczony system przyszłości lub przyszłości, w którym użycie pełnego 64-bitowego typu jest kosztowne i mogą chcieć korzystać z operacji we / wy większych niż 4 GB, ale nadal mają wskaźniki 64-bitowe.

Myślę, że musisz się zastanawiać: co mogło zostać opracowane, co może przyjść w przyszłości. (Być może 128-bitowe wskaźniki dla całego systemu rozproszonego w Internecie, ale nie więcej niż 64 bity w wywołaniu systemowym, a może nawet „32-bitowy” starszy limit :-) Obraz, że starsze systemy mogą uzyskać nowe kompilatory C. .

Zobacz także, co wtedy istniało. Oprócz modeli pamięci w prawdziwym trybie zillion 286, co powiesz na 60-bitowe mainframe słowa / 18-bitowego CDC? A co z serią Cray? Nie wspominając o normalnym ILP64, LP64, LLP64. (Zawsze myślałem, że Microsoft był pretensjonalny z LLP64, powinien to być P64). Z pewnością mogę sobie wyobrazić komitet próbujący objąć wszystkie bazy ...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

Oznacza to, że intptr_t musi zawsze zastępować size_t i visa versa.