В 64-битной винде не выполняется, пруфлинк

Ок, тогда чему _всегда_ равно sizeof(void *) == sizeof(????) ? Или нет такого?

sizeof(void *) == sizeof(char *), всегда.

Тогда уже

sizeof(_anything_ *) == sizeof(_anyother_ *)

Я имею ввиду из sizeof(_скалярный тип_), не указатель.

>sizeof(_anything_ *) == sizeof(_anyother_ *)

В общем случае размер указателя разных типов в некоторых системах может быть разным, если разные типы по-разному адресуются. Например, 8-битный указатель портов и 16-битный указатель данных. Или быстрый 16-битный внутрисегментный указатель и медленный 32-х битный указатель сегмент-смещение.

>Ок, тогда чему _всегда_ равно sizeof(void *) == sizeof(????) ? Или нет такого?

Можно безопасно полагать, что sizeof(size_t) >= sizeof(void*)

нет такого. если хочешь хранить указатель в целочисленной переменной, используй (u)intptr_t. но то, что sizeof(void *) == sizeof(intptr_t) стандарт не гарантирует.

> Можно безопасно полагать, что sizeof(size_t) >= sizeof(void*)

нет. например, в 16-битном х86 полный адрес — 32-битный, но в некоторых моделях адресации (small, емнип) size_t — 16-битный.

> sizeof(unsigned long) == sizeof(void *) ?

С чего бы?

> sizeof(_anything_ *) == sizeof(_anyother_ *)

нет, если _anything_* указатель на данные, _anyother_* — на функцию.

а если использовать тип ptr_diff для перевода в «целые»? похоже ТС хочет именно этого. Не?

> тип ptr_diff

не знаю такого типа.

> похоже ТС хочет именно этого. Не?

я хз, что хочет ТС, у меня была двойка по телепатии.

А зачем?

я хз, что хочет ТС, у меня была двойка по телепатии.

у мну трояк. из этого

sizeof(unsigned long) == sizeof(void *) ?

следует, что тс хочет(?) вычитать указатели. А ptrdiff_t как раз тот самый тип, который имеет РАЗНОСТЬ УКАЗАТЕЛЕЙ (одного типа ессно).

#include <cstddef>

int main()
{
	int x[] = {1,2,3};
	int *p1 = &x[0];
	int *p2 = &x[2];
	std::ptrdiff_t d = p2 - p1;
	return d;
}

ответ 2 :)

ЗЫЖ вроде и без плюсов с ц99 работало. не помню...

А разве это не сглаживается libc/компилятором?

>А разве это не сглаживается libc

Э... libc, это, как бы, очень конкретная библиотека для вполне конкретных архитектур :)

компилятором?

Вот, как раз, в некоторых хитрых платформах у Си-компилятора и есть такие извращения. На x86/ARM/DEC/68K/etc мир не заканчивается ;) Впрочем, вариант со смешанными far* near* указателями и на x86 был.

int же.

> Я правильно понимаю, это правило выполняется всегда?

Нет. Читайте стандарт.

идиоты, на Си надо писать под конкретную платформу, это слишком низкоуровневый язык, для кроссплатформенности

Улыбнул.

А что именно тебе нужно?

По определению

sizeof(intptr_t) == sizeof(void *)

Заодно см. inttypes.h на предмет (PRI|SCN)[diouxX]PTR

Ну у меня впечатление, что народ хочет писать под те платформы, которые не очень стандартам следуют.

Тогда autotools && несложные проверки для правильного определения u?intptr_t и макросов для printf/scanf. В принципе, там никакого rocket science нет.

> идиоты, на Си надо писать под конкретную платформу, это слишком низкоуровневый язык, для кроссплатформенности
Торвальдс с удивлением смотрит на анонимуса

Полагаю, что анонимус имел ввиду, что для другой платформы надо будет в любом случае выверять длины всех типов.

И даже это глупость. Надо просто быть аккуратным и следовать спекам, не делая допущений, которых в спеках нет.

> По определению

нет такого определения.

Вообще, конечно, да. По определению там '>=', но задачи, где будет нужно точное соответствие (равно как и архитектуры, где это будет не так), я придумать не могу.

> По определению там '>='

такого определения тоже нет.

неправильно понимаешь. нет такого правила.

Да ну? А 7.18.1.4 о чём говорит? Или месье предлагает однозначность преобразования void * => intptr_t и обратно при sizeof(intptr_t) < sizeof(void *)?

> А 7.18.1.4 о чём говорит?

о том, что любое валидное значение указателя на void может быть представлено intptr_t. там нет ни слова о внутреннем представлении ни указателя на void, ни intptr_t.

> Или месье предлагает однозначность преобразования void * => intptr_t и обратно при sizeof(intptr_t) < sizeof(void *)?

а что смущает? что для некоторой платформы указатель может содержать избыточную информацию?

Что указатель может иметь явно избыточный размер. Хотя да, стандарту это не противоречит, был неправ.

Приведи пример такой архитектуры, пожалуйста.

Приведи пример такой платформы.

> Приведи пример такой архитектуры, пожалуйста.

x86.

> Приведи пример такой платформы.

какой вывод ты сделаешь, если не приведу пример реальной платформы?

8086? Внутрисегментная и межсегментная адресация?

Что ты не можешь дать пример реальной платформы.

А какой смысл там приводить пару сегмент:смещение к целому типу, если арифметика с ним работать не будет?

Да никакого смысла нет, вопрос только для улучшения моего понимания предмета.

> 8086? Внутрисегментная и межсегментная адресация?

лолшто? у меня случился SIGSEGV, бэктрейс:
bk_> 8086? Внутрисегментная и межсегментная адресация?
arsi>> x86.
bk_>>> Приведи пример такой архитектуры, пожалуйста.
arsi>>>> нет, если _anything_* указатель на данные, _anyother_* — на функцию.
bk_>>>>> sizeof(_anything_ *) == sizeof(_anyother_ *)
arsi>>>>>> sizeof(void *) == sizeof(char *), всегда.
bk_>>>>>>> чему _всегда_ равно sizeof(void *) == sizeof(????) ?

uintptr_t

В каких таких случаях указатель на функцию больше указателя на переменную?

> В каких таких случаях указатель на функцию больше указателя на переменную?

я уже не помню точно, как назывались эти модели распределения памяти… medium, compact или как-то так… были near(16bit) code + far(32bit) data и far code + near data… ну и остальные, где указатель на код занимал столько же, как указатель на данные. +pseudo-linear (huge model), но это уже совершенно другая история.

> medium, compact или как-

tiny, small, medium, compact, large & huge.

Указали на данные и код свободно прыгали в размерах между 16 и 32 битами, их комбинации давали вышеперечисленные модели.

+pseudo-linear (huge model),

huge ничего общего не имеет с «pseudo-linear». В этой модели смещения были 32 бита.

первое, с чего нужно начинать, это читать про размеры типов на конкретной платформе. нет, конечное есть абстракции типа int32_t явно обозначающие размерность типа, но как бы то ни было, всегда есть особенности конкретного компилятора на конкретной платформе.