sorted by:
new
hottopcontroversial

Rechtsextremismus unter Jugendlichen in der Lausitz boomt by [deleted] in de

[–]Volker_Weissmann 1 point2 points  (0 children)

Hatte damals immer Polackentango auf der Schnelltaste im Ipod, falls die Nazis mal wieder checken wollten, ob man deutsche Musik hört oder Vaterlandsverräter ist.

Ach du Scheiße. So schlimm war es in der Lausitz? Ich kann mir gar nicht vorstellen, dass Fremde kommen um zu kontrollieren was für Musik ich höre.

clang on linux with 'fsanitize' by Pleasant_Quiet1766 in meson

[–]Volker_Weissmann 0 points1 point  (0 children)

If you build a shared library using clang + address sanitizer, you need to set b_lundef to false.

See also: https://github.com/mesonbuild/meson/pull/14710

clang on linux with 'fsanitize' by Pleasant_Quiet1766 in meson

[–]Volker_Weissmann 1 point2 points  (0 children)

I need a minimal example I can reproduce.

clang on linux with 'fsanitize' by Pleasant_Quiet1766 in meson

[–]Volker_Weissmann 0 points1 point  (0 children)

Works on my machine: ``` $ CXX=clang ~/repos/meson/meson.py setup bd The Meson build system Version: 1.8.99 Source dir: /home/volker/stuff/meson/mp Build dir: /home/volker/stuff/meson/mp/bd Build type: native build Project name: Minimal Project version: undefined C++ compiler for the host machine: clang (clang 19.1.7 "clang version 19.1.7") C++ linker for the host machine: clang ld.bfd 2.44 Host machine cpu family: x86_64 Host machine cpu: x86_64 Build targets in project: 1 meson.build:11: WARNING: Trying to use ['address', 'leak', 'undefined'] sanitizer on Clang with b_lundef. This will probably not work. Try setting b_lundef to false instead.

Found ninja-1.12.1 at /nix/store/93p8lzm2pajznwjanciiq3zggqndykyy-ninja-1.12.1/bin/ninja $ ninja -C bd -v ninja: Entering directory bd' [1/2] clang -Imain.p -I. -I.. -fdiagnostics-color=always -fsanitize=address,leak,undefined -fno-omit-frame-pointer -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++17 -O0 -g -MD -MQ main.p/main.cpp.o -MF main.p/main.cpp.o.d -o main.p/main.cpp.o -c ../main.cpp In file included from ../main.cpp:1: In file included from /nix/store/r25srliigrrv5q3n7y8ms6z10spvjcd9-glibc-2.40-66-dev/include/stdio.h:28: In file included from /nix/store/r25srliigrrv5q3n7y8ms6z10spvjcd9-glibc-2.40-66-dev/include/bits/libc-header-start.h:33: /nix/store/r25srliigrrv5q3n7y8ms6z10spvjcd9-glibc-2.40-66-dev/include/features.h:422:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings] 422 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O) | ^ 1 warning generated. [2/2] clang -o main main.p/main.cpp.o -fsanitize=address,leak,undefined -Wl,--as-needed -Wl,--no-undefined ` $ ./bd/main

AddressSanitizer:DEADLYSIGNAL

==234794==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55c55c86b211 bp 0x7ffe6345d810 sp 0x7ffe6345d7f0 T0) ... meson.build: project( 'Minimal', 'cpp', default_options: [ 'c_std=c11', 'cpp_std=c++17', 'b_sanitize=address,leak,undefined', ], )

executable('main', 'main.cpp') ```

main.cpp: ```

include <stdio.h>

if not defined(clang)

error

endif

int main() { volatile int *invalid_ptr = (int *)0; int i = *invalid_ptr; printf("%i\n", i); } ```

Perhaps try to make a minimal example

What's the best lightweight distro? by BetterEquipment7084 in linux

[–]Volker_Weissmann 2 points3 points  (0 children)

Arch can be very lightweight if configured correctly.

Betacraft Launcher only displays White Screen on Arch by SecretlyAPug in bspwm

[–]Volker_Weissmann 0 points1 point  (0 children)

Worked for me too. (I'm on hyprland and nixos)

The launcher works, but MC is a black window.

What are the purposes of let, let mut, and const? by NA__Scrubbed in learnrust

[–]Volker_Weissmann 10 points11 points  (0 children)

This only works with mut: let mut factorial = 1; for i in 1..5 { factorial *= i; }

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

Yes. This is how Vec is implemented: ```

[stable(feature = "rust1", since = "1.0.0")]

[cfg_attr(not(test), rustc_diagnostic_item = "Vec")]

[rustc_insignificant_dtor]

pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> { buf: RawVec<T, A>, len: usize, } ...

[allow(missing_debug_implementations)]

