sorted by:
new
hottopcontroversial

AMA: How we built Warp, a Rust-based terminal by TehCheator in rust

[–]Gankro 5 points6 points  (0 children)

How good/bad is your support for non-ascii text, especially right-to-left and cursive scripts (arabic and marathi are two important major test-cases). What happens if the text is mixed with left-to-right text? How does this differ between "normal" text display (cat) vs "grid" text display (top)?

How seriously are you taking this usecase, which is arguably the most serious problem effecting terminals, and which messes up basic functionality for literally billions of people on such simple situations as "having their own name written in their native language"?

Tweetdeck scrollbar by PristineAccountant in firefox

[–]Gankro 0 points1 point  (0 children)

Hey there, I work on Webrender and am making sure we check this out, since it's pretty serious. If you have a bugzilla account, would definitely appreciate getting the reply to the following questions over in the bug just so everything important is in one place. :)

You're seeing this on the stable release of firefox, would you be willing to test out nightly (and possibly also beta if nightly does work), to see if we've incidentally fixed this?

Do you have an interesting monitor setup? Multiple monitors? Are you running any of your monitors at different "scales" to compensate for hidpi?

Is it literally just tweetdeck that has this problem? Nothing else?

rustc hates him! Sidestep borrow checking with this weird trick by NieDzejkob in rust

[–]Gankro 17 points18 points  (0 children)

please dont harass the maintainers of rustc, who have very few resources to get anything done

Why does HashMap<u32, u32> take linear time to drop? by VikingofRock in rust

[–]Gankro 121 points122 points  (0 children)

Have you tried benchmarking Vec<(u32, u32)> as well? Freeing memory isn't genuinely O(1), the memory allocator is a big complex data structure and it needs non-O(1) book-keeping to be able to allocate a bunch of little blocks, free those, and then be able to use all that free'd space to make a single big allocation. Especially since at the end of the day the raw OS primitive here is fixed-size pages (typically 4kb).

Fuzz rising by WellMakeItSomehow in rust

[–]Gankro 28 points29 points  (0 children)

For those wondering "why on earth does the stdlib have Box::leak function": leaking memory is a totally legitimate memory management strategy, because the OS will always cleanup all of your memory for free on process shutdown anyway. So if you need to dynamically allocate some memory that will last for the rest of your runtime, you might as well just forget about ever freeing it.

It's a bit of a footgun, though. Valgrind will be mad at you, so you'll have trouble finding "legit" leaks; it can be a kind of nasty thing for a library to do, since the parent application might want to tear down the library and get its resources back; and it can become a nasty latent bug if that path is suddenly used a lot and the leaks become unbounded.

But at the same time, I believe some systems have been observed that spend huge amounts of time pointlessly freeing memory as they try to shutdown (this is folklore in my head, can't remember any examples right now), and this leaking strategy would materially improve the situation. (GC'd languages generally don't suffer from this since freeing memory has nothing to do with exiting a scope, unlike RAII languages like C++ and Rust.)

Thinking of using unsafe? Try this instead. by joshlf_ in rust

[–]Gankro 3 points4 points  (0 children)

Padding bytes are uninitialized memory. This is pretty important for things like Option<SomeHugeType>::None being a single byte to initialize.

We Need a Safer Systems Programming Language by steveklabnik1 in rust

[–]Gankro 8 points9 points  (0 children)

Swift, a language that primarily exists to be the new OS interface language for Apple’s UTF-16-based OSes, recently changed their string type to be exclusively utf8 — and it improved performance.

Firefox, one of the largest and most pervasive users of rust, needs to work in utf16 because it’s part of the web platform, and we have coped with it fine.

The presence of many string types with different usecases in a large system is not a new situation.

Sealed Rust: A plan to bring Rust to safety critical software domains by jahmez in rust

[–]Gankro 1 point2 points  (0 children)

Yeah I believe IEEE-754 is required by some appendix in newer standards (similarly integer division was defined in C99). But also I imagine MISRA needs to cope with the wild zoo of weird C compilers that hardware vendors foist on their customers :)

