#what is happening ?

1 messages · Page 1 of 1 (latest)

atomic crypt
#

there should be a value to increment since += doesn't see any value it won't increment ?

grave field
#

No

#

what happens is

#

undefined can start in any value

kind idol
#

in debug mode it's usually 0xaaaaa....

#

which i think is negative for an i32

grave field
#

(in this case from -2,147,483,647 to 2,147,483,647)

atomic crypt
grave field
#

undefined on debug is 0xAAAAAAAAAAAA

#

So it's a real big number

#

😄

kind idol
#

i think it's a real small one actually

#

so this is running forever bc it's always less than 1

grave field
kind idol
#

but it won't actually run forever, just "forever"

grave field
#

the magnitude is big

#

Either way

#

Yes, it will run till it reaches 2

#

which is a lot of iterations

knotty cipher
#

You can probably see this by printing the start

atomic crypt
kind idol
#

only in debug mode

#

the obvious solution is to do var start: i32 = 0;

grave field
#

Is whatever value, in debug mode for ease of debugging is 0xAAAAAA

atomic crypt
#

wait wait wait it doesn't make sense to me it is -1 but i am incresing it should go up

hasty tree
#

my understanding is undefined means "don't set this value to anything" - i.e. it'll be whatever value the memory occupying that space was before you allocated it

grave field
#

indeed

grave field
atomic crypt
kind idol
#

0xaaaa < 1 if you interpret 0xaaaa as a signed 32-bit int

#

(the point is that the sign bit is set)

knotty cipher
#

Clarifying question, is any undefined set to that?

kind idol
#

in debug mode, yes

atomic crypt
#

not always minus

kind idol
hasty tree
grave field
#

undefined in debug is -1563262968

#

in i32

#

undefined is 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... fitted to the size of integer you are using

#

-1563262968 to 1 is a lot of iterations that might seem like forever, specialy while printing

atomic crypt
#

it depends on the type size

hasty tree
#

the value of what undefined ends up being does depend on the type size, but that value isn't really relevant to what undefined is

atomic crypt
hasty tree
#

that's wrong

atomic crypt
#

prove

#

undefined always return the type size

hasty tree
grave field
#

what the value of undefined is is related to the representation

But what undefined is is not

Undefined is the absense of being defined, in debug it has a value given that is easier to debug that way

on release modes it will have the value that memory space have, sometimes is 0, sometimes is not

hasty tree
#

coincidence

grave field
atomic crypt
hasty tree
#

the fact that undefined happens to be 8 with a i8 is entirely coincidence

grave field
#

Use undefined to leave variables uninitialized:

assign_undefined.zig

const print = @import("std").debug.print;


pub fn main() void {
    var x: i32 = undefined;
    x = 1;
    print("{d}", .{x});
}

Shell

$ zig build-exe assign_undefined.zig
$ ./assign_undefined
1

undefined can be coerced to any type. Once this happens, it is no longer possible to detect that the value is undefined. undefined means the value could be anything, even something that is nonsense according to the type. Translated into English, undefined means "Not a meaningful value. Using this value would be a bug. The value will be unused, or overwritten before being used."

In Debug mode, Zig writes 0xaa bytes to undefined memory. This is to catch bugs early, and to help detect use of undefined memory in a debugger. However, this behavior is only an implementation feature, not a language semantic, so it is not guaranteed to be observable to code.

atomic crypt
#

but

#

where are those random minus numbers coming from ?

#

sorry it is confusing a little bit

stuck spear
#

if you dont want it to be undefined

#

give it a value

#

it has nothing to do with type size

grave field
#

more like

#

negative numbers use a representation form that let us decide in binary what is a negative number

atomic crypt
#

how a lie explain where are they coming from ?

stuck spear
#

which can and will be random in most cases

#

in debug mode it wont be random

#

but in release modes it will

grave field
#

if the number that the memory held before happens to match what a negative number representation, it will be negative

atomic crypt
stuck spear
#

either way: you are using undefined wrong, you should be defining the value to be "0" or something

grave field
#

yep

stuck spear
#

anytime you read undefined, you are doing something wrong

grave field
#

the point is undefined is whatever and shouldn't be used

atomic crypt
stuck spear
#

no

#

undefined is undefined

#

it is "any value"

#

dont depend on it

grave field
#

read the text I sent

#

In Debug mode, Zig writes 0xaa bytes to undefined memory. This is to catch bugs early, and to help detect use of undefined memory in a debugger. However, this behavior is only an implementation feature, not a language semantic, so it is not guaranteed to be observable to code.

stuck spear
atomic crypt
# stuck spear no

aaaaah confusing how is it undefined while it is generating values

stuck spear
#

please read the documentation

grave field
stuck spear
#

quote from the documentation: "Not a meaningful value. Using this value would be a bug. The value will be unused, or overwritten before being used."

grave field
#

when you get memory, almost never is clean, so it has the value it was there before

But the text like it says, undefined means is not a meaninful value, it's a value that make no sense to use before asigning it to something

atomic crypt
#

well the docs are good but it is missing some points

vague vault
#

Not sure if that's what you meant

#

But worth pointing out nonetheless

#

0xaaaaaaaa has the top bit set, for instance.

#

But indeed, in release modes, it really will be whatever the memory had in it already.

#

And that doesn't have any guarentee about it at all

#

Thus, it can be any value

#

undefined is generally useful for times where you are literally about to overwrite its value anyway, and only want to declare its existent right now.

#

Memory allocators also set freed memory to the same 0xaaaaaaaa pattern to aid with debugging too.

#

You also can find that .deinit() functions will overwrite the structure with 0xaaaaaaaas for similar reasons too.

stuck spear
vague vault
#

Perhaps a better question is: What things do you think it's missing that you'd want it to mention?
Or, How would you improve it?

atomic crypt
merry galleon
#

from the website:

In Debug mode, Zig writes 0xaa bytes to undefined memory.

When you compile in debug and set a value to undefined, it'll be filled with 0xAAAA... (all the bytes will be set to 0xAA). this is an intentional decision to make it easier to spot errors

In release, nothing actually happens and nothing is set - if you access the value without defining it, all bets are off and you'll be interacting with dirty memory

opaque sluice
#

undefined is used as a placeholder. The value is not strictly defined at runtime (in release). The compiler reserves some space on the stack for the variable and nothing more, meaning that the variable's value can be anything that was at its place in memory beforehand - most likely junk. Hence the name undefined - the value is not defined by a known rule when created and cannot be dependent on, otherwise it's an undefined behavior.

vague vault
#

I've always kinda thought that the keyword should be uninitialized or something similar, as I've seen quite a lot of people confuse it - and there's not really a good reason to make it abstract.

#

But yeah - no value is being generated there.

#

It was just already there from some previous operation.

tulip canyon
#

Then again, it is initialized, just not to a fixed default value or a value of your choosing. So it is literally undefined. Maybe call it "unspecified".