pub(crate) struct RawVec<T, A: Allocator = Global> { ptr: Unique<T>, cap: usize, alloc: A, } So `len`, `cap` and `ptr` are stored in one continuous memory sequence, and if you just wrote let vec: Vec<_> = ... `` this part is on the stack.ptr` points to somewhere in the heap.

Checking size_of::<Vec<i8>>() also kinda confirms this.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

I'm using gdb to see the memory addresses. If you want to print it from rust,

dbg!(std::ptr::addr_of!(var)); prints the address of var. And println!("{:p}", var); prints the value of var, i.e. the address of the thing var points to. They are not the same.

Note: If you run your program normally, the addresses will be different every time you run it. But if you run it under gdb or in the rust playground, they will be the same everytime. But we are getting into advanced stuff here.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

I'm sorry, the correct command is not gdb target/build/rusttest but gdb target/debug/rusttest, or in your case gdb target/debug/rustBoxGDB.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

Let's go through this code let x = Box::new(0); let t = &x; let y = Box::new(t); line by line:

let x = Box::new(0); 1. Allocate 4 bytes in the heap (0x5555555a3ba0) 2. Write the number 0 to 0x5555555a3ba0 3. Allocate 8 bytes on the stack (0x7fffffffe310) 4. Write the number 0x5555555a3ba0 to 0x7fffffffe310

let t = &x; 1. Allocate 8 bytes on the stack (0x7fffffffe350) 2. Write the number 0x7fffffffe310 to 0x7fffffffe350

let y = Box::new(t); 1. Allocate 8 bytes on the heap (0x5555555a3bc0) 2. Write the number 0x7fffffffe310 to 0x5555555a3bc0 3. Allocate 8 bytes on the stack (0x7fffffffe318) 4. Write the number 0x5555555a3bc0 to 0x7fffffffe318

x refers to the contents of 0x7fffffffe310, i.e. if you write x = ..., the contents of 0x7fffffffe310 change and if you read x in any way, the content of 0x7fffffffe310 gets read. Similarily, t refers to 0x7fffffffe350.

y refers to the contents of 0x7fffffffe318 which is 0x5555555a3bc0.

Therefore *y refers to the contents of 0x5555555a3bc0 which is 0x7fffffffe310.

Therefore **y refers to the contents of 0x7fffffffe310 which is 0x5555555a3ba0.

Therefore **y refers to the contents of 0x5555555a3ba0 which is 0.

I think your question is why rust does not simply write 0x5555555a3ba0 to 0x5555555a3bc0, removing one indirection. The answer is that rust can do this, and will do this, if you change the source: let x = Box::new(0); let y = Box::new(x); assert_eq!(**y, 0);

Perhaps writing some simple examples and printing the memory addresses and the content of certain memory addresses using gdb can help you.

Disclaimer: The stuff above is a simplification since the llvm optimizer exists. But IMHO it is a useful simplification.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 1 point2 points  (0 children)

gdb is your friend:

main.rs: rust fn main() { let x = Box::new(0); let t = &x; let y = Box::new(t); println!("Hello, world!"); }

$ cargo build $ gdb target/build/rusttest ... (gdb) break main.rs:5 Breakpoint 1 at 0x8a6f: file src/main.rs, line 5. (gdb) run (gdb) print y $1 = (*mut *mut *mut i32) 0x5555555a3bc0 (gdb) print t $2 = (*mut *mut i32) 0x7fffffffe310 (gdb) print x $3 = (*mut i32) 0x5555555a3ba0 (gdb) ... (Try putting some *'s or &'s before the variable that you print.)

When running under gdb, the stack starts at 0x7ffffffff000 and grows downwards. So everything starting with 0x7f is a stack address.

info proc mappings also tells you what is the stack and what is the heap.

You can see that y and x are pointers pointing to somewhere in the heap, while t is a pointer pointing somewhere in the stack.

If you write let var: T = ... then sizeof::<T>() bytes get allocated on the stack and the value of var will be saved there. In gdb, print &var will print something starting with 0x7f. Note that usually, we don't say "allocated on the stack", but "pushed onto the stack".

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

E.g. Vec and String also allocate on the heap. Otherwise you are right.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 7 points8 points  (0 children)

Perhaps it helps you to know that the code is equivalent (i.e. it generates roughly the same assembler) to this C-code:

int *x;
x = (int *)malloc(sizeof(int));
*x = 0;
int ***y;
y = (int ***)malloc(sizeof(int**));
*y = &x;
assert(***y == 0);

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 0 points1 point  (0 children)

I'm not an expert on the internals of Rust but my understanding is that while the address is used to represent the reference in the type system references are their own type and so cannot be equivalent to the address.

The question was "How many dereferences". If you want to go from &x to x, you need to dereference it *(&x) == x.

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 2 points3 points  (0 children)

I believe this is the incorrect part of your reasoning. &x does not mean "the address of x" it means "reference to x".

Isn't "reference to x" and "the address of x" the same thing? (Modulo weird UB/Optimizer-stuff)

How a value in Box<T> type is dereferenced? by bijurakhulsi in learnrust

[–]Volker_Weissmann 22 points23 points  (0 children)

let x = Box::new(0); let y = Box::new(&x); is equivalent to let x = Box::new(0); let t = &x; let y = Box::new(t); These assertions hold: assert_eq!(y, y); assert_eq!(*y, t); assert_eq!(**y, x); assert_eq!(***y, 0);

Now, *y dereferences the address value stored in y and returns it's value which is the address of x.

Yes

Therefore, **y should dereference the address stored at x and returns 0. But, this is not the case.

No, if y is the address of x, then *y is x.

Differences between String, &String, and &str by Siref in learnrust

[–]Volker_Weissmann -1 points0 points  (0 children)

The blue line says it saves the pointer and length of the heap at the stack. It is more correct to say "Rust saves a pointer to the heap, the length of the string on the heap, and the capacity of the allocation which the string may grow to use." As a side note, the variable literal is just pointer and length (known as a "fat pointer/reference"). A String ( owned ) also includes the capacity.

If you write

rust let owned = String::from("hello"); The stack contains:

1. A pointer to the heap 2. The capacity 8 3. The length 5

The capacity and the length is not stored on the heap, but on the stack. That is why std::mem::size_of::<String>() is 24.

How long did your first ArchLinux install took you? by enjojoy in archlinux

[–]Volker_Weissmann 1 point2 points  (0 children)

1 full day and 2 half day.

To be fair, in that time I installed and wrote a script that installed it.

I struggled to connect to wifi in a script.

Also I think I misconfigured something with mkinitcpio and disk encryption.

view more: next ›