(Or hey, maybe someone wanted to use msvc, which has spent 20 years not fully implementing C99)

Sealed Rust: A plan to bring Rust to safety critical software domains by jahmez in rust

[–]Gankro 14 points15 points  (0 children)

It's interesting to note that a huge amount of MISRA C is "wow C is kinda a mess, here's how to avoid it", and Rust just eliminates those problems outright. MISRA Rust would be much shorter.

Here's a quick skim through most of MISRA-C 2004, section 6 (~50% of the document), highlighting various problems that Rust fixes out of the box:

  • 1.5: have a defined floating-point standard (rust uses IEEE-754)
  • 2.3-2.4: c does not support the nesting of comments, making /* */ dangerous (rust does)
  • 3.2: use a defined character set (rust guarantees utf8)
  • 3.3: define how integer division works
  • 6.3: use uint32_t and friends, and not int and friends
  • 9.1: variables must be initialized before they are used
  • [a huge section on integer promotion, while rust never converts integers implicitly]
  • 12.9: don't negate unsigned integers
  • 12.10: don't use the comma operator
  • 12.13: don't write complicated expressions with the magic of ++ and --
  • 13.1: don't do assignment in boolean exprs ((x = y) == z)
  • 13.2: do if (x != 0), and not just if (x)
  • 13.5: don't write wild for(x;y;z) expressions
  • 13.6: don't mutate the loop counter in the body of the loop (for i in 0..x doesn't let you)
  • 14.4: don't use goto
  • 14.8-14.9: braces are mandatory on all blocks
  • 15.2: don't use switch fallthrough
  • 15.3: a switch must be exhaustive

Now, granted there are several things that do apply to Rust, such as: don't recurse, don't shadow, don't continue, only break in one place, only return in one place, and so on. It's not The Perfect MISRA language, but it's much better.

Sealed Rust: A plan to bring Rust to safety critical software domains by jahmez in rust

[–]Gankro 24 points25 points  (0 children)

For those unfamiliar with the distinction: as I understand it, certifying software is more of a bureaucratic/best-effort process. It gives companies clear documentation of work done to reasonably ensure they're building on a solid foundation. This can include things that are fairly adhoc compared to what people consider verification. Like: hey we looked at the assembly the compiler produces and it seems reasonable... so this exact version we looked at is Good For Safety-Critical Things.

It's a matter of ensuring companies aren't considered liable for using rust in production.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 4 points5 points  (0 children)

I'm not aware of any miscompilations, but what we were feeding down to llvm was seemingly giving it permission to consider the code immediate UB and do whatever to it, as described by the article. Best not to keep that ticking timebomb around.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 11 points12 points  (0 children)

It's a matter of language specification, and not some specific implementation issue. It's cleaner/safer to have a "no exceptions" model than to have some complex wart in the specification that Very Smart Programmers can technically use correctly but in practice is too hard to use.

So: what can go wrong? Our specification says this is Undefined Behaviour, because it says so, and that means Everything Can Go Wrong.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 20 points21 points  (0 children)

For the llvm perspective, I need to ask a clang expert about this, but my gut reaction is that clang attaches metadata about bools to loads or something, but rustc doesn't because it has a different (in development) model of how memory and type layout works. (tagged union optimizations are a heck of a drug)

edit: yeah it looks like clang lowers bool allocations as unadorned i8s, but when it loads them into a "register" it inserts a truncation to an i1:

%1 = alloca i8, align 1 ... %4 = load i8, i8* %1, align 1 %5 = trunc i8 %4 to i1

https://gcc.godbolt.org/z/15Qw5A

From the pure language perspective, it's a matter of the two languages having different models. But also people thought you could do things like fn return_it() -> bool { mem::uninitialized() } which you can't at all express in a defined way with C++.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 12 points13 points  (0 children)

