[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


Sepples will make excuses for this.
>>
>>107718524
what does he mean "what address do you land on"? where does the output of the expression go? is it reused or are we doing it independently?

a chink or jeet wrote this text
>>
>>107718543
It's a Microsoft interview question kek
>>
>>107718524
4,4?
>>
>>107718524
ez pz
assuming this is x86-64

first line: &x + 1
means
take the address of the pointer to x and increment it by sizeof(int *)
so you have int ** and you increment it by the size of the type it points to: sizeof(int *)
so its gonna be 8
and the second line : x + 1
emans
take the pointer to x and increment it by sizeof(int)
so you have int * and you increment it by the size of the type it points to: sizeof(int)

the answer is 8, 4
and op is a faggot filtered by pointers
>>
>>107718975

If this line is in a normal function then x, the pointer, is a variable on the stack. How do you know where the stack pointer is?
>>
>>107718975
>>107719018
The variable shown here is an array. There is no int* for you to get an int** from.
>>
>>107719018
its an array
the address of an array is the same of its first element
the difference in behaviour in picrel, bw s_str_a and s_str_b emerges from the same property- one "shadow dereferencing"
youre passing a pointer to putstr, but in one case its a pointer with a dereferencing, in another its an offset

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct s_str_a
{
size_t size;
char *text;
};

struct s_str_b
{
size_t size;
char text[];
};


int main(void)
{
char text[] = "this is a string";
struct s_str_a *str_a = malloc(sizeof(struct s_str_a));
struct s_str_b *str_b = malloc(sizeof(struct s_str_b) + sizeof(text));

str_a->text = text;
strcpy(str_b->text, text);

puts(str_a->text);
puts(str_b->text);


// emits address of the array
fprintf(stderr, "&(str_b->text) : %p\n", &(str_b->text));
// emits address of the first element of the array
fprintf(stderr, "str_b->text : %p\n", str_b->text);

free(str_a);
free(str_b);


}
>>
>>107719040
arrays "decay" into pointers from the point of view of c, on a semantic level
but not from the point of view of its internals, how the semantics are expressed in asm
idk if that makes actual sense, it does to me
>>
also yeah. c
we dont serve sepplebois and dogs in this joint
we kindly ask our clients to leave their pet animals outside
>>
>>107719074
When an array is used in an expression, it will "decay" into a pointer to the first element of the array, with a few exceptions. One of these exceptions is the unary & operator, allowing you to make a pointer to the array.

&x does not give you int**. If it did, what int* would it be pointing to? There is no such object.
>>
>>107719150
the address of the array. duh
you add a level of reference to it
what else is it gonna do than "this 'ere int* shall now become an int** by virtue of addressing it through reference"
thats literally what youre telling the lang to do
that arrays are quirky, yeah, thats another thing.
pointers are a reference. not an address. theyre an abstract object. they opacify the actual memory layout. its for portability purposes afaik
>>
>>107718975
heh, I always thought "x" and "&x" would evaluate to the same type. oh well.
t. been coding in c++ for over 20 years
>>
>>107718975
>take the address of the pointer to x and increment it by sizeof(int *)
that's retarded. Why not increment by 1?

Also you're wrong. It's 20, 4.
>>
>>107719220
its a trick question
+ sepples tends to force you into high level interfaces
you just dont have as much experience as a c-ultist in pointer shenanigans

even doe x and &x wont ever be of the same type
one is an object, the other is a reference to said object, they cannot be of the same type
you kinda should have known that to be quite famalam with you
>>
>>107719150
I was expecting something like this (which does not compile) to be sematically identical to the op.

int* x = {0,1,2,3,4};

I was expecting the compiler to stick the array in some sort of pre-initialized memory, and give me a ordinary pointer named x. Tested in gcc/g++ 11.2 to not work (ofc).

I guess I was thinking this because:
char *str = "hello world";
is ok, at least in 'c', and with a warning in c++.
>>
>>107719222
>Also you're wrong. It's 20, 4.
I didn't say the answer before. And yeah, that seems to be the correct answer.
>>
>>107719222
>that's retarded. Why not increment by 1?
because then you would have to increment everything with += sizeof(type)
now that would be retarded
>its 20
why would that be?
>>
>>107719235
>the other is a reference to said object
lmao, you're not in position here to lecture me, kiddo
>>
>>107719255
nice sad homonem but you suck cock
therefore your opinion is invalid
feel free to try again (although you will be met with the same answer)
>>
>>107719250
>its 20
fukk
it IS 20
ok, gg. i learned something today
>>
>>107719250
>why would that be?
x is an array of 5 ints. It has a size of 20 bytes.
&x is a pointer to an array of 5 ints. The element it points to has a size of 20 bytes.
&x + 1 is the pointer to the array of 5 ints next to x. So it's 20 bytes after where x is.
>>
int x[5] = { 0, 1, 2, 3, 4 }; // sizeof(20)
x // *int - pointer to an object of sizeof(4)
&x // int(*)[5] - pointer to an object of sizeof(20)
x + 1 = 0 + sizeof(int) = 4
&x + 1 = 0 + sizeof(int[5]) = 20
>>107719267
there are wrong answers and there are catastrophically wrong answers. how did you manage to bring references into all this is beyond me. you clearly don't understand anything.
>>
>>107718975
#include <iostream>
using namespace std;

int main()
{
int x[5] = {0,1,2,3,4,};
long offset = (long)&x;
cout << (long)(&x + 1) - offset << endl;
cout << (long)(x + 1) - offset << endl;
}

Smut retard. Imagine being wrong. C++ is a mess
>decay into pointer
kek wtf
>>
>>107719303
it took me a minute to figure that out
for my defence its 11:48 and i havent slept yet since yesterday
but that the array doesnt decay thats inexcusible
i will probably abstain from drinking for the next several hours (also bc ill be sleeping during that time. but still, its the intention that matters as they say)
>>
File: ukaki0l.png (17 KB, 400x400)
17 KB
17 KB PNG
>>107719324
>smut retard
wow. youre even more esl-est than i am
>>107719308
because &x means "reference of x"
you seem to understand even less than i do
chud gpt has been very helpful i see
>>
>>107719350
>because &x means "reference of x"
lmao
>>
>>107719354
>digs deeper
you want a shovel with that?
it could expedite the process
>>
>>107719360
>C code
>references
>>
  char str[] = "hello world";

printf("str addr: %p\n", str);
printf("str addr addr: %p\n", &str);

char *str2 = "hello world2";

printf("str2 addr: %p\n", str2);
printf("str2 addr addr: %p\n", &str2);


str addr: 0x7fffac0ee174
str addr addr: 0x7fffac0ee174
str2 addr: 0x402025
str2 addr addr: 0x7fffac0ee168


This was compiled in c, but I would have expected both cases to work similarly.
>>
>>107719406
exactly.
now that you snatched defeat from the jaws of victory feel free to penguin walk to your nearest medical point lamaõ
>>
File: pointers.png (70 KB, 946x276)
70 KB
70 KB PNG
>>107719420
>>107719057
this code is a practical application of the property:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct s_str_a
{
size_t size;
char *text;
};

struct s_str_b
{
size_t size;
char text[];
};


int main(void)
{
char text[] = "this is a string";
struct s_str_a *str_a = malloc(sizeof(struct s_str_a));
struct s_str_b *str_b = malloc(sizeof(struct s_str_b) + sizeof(text));

str_a->text = text;
strcpy(str_b->text, text);

puts(str_a->text);
puts(str_b->text);

free(str_a);
free(str_b);
}
>>
File: 1757418194680.png (43 KB, 638x448)
43 KB
43 KB PNG
>>107718975
It's trickier than that. &x is a "pointer to an array of 5 integers (int[5]*)", which has size 20. Pointer arithmetic will advance the pointer by sizeof(int[5]).
>>
>>107719448
yup.
had time to notice myself since then
>>107719287

i thought & operator drops the actual type, makes the array decay into a pointer
>>
>>107719467
in order to do pointer arithmetic, the pointer still holds a type. you can then cast to a void* if you want.
>>
>>107719498
yeah, sure
i just thought that arrays get normalized into pointers to their element type when using the & operator... for some reason.
apparently c is smarter than i gave it credit for
>>
>>107719446
Its a bit more than that; in the str2 case the array is located in a different segment. in the str case the static array is on the stack.

Because you use a static array in your example, i'd bet you would find "this is a string" on the stack.
>>
>>107719545
*whups.
you would find text[]'s contents on the stacks. I'd guess a copy of "this is a string" is also in another segment and was copied into text[], but that's a godbolt question.
>>
File: 1754284312595320.jpg (79 KB, 480x601)
79 KB
79 KB JPG
>>107718975
>"ez pz"
>gets the first answer completely wrong
>>
>>107719584
not the first not the last time
perfectly in line with the spirit of the board, too

>>107719545
apparently it gets shoved into 2 registers
and then i have no fucking clue kek
>>
>>107719518
>i just thought that arrays get normalized into pointers to their element type when using the & operator... for some reason.
same
>>
File: pepe-shrug.png (8 KB, 700x500)
8 KB
8 KB PNG
>>107719625
the fastest way to learn is to be wrong on the internet
>>
>>107718524

address of variable x + 1
address of pointee x + 1 so address of x[1]
>>
>>107719448

is that compiler dependent/undefined behavior? i thought it’d decay into int[]* (as in size is not preserved so int**)
>>
>>107719722
size is lost only after decaying to pointer. sizeof(array) returns real size of array.
>>
File: c standard.png (65 KB, 874x480)
65 KB
65 KB PNG
>>107719722



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.