LINUX.ORG.RU

Размер указателя и stack pointer

 , , ,


0

3

Есть код

#include <cstdlib>
#include <iostream>

using namespace std ;

int main() {
  register int sp asm ("rsp");
  printf("0x%016llx\n", sp);
  int intVal = 7 ;
  int&& intRval = 5 ;
  int& intLval = intRval ;
   
  cout << hex << (void*)&intVal << endl;
  cout << hex << &intRval << endl;
  cout << hex << &intLval << endl;
  
  return 0 ;
}

Компилирую так:

g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out

Выхлоп рограммы такой
0x0000000068bb5580

0x7ffe68bb5588

0x7ffe68bb558c

0x7ffe68bb558c

Хочу спросить, почему RSP(стек пойнтер) указывает на разные места???
И сколько фактически размер указателя на x86_64?
Тестировал тут http://coliru.stacked-crooked.com/


Хочу спросить, почему RSP(стек пойнтер) указывает на разные места???

Может потому что он обрезается до int?

И сколько фактически размер указателя на x86_64?

А как ты думаешь?

slovazap ★★★★★ ()

1. В первом случае 64-битное значение rsp обстриглось до 32-битного int.

2. Если архитектура 64-битная, значит и размер указателей там 64 бита.

hlamotron ()
Ответ на: комментарий от pulya

Да. На 64-битной системе. Для кроссплатформенности используй ptrdiff_t или size_t. Они всегда будут правильного размера.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от slovazap

В выводе программы адреса переменных 12 байтные, а размер указателя в 64 битной системе 8 байт. Отсюда и вопрос

pulya ()
Ответ на: комментарий от pulya

Во-первых, в 16-ричном виде 2 символа равны 1 байту исходного числа. Так что получается 6, а не 12. Однако на самом деле дело в том, что cout не добавляет ведущие нули, чтобы добить длину строкового представления до 16 символов (8 настоящих байт).

KivApple ★★★★★ ()
Ответ на: комментарий от pulya

В выводе программы адреса переменных 12 байтные

Сделай std::cerr << (void*)nullptr, ещё больше удивишься - адрес, оказывается, полубайтный.

slovazap ★★★★★ ()

а как gcс вообще дал int с rsp связать?

ckotinko ☆☆☆ ()

#include <iostream>

никак сессия на горизонте...

mos ★★★★★ ()
Ответ на: комментарий от hlamotron

Если архитектура 64-битная, значит и размер указателей там 64 бита.

Пруф.

anonymous ()
Ответ на: комментарий от pulya

т.е. размер указателя равен размеру long long int?

Размер указателя равен размеру указателя.

anonymous ()
Ответ на: комментарий от hlamotron

2. Если архитектура 64-битная, значит и размер указателей там 64 бита.

А если 32-битная, то - 32 что ли? Фига с два.

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

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

KivApple ★★★★★ ()
Ответ на: комментарий от anonymous

А что кстати не так с iostream? Нужно чем-то другим пользоваться?

Kronick ()
Ответ на: комментарий от KivApple

Есть еще типы intptr_t, uintptr_t. size_t по смыслу лучше применять для всяких индексов в циклах

SZT ★★★ ()
Ответ на: комментарий от Kronick

А где ты в продакшене видел вывод в соснольку?

anonymous ()
Ответ на: комментарий от anonymous

У ТСа код на 15 строчек, чтоб чекнуть размер указателя, причем здесь продакшн?

Kronick ()
Ответ на: комментарий от pulya

Незнаю что такое long long int, стандарт явно не описывает битность типов. Я понимаю арабские числы, зачем плодить сущности - 32 или там 128.

hlamotron ()
Ответ на: комментарий от hlamotron

Фига с ноль. Если 32-битная, значит указатель 32.

Пруфлинк давай.

asaw ★★★★★ ()
Ответ на: комментарий от hlamotron

2. Если архитектура 64-битная, значит и размер указателей там 64 бита.

Фига с ноль. Если 32-битная, значит указатель 32.

Брехня. В общем случае размер указателя не равен размеру архитектуры (слова). Наличие с стандарте отдельных типов size_t и uintptr_t должно же намекать.

Dendy ★★★★★ ()
Ответ на: комментарий от anonymous

Если именно на консольку - то такое сплошь и рядом. Отладочный вывод называется. И да, он вполне имеет место и в релизных билдах, просто менее активный (чтобы не просаживать производительность). Я знаю вполне серьёзный софт (в том числе закрытый и дорогой), который как минимум в Linux версии выдаёт на консоль всякие ошибки и предупреждения. Некоторые из них отлично гуглятся и позволяют понять, что пошло не так (приложение в этой ситуации не запускается или работает некорректно), другие носят чисто информационный характер.

Правда, конечно, обычно для логгирования есть специальный класс, который уже где-то внутри себя дёргает printf или cout.

Но блин, это имеет смысл когда речь о большом проекте. У ТСа 15 строк кода. Плюс всё равно нет ничего удобнее при отладке распихивания по исходнку отладочных printf-ов, чтобы понять что же происходит. После устранения проблем этот вывод убирают или комментируют, но готов поспорить, что им пользуются даже в тех проектах, которые в релизе вообще ничего в консоль не выводят.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от anonymous

куча утилей срёт в консоль. в чём проблема? если для программы не нужен никакой другой вывод - вполне себе допустимо.

Iron_Bug ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.