2011-01-01 35 views
8

Khi thiết kế một ngôn ngữ lập trình mới, có an toàn khi giả sử rằng một int và con trỏ có cùng kích thước trên máy không?Có an toàn khi giả định rằng một con trỏ có kích thước của một int trong C không?

+4

Có thể là câu hỏi tràn ngăn xếp. – Orbling

+0

Xem thêm: [C++: Có an toàn khi đưa con trỏ tới int và sau đó quay lại con trỏ không?] (Http://stackoverflow.com/questions/3567905/c-is-it-safe-to-cast-pointer- to-int-and-later-back-to-pointer-again) – Shog9

+1

bản sao có thể có của [sizeof (int) == sizeof (void \ *)?] (http://stackoverflow.com/questions/502811/sizeof- int-sizeof-void) – Amro

Trả lời

16

Không. Con trỏ có thể lớn hơn hoặc nhỏ hơn kích thước nguyên. Nếu bạn cần truyền con trỏ dưới dạng số nguyên vì một số lý do (như thực hiện số nguyên, thay vì con trỏ, số học), chúng được đảm bảo để khớp với một số intptr_t.

Chúng không được đảm bảo phù hợp với kích thước_t như được đề xuất trong câu trả lời khác, nhưng trong thực tế, không chắc là chúng sẽ không, vì kích thước địa chỉ lớn nhất thường bằng địa chỉ lớn nhất.

1

không, nhưng con trỏ phải có cùng kích thước với intptr_t.

+0

Có vẻ như sizeof (int)! = sizeof (int *) với máy và trình biên dịch mà tôi đang sử dụng tại thời điểm này ... vì vậy nếu một cái gì đó tương tự là an toàn, nó không liên quan đến int . – compman

+1

@ user9521: Như Dan nói, luôn sử dụng các loại 'size_t'. Vấn đề chính với việc chuyển đổi mã thành x64 là sự phổ biến của những người giả sử kích thước int là như nhau, thực tế đó đã bị phản đối nhiều năm trước. – Orbling

+2

-1 - Trên thực tế bạn có thể đúng, nhưng de jure bạn là sai. Trên kiến ​​trúc bộ nhớ phân đoạn (và các loại bệnh lý khác), size_t có thể nhỏ hơn intptr_t. http://stackoverflow.com/questions/1464174/size-t-vs-intptr-t. –

1

Tôi nghĩ rằng bạn có nghĩa là kích thước của các loại dữ liệu được xác định bởi nền tảng không phải là C lang. Theo hiểu biết tốt nhất của tôi, C không xác định bất kỳ kích thước cụ thể nào cho các kiểu dữ liệu. Câu trả lời cho câu hỏi của bạn là bạn không thể giả định điều này, ví dụ trên win32 sizeof (int) == sizeof (con trỏ) == 4 byte tuy nhiên trên win64 sizeof (int) == 4 và sizeof (pointer) == 8

+2

Ngôn ngữ C xác định một số kích thước dữ liệu tối thiểu (ví dụ: size_t phải có ít nhất 16 bit), kích thước quan hệ (dài không thể ngắn hơn), cũng như một số loại kích thước cố định (uint32_t chính xác là 32 bit). –

+0

@ Joe bạn nói đúng, tôi nên hạn chế câu trả lời của tôi về kích thước tương đối của int và con trỏ. – Gaurav

+0

@Joe: Có vẻ như uint32_t lần đầu tiên xuất hiện trong tiêu chuẩn C trong C99 (xem http://en.wikipedia.org/wiki/Stdint.h) bởi vì đó là khi stdint.h trở thành một phần của tiêu chuẩn. (Tôi không biết nếu triển khai đôi khi sẽ cung cấp nó trước khi C99.) – compman

3

Không, đặc biệt là trong môi trường 64 bit:

LP64 Điều này bao gồm * nix môi trường nhưng điều này cũng đúng trong cửa sổ cho LLP64.

5

Không, hoàn toàn không. Nhiều trình biên dịch không có chúng như cùng kích thước.

1

Không; trên máy MacOS X 10.6.5 của tôi. máy, int là 32 bit và một con trỏ là 64 bit theo mặc định.

Nếu bạn cần số nguyên đúng kích cỡ để giữ con trỏ, hãy sử dụng #include <inttypes.h> (hoặc <stdint.h>) và uintptr_t - giả sử bạn có hỗ trợ C99 hoặc có thể mô phỏng nó.

-2

Tôi tin rằng hạt nhân Linux chuyển con trỏ dưới dạng unsigned long's. Chúng được đảm bảo ít nhất có cùng kích thước với con trỏ :)

+3

No. Linux đảm bảo chúng có cùng kích thước. Ngôn ngữ C không hứa hẹn gì cả. –

+0

Đây thực sự là câu trả lời hay vì nó cho thấy một số hành vi của hạt nhân, và họ không quan tâm đến các quy tắc ngôn ngữ C. Nó gây ra lỗi trong cuộc sống thực, như bộ xử lý [Bug 4441: VIA C7-D của OpenSSL: Treo trong 30-test_afalg.t] (https://rt.openssl.org/Ticket/Display.html?id=4441). Nó xuất hiện là vì hạt nhân đang đúc con trỏ (i686, 32-bit) để tích phân kích thước lớn hơn (unsigned long và sau đó được lưu trữ trong một '__u64'). – jww

Các vấn đề liên quan