Infinite growth is an infectious disease that turns everything into shit

>>105591698 (OP)
what if i want to add mods to model every molecule possible in your game mr anon

>>105591698 (OP)
Ok, what if you want to use more than 8 MiB of memory?

>>105591723
Refer to line 4.
>>105591732
Rewrite the program.

Rather generous filename length allowance

common on embedded systems. even though the hardware is good enough to not do it that way anymore, those parts of the code are usually quite old.
note that this will make it very easy to cheat engine your game.

>>105591778
what mainstream os even allows filenames over 255 bytes? iirc neither windows nor linux does

My game has 518400 entities. Is this ok op?

>>105591698 (OP)
Minecraft modders would like a word with you

>>105591698 (OP)
>Only 4096 files
Can't even compile Linux with this restriction.

>>105591698 (OP)
you're the reason why we can't have nice things

>>105591698 (OP)
You do need pointers.
Pointers are how addressing memory works, whether you are in control of them or not.

>>105591698 (OP)
>You don't need pointers
>OP pic literally has pointers

Array is just a syntactic sugar over pointer.

>you don't need pointers.
>declares 3.

>>105596140
>>105597005
>>105598674
why are cniles always so clueless about basic programming or even the c language they wank one over daily

>>105591698 (OP)
Great now write that in assembly without pointers

>>105598835
>why are cniles always so clueless about basic programming
Why are you so clueless about basic programming?

>>105598872
There are no pointers in assembly, retard

>>105599421
Are you actually retarded?
Any time you want to access something in memory, or put something in memory, you need that address somewhere. That's a pointer.

>>105599913
wrong, an address is an address

>>105599946
A pointer is an address.
Seriously, have you even done any assembly programming? Any at all?

>>105599997
wrong. In C, pointers are not addresses.

Write a linked list without pointer.

>>105600014
What do you think they are?

>>105600117
(ntt)
abstract objects
#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);


}

the practical difference is an additional level of dereferencing

>>105600117
A pointer is an address and the pointer's provenance.

>>105591698 (OP)
Why 512? vfat supports filenames up to 255 character encoded in UTF-16 (what Windows uses). If converted to UTF-8 (what Linux uses) it will take 765 bytes + 1 for null terminator.

>>105600117
heap memory

>>105600146
Both addresses, so what?

>>105600214
yeah but in one instance you get em with a dereferencing, in another with a simple add operation
both pointers.
but one is way faster than the other
pointers are abstract objects. they dont map 1:1 to underlying operations
theyre references.

>>105600214
wrong, see >>105600164

fixed length array schizo is at it again huh

>>105600226
>theyre references.
What do they reference?

>>105600267
the underlying data, duh
in the example: in one instance its an actual address
in the other: like a roadsign that says "here but
+ 8"

>>105600226
>but one is way faster than the other
They're the same speed.
The register to register mov and the add each take one cycle.

>>105600351
yeah but in one case you point to what could be yet another block of memory and in the latter youre pretty much guaranteed to find your data on the same page
i think the abstraction of a pointer is even more evident this way
more tangible

>>105600146
What if you need more than one flexible array in your struct?

>>105600376
thats a dumb question
you allocate a buffer and you subdivide it
how exactly you wanna do that is up to you its a matter of interfaces so you got plenty of options

>>105600376
>>105600397
(cont)
in other words
you reformulate your two flex arrays as one

>>105600397
>you allocate a buffer and you subdivide it
So you just create a pointer?

>>105600415
yeah
you think im op?
lamao no im not
op is bait you fkn dweeb

>>105591698 (OP)
I was going to say things like "Anon, how are you supposed to pass a buffer into a function without a pointer to its first element and its length? How are you going to implement interfaces without structures of function pointers? How are you going to have an 'out' parameter without pointers? How are you supposed to do any complex algorithms that require data structures with pointers in them?" Then I realized that languages less primitive than C allow you to do all of these things without explicit pointers (except maybe the part about the data structures that need pointers).

>>105591778
Runs out quite quickly the moment you start using japanese characters.
This is an actual issue i had with my anime sound tracks on Ext4

>>105600146
I'm sorry, but the more I consider what you're doing here, the more it seems pointers are just addresses.
You have two data structures, s_str_a and s_str_b somewhere in memory. str_a is the address of s_str_a and str_b is the address of s_str_b.
Only, s_str_a->text is a pointer, so it will be the address where text[] is somewhere in memory, while s_str_b->text is an array so you actually copy the contents text[] array into the area of the data structure.
What is the point? They're still just addresses. All you have done in one case is structured data in memory differently. One may be faster, but that's comes from the structuring the data so it is dereferenceable from the first pointer, the data is going to start 8 bytes after the address in the pointer.