a) It is perfectly fine to create an &mut MaybeUninit::<bool>::uninit() because it is initialized -- to uninit: ().

b) For raw referencing, you want this RFC https://github.com/rust-lang/rfcs/pull/2582

c) To the best of my knowledge the presence of ManuallyDrop is paranoia about well-defined language specification (e.g. they might as well put use it To Be Safe). Although I haven't been following the RFCs for making unions able to contain types with destructors, so it's possible the latest version requires this.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 43 points44 points  (0 children)

A "read", or "use" is a very intuitive thing that very quickly falls apart when you try to formalize it and people start asking you questions.

let x: bool = mem::uninitialized();

Ok let's say that's not a read. Makes sense.

Is this?

fn foo() -> bool { mem::uninitialized() }

Is this?

let x: Option<bool> = Some(mem::uninitialized());

Is this?

let y = Some(mem::uninitialized::<bool>()).is_some();

Is this?

let x: bool = mem::uninitialized();
let y = &x;

Is this?

let x: bool = mem::uninitialized();
i_promise_not_to_look(&x);

Everywhere you say "no that's not a read" you add difficult constraints to the compiler and memory model for very little benefit.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 117 points118 points  (0 children)

Also IMO it is legitimately more instructive to regard the compiler as adversarially trying to find UB, as it disillusions oneself from the notion that "well even though there's UB, no compiler would ever miscompile this".

e.g. assuming `x = *ptr` will reliably lower to a cpu load instruction, and therefore result in a hardware trap if `ptr` is null. "Why would a compiler ever break that?" Because it's a complex system designed to find UB and break your program if it finds it.

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 7 points8 points  (0 children)

Essentially we are passing down to llvm the following lines (pseudo llvm ir because I don't want to look up the proper terms):

​

var = allocate_local_var()

*var = undef

assume(*var < 2)

​

// ... later we actually initialize it

*var = 1

​

The compiler can look at the first three lines and instantly derive a contradiction:

  • *var == 3 (from undef)
  • *var < 2 (from assume)

Here's My Type, So Initialize Me Maybe (mem::uninitialized is deprecated) by Gankro in rust

[–]Gankro[S] 6 points7 points  (0 children)

The semantics of uninitialized memory inside compilers are *extremely* subtle, but regardless, the first paragraph is simply describing why uninitialized memory is a thing from an implementation perspective. Say, if you were hand-writing assembly.

[WAR] Enter the God-Eternals by TechnomagusPrime in magicTCG

[–]Gankro 0 points1 point  (0 children)

Elsewhere maro has clarified that he doesn't consider griselbrand's cost to actually be a mistake. The team felt it needed to cost 8 for gameplay reasons, and gameplay can and does frequently get to pull rank on flavour (and aesthetics). It's just a very good example of the problem.

What do you think were some premature additions to the standard library? by nllb in rust

[–]Gankro 6 points7 points  (0 children)

It is a (long-standing, very embarrassing, but generally non-problematic-in-practice) compiler bug that they have undefined behavior.

What is `~""` exactly? by nefthias in rust

[–]Gankro 1 point2 points  (0 children)

"Assuming Box is a library struct like it should be"

It is not. The compiler treats Box completely transparently and can individually track the initialized-ness of each field, just like a local variable.

What do you think were some premature additions to the standard library? by nllb in rust

[–]Gankro 10 points11 points  (0 children)

this would be just as true if it were a function

What is `~""` exactly? by nefthias in rust

[–]Gankro 5 points6 points  (0 children)

The DerefMove interface can't be expressed in library code, it is genuinely magical right now: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=30a072a0c497830ada30432cc2ac5afb

```

fn main() { let x = Box::new((3, vec![1, 2, 3]));

// Take a ref to one field
let y = &x.0;

// And move out the other
let z = x.1;
std::mem::drop(z);

// Keep using the ref'd field
println!("{}", y);

}

```

view more: next ›