xscott

29 ms·

391.
by xscott 4y ago
Yeah, I'm not confused by C's syntax any more either. However, when I was learning it (about 30 years ago), things were very non-obvious. And there are a lot of people who want to throw the baby out with the bathwater. Go is the
392.
by xscott 4y ago
> Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Hah, I appreciate your point and careful reply, but that's quite an assumption :-) I think using capitalization does qualif
393.
by xscott 4y ago
> There is no actual difference between the two. Rust has raw pointers, references, slices, and arrays, each with special syntax in type/variable declarations. You're conflating those with Boxes, and it isn't adding clari
394.
by xscott 4y ago
A bunch of ways? Maybe it's just confusing because you haven't thought about it before. There's certainly a tiny trade-off about where to put the core type name. If you have a "let" keyword, your declaration is ju
395.
by xscott 4y ago
You changed your post, so this is a reply to the changes. Boxes are containers, not pointers or references. Let's look at all of those those using the star syntax and operator inside of an unsafe block? You'll end up with stuff
396.
by xscott 4y ago
It's clear you prefer the final type as suffix. That just means you need another syntax or keyword (such as "let") to introduce a variable declaration. However function calls, array subscripts, and field accesses are the sam
397.
by xscott 4y ago
Why not solve 100% of the problem? And since pointer syntax is really so rare, you wouldn't even see the suffix operator.
398.
by xscott 4y ago
The biggest problem with C's pointer syntax is that it's prefix. If pointers were suffix, perhaps using a character that isn't doing primary duty as the multiplication operator, there wouldn't be any need for a Gibberis
399.
by xscott 5y ago
Cool stuff. I've also seen generic traits and tuples used to fake function overloading with different arity: trait Foo<T> { fn foo(&self, other: T); }
400.
by xscott 5y ago
> Correct code would be: ... Nah, it's still really broken :-) Here, let's take all the confusing stuff out - no arrays, sinc functions, etc.. This compiles cleanly with -Wall and -Wextra #include <stdio.h> int
401.
by xscott 5y ago
> I appreciate the challenge. :) Thank you for being friendly btw. So many conversations here go south, it's nice to just talk ideas without it being an unpleasant confrontation.
402.
by xscott 5y ago
> I think you may be underestimating how large systems are _today_ I don't think so, and I think you're moving the goal posts on me! :-) I've got a good friend that works at a large search company, and he's happy to
403.
by xscott 5y ago
Interesting. Just to be clear though: if I'm up to date using rustup with stable, `Vec` and `collect` _are_ using this?
404.
by xscott 5y ago
The negative sign doesn't save you. `ii` takes every value in [0,len), so as soon as `ii` gets to `len/2 + 1` the unsigned subtraction became `2^64 - 1` (18446744073709551615), quietly converted/rounded to a pretty big doubl
405.
by xscott 5y ago
Feels like archaeology or a treasure hunt to track that down, but yeah it all looks very clever: https://doc.rust-lang.org/src/core/iter/traits/iterator.rs.h... (collect) https://doc.rust-lang
406.
by xscott 5y ago
I see your point, but I've got some practical objections to it: a) You can't (sanely) initialize a fixed-sized rust array with an iterator. It looks like one of the following: let a = [1.0f64, 2.0, 3.0]; // not c
407.
by xscott 5y ago
> [unsigned] extends the range of valid values versus signed types, which is sometimes useful When is it useful? On a 32 bit platform, for file offsets, maybe that last bit was useful for a few years. But as soon as disks got bigger tha
408.
by xscott 5y ago
> That is integer arithmetic, not pointer arithmetic. Yeah, but I did say: "which operation could any C compiler disallow in practice: converting from pointer to integer, arithmetic on integers, or converting from integer to pointer
409.
by xscott 5y ago
No, I was sloppy when I read it the first time. The second snippet of code is broken, and I (incorrectly) assumed it was a valid translation from the first snippet. My bad. The first snippet is subtle, and I'm not a language lawyer,
410.
by xscott 5y ago
> I used to program on a platform [...] Yeah, and I know that's why the C standard has so much slop in it. They want to keep the window of conformance open for past or future architectures. > If I could, I would disallow integer
411.
by xscott 5y ago
There's nothing in that example that assumes they are adjacent. It only assumes they are in the same (flat) address space. Put a gigabyte between them if you want. If I had used `uintptr_t` instead of `ssize_t`, I think it's eve
412.
by xscott 5y ago
Same compiler and optimization level provides different behavior when you ask it to compile as C vs C++. Gross.
413.
by xscott 5y ago
I originally responded to your code, and you're right about it. That's not what I expected or would want to happen. However, your code doesn't actually address my comment about conversions and arithmetic. Where does this co
414.
by xscott 5y ago
> (I assume in the following that where you wrote `strict`, you meant `restrict`.) Yup, silly typos. Sorry about that.
415.
by xscott 5y ago
> The one who is mistaken here is you, although I shouldn't be surprised that someone can dismiss [...] Yes, I was mistaken in my first read through. I'm taking your indignation with some amusement, but I hope you can be civil
416.
by xscott 5y ago
Catastrophic sounds strong. As far as `restrict` goes, C was never that far behind Fortran in performance. And if maintaining `restrict` for other passes is really important, maybe the order of the passes should be changed. I'm not p
417.
by xscott 5y ago
> It's not sufficient to say "there's an int2ptr cast, so stop optimization." Complicated or not, it's necessary that optimizations do not break correct code. There doesn't seem to be a problem (UB or otherw
418.
by xscott 5y ago
> Thus, this optimization is incorrect and may not be applied. You're right, and I was wrong in my initial take on things. I currently believe the first version of the code is fine, but that the second version is clearly incorrect.
419.
by xscott 5y ago
With regards to optimization passes, does it matter if the analysis is infeasible? We agree the optimization/transformation from the first version to the second isn't valid, so I think it shouldn't have been done. The origin
420.
by xscott 5y ago
Seems like we need a C compiler flag like "--acknowledge-reality", because the compilers for nearly 100% of the server, desktop, and mobile computers in the real world have flat address spaces and do allow arbitrary pointer arithm

More ›