>>105600696
wrong, see >>105600164

>>105600707
Provenance is something the compiler considers, it is not what the pointer is.

>>105600863
wrong

>>105600932
No, you.
Your code has no idea what the provenance is, the compiled code has no concept of provenance, it's not stored anywhere in the binary (for architectures like x86 at least).
It's something the compiler considers while doing optimizations.

>>105591698 (OP)
>pointers
>infinite growth
You have C brain damage. Pointers are a way to point to something in a memory space. They don't have "infinite growth."

>>105597005
>Array is just a syntactic sugar over pointer.
No they are not. Arrays have no pointers anywhere. An array is a data structure. On the hardware level, your arrays can be separate blocks of memory cells on the chip. Think about FPGAs.

>>105600527
>Anon, how are you supposed to pass a buffer into a function without a pointer to its first element and its length? How are you going to implement interfaces without structures of function pointers? How are you going to have an 'out' parameter without pointers? How are you supposed to do any complex algorithms that require data structures with pointers in them?
C cripples your mind. You don't need pointers for any of these things. You can pass an array "buffer" by value (in a vector or array register or over wires). You can implement interfaces with type-based case dispatching. You can have an out parameter in a register. FPGAs can do all these things without pointers.

>>105600991
low IQ retard
pointer = address + provenance

>>105601009
Wrong. A pointer is just an address.
What that address will be depends on the provenance, something the compiler works out (sometimes badly) during compilation.

>>105600993
>C cripples your mind. You don't need pointers for any of these things.
That's literally what I said in the second sentence.

>>105601061
wrong
>The provenance of a valid pointer is the ID of the specific storage instance to which the pointer refers (or one-past).
>This ID is a genuine component of the pointer value in C’s abstract machine, but does not necessarily take part
>in the object representation of the pointer; in general the provenance of a pointer is not observable.

>>105601117
>>This ID is a genuine component of the pointer value in C’s abstract machine
Yeah, essentially how it is going to be compiled.

>>105601009
>>105601117
>pointer = address + provenance
Provenance is more C brain damage. It doesn't really exist. Pointers can have more than an address, like type information or the size or bounds of what is being pointed to. Those actually exist as bits in the pointer.

>>105601245
dumb retard

>>105601288
retarded post

>>105601291
Have some light reading.
https://dl.acm.org/doi/pdf/10.1145/3290380
And play with the examples to understand what is going on.

>>105601357
So now you agree that pointer = address + provenance?
dumb retard

>>105593410
Linux allows paths up to 4k in a path with no single file name being greater than 255 bytes

>>105601375
No, because you haven't fucking read it yet.

>>105601328
>>105601375
"Provenance" is fake C bullshit that doesn't mean anything.

>>105600993
>Arrays have no pointers anywhere
An array is compiled to a pointer to a memory address it literally is a memory pointer that represents the abstract idea of a chain of bytes.

Every array in op code was compiled to a pointer to somewhere on the stack

>>105601399
https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html

>>105601405
>An array is compiled to a pointer to a memory address it literally is a memory pointer that represents the abstract idea of a chain of bytes.
Arrays don't need pointers or memory addresses. C damaged your brain.

>>105601416
Who mentioned rust?

>>105601431
dumb retard

>>105601425
>Arrays don't need pointers or memory addresses.
Dear god...
You better not reference >>105600146 because that array has a pointer, the one holding the address of the struct it is in.

>>105601425
>Arrays don't need pointers or memory addresses. C damaged your brain.
They do.
Are you talking about placing 512 byte values in the avx-512 registers

>>105599913
This is what cnility does to a mf

>>105601445
>You better not reference >>105600146
The first structure has a pointer and no array The second structure has an array (in the brain damaged castrated C sense of "array") and no pointer.

>>105601469
Would you mind compiling any of this code you are currently imagining in your psychotic break and share the decompiled assembly with us so we can laugh at you?

>>105601469
>The second structure has an array (in the brain damaged castrated C sense of "array") and no pointer.
The pointer is the address of the struct

>>105601489
>The pointer is the address of the struct
Whoops pressed enter too soon
>>105601469
The pointer is the address of the struct plus the size of size_t

>>105601425
>Arrays don't need pointers or memory addresses. C damaged your brain.
They do if you ever want to read or write their contents.

>>105601489
>The pointer is the address of the struct
No, the struct and array are different things.

>>105601492
>The pointer is the address of the struct plus the size of size_t
So you don't know the difference between a struct and a pointer either. The size_t is PART OF the struct, not a pointer. If it wasn't there, the array still wouldn't be a pointer. The "array" is the "char text[]" in "s_str_b", not the whole "s_str_b" itself. "s_str_a" does not have an array, just a size_t and a pointer. C really damaged your brain. I know C better than you people and I don't even like C.

>>105601505
>They do if you ever want to read or write their contents.
That's C brain damage. Arrays are not something made up by C, they're a programming concept that was around for a long time before C. You do not need pointers to read or write contents of arrays.

>>105601532
>You do not need pointers to read or write contents of arrays.
Yet you cannot provide a single example.
Curious

>>105601469
The first structure has a pointer INSIDE IT and the second structure has an array INSIDE IT.
The address to the array in the second structure is just the address of the structure plus the offset of the size value at the beginning of the structure. str_b is essentially str_b->size.
So to reference that array, you need a pointer, which is the pointer to the struct, because you know where the array is in relation to the start of the struct in memory.

Sure. You can define a struct and there are no pointers anywhere. Even if you have a pointer in the struct, there are no pointers actually anywhere yet until you create the struct.
As soon as you create the struct, no matter what it contains, a pointer is created which points to the newly created struct. And regardless of the contents of that struct, each item within it is accessed using an offset of said pointer

>>105601549
>The first structure has a pointer INSIDE IT and the second structure has an array INSIDE IT.
Yes.
>The address to the array in the second structure is just the address of the structure plus the offset of the size value at the beginning of the structure. str_b is essentially str_b->size.
This is a limitation of C because of malloc returning a pointer to a byte. Programming languages do not have to do that.
>So to reference that array, you need a pointer, which is the pointer to the struct, because you know where the array is in relation to the start of the struct in memory.
This is another limitation of malloc. The struct itself does not have to be in memory or have an address.

>>105601573
No, structs don't need to be in memory or have an address.

>>105600014
This is bait.

>>105601405
>An array is compiled to a pointer to a memory address
In C. (Also, in C, pointers and arrays aren't the same thing). That's also why all arrays must be zero-indexed in C: there's no way to specify a custom range of indices, because all you have is a pointer to the first element of the array, and you can only specify it in terms of pointer offsets.
In languages that have slices, it will carry a pointer to its first element and something that indicates the length. Some languages have custom ranges of index (e.g. -7..7 rather than 0..14], in which case slices will have that as well. This extra information allows bounds checking and (like I said) custom ranges of indices.
Of course, the pointer will be there in assembly, but it's not exposed to the programmer.
Just like how you don't need to make the programmer write custom tables of function pointers to have inheritance, and you don't need to make the programmer use pointers to have out variables, you don't need to make the programmer use pointers to let them use arrays.

>>105601641
dumb retard, see >>105601117

>>105601607
You're correct. In the scenario you have described they are unused in the code and thus optimized by the compiler and excluded from the program

>>105601607
Where would a struct be stored if not in memory?

>>105602292
In the registers, or some kind of block RAM like an FPGA. It doesn't have to have a memory address.

>>105602341
oh i get it, youre retarded

>>105602341
>In the registers, or some kind of block RAM
Block RAM... You mean memory?

How do you propose register storage of a struct? Writing a compiler that takes structs and chunks them into 8 bytes and spreads them across registers?
That sounds useless and extremely limiting. What's the maximum size of a struct if we spread it across all register? Like maybe 128 bytes of on chip storage and then you run out of free registers to operate on the struct with,?
Literally retarded

>>105602360
>oh i get it, youre retarded
>>105602446
>How do you propose register storage of a struct?
You know, for the System V ABI, struct fields will be passed in registers as if they were individual parameters. Here's an example showing proof if you don't believe me; just read the assembly.
https://godbolt.org/z/xxb94zfKx
Furthermore, it's a common optimization to hold struct fields in registers as opposed to on the stack as long as the values of those registers are stored back into the struct before it's used (like if its address is exposed or it's returned from a function).
It's really not that amazing to store structures in registers at least part of the time.

>>105602446
>Block RAM... You mean memory?
It's not part of a linearly addressed memory like C mandates. You can't have a pointer to it from somewhere else. Each block RAM can be used for an array but the array doesn't have an address. There's no concept of what's "before" or "after" the RAM like there is in C. In C, you have an array or struct that has bytes "before" it and "after" it and you can do pointer arithmetic to get to those bytes.
>How do you propose register storage of a struct? Writing a compiler that takes structs and chunks them into 8 bytes and spreads them across registers?
In most programming languages, it doesn't have to be in one big linearly addressed memory or accessible from somewhere else. Your struct of 1 int and 3 floats might be stored in 3 FPU registers and one integer register. Ada and Pascal for example allow this.