Why not? This wasn't found by source review. The computer was slow, somebody looked into why. The bug was discovered via analysis of binary artifacts, and only then traced back to the source. Bruce Dawson does this all the time on Windows.
Proprietary software typically does everything within its power to stop you introspecting it.
Also, Windows is just suspicious in general. It's slow, everything makes network requests. Finding malware in Windows is a needle in a haystack. For some perspectives, Its all malware.
It is difficult to find out why Windows is slow again. My colleagues using Windows complain about it regularly, but not not even one ever started an investigation whether there might be backdoor or not, because this would be hopeless. With open-source it is feasible.
> Note that as these machines have not been released for general availability yet, supported and missing features are predictions based on what Apple has changed on a per-SoC and per-machine basis in the past. This page will change rapidly once work begins on support for these machines.
These machines have been available for quite a while.
The same text is on their M3 page, so at this point you have to assume it really means they haven't gotten to a point where the support page needs updating. Although it would be nice if they updated their page to just say that instead I guess beggars can't be choosers.
Do you have a source for transglutiminase used to put the pink slime back together? This is the first I'm hearing it. I thought they just stirred it into the ground beef.
That article is very confused. They're saying that transglutaminase, street name meat glue, extracted from bacteria is literally the same thing as pink slime. Lean finely textured beef, street name pink slime, comes from cows. However processed, it's still beef. You can't squeeze it out of bacteria.
Reading the Wikipedia articles it's pretty clear these are different things, even if both are added to beef in some way.
Of course it's confused. I barely read it. I just remember, as a meat glue enthusiast (glue two skirt steaks together sometime! amazing!) that TG was at the heart of a "pink slime" controversy, as one of the ways manufacturers made salable products out of mechanically separated meat.
I don't, like, agree that it's a real issue! That's my point. TG is more than enough to make a food product "UPF", but a lot of TG meat products are probably a whole hell of a let better for you than non-UPF "olive-oil fried potato chips".
"has no parameters" is not the same as "cannot take arguments". Defining `int main()` does not stop the runtime from passing the usual 3 arguments (typically named argc, argv, envp), it only means that no parameters are bound to those arguments. Technically it's no problem to have a C function ignore its arguments by not binding parameters. Way too many programmers seem to not understand the difference between parameter and argument.
Surely part of the problem is having a distinct term and handling for parameters passed to functions. What is the point? It seems confusing with no upside.
Do you find the difference between abstract and concrete confusing? Or the difference between container and contents? Is that a pointless distinction with no upside?
I do agree these are useful concepts to distinguish, but I don't get the connection to the topic at-hand. To me, there is just the function signature. I don't see a benefit to referring to passed values as distinct from received values. To my ear "argument" and "parameter" are perfect synonyms.
> referring to passed values as distinct from received values.
That’s not the distinction being made by those terms.
“Parameter” refers to a named variable in a function definition.
“Argument” refers to an actual value that’s passed to a function when it’s called.
It’s exactly the same as the distinction between variables and values (which you probably see the use for), just applied to the special cases of function signatures and function calls.
(As an aside, in the lambda calculus this relationship becomes a perfect equivalence: all variables are parameters and all values are arguments.)
> "A parameter is a special kind of variable used in a function to refer to one of the pieces of data provided as input to the function. These pieces of data are the values of the arguments with which the function is going to be called/invoked."
> "Parameters refer to the variables listed in a function's declaration, defining the input that the function can accept. Arguments, however, are the actual values passed to the function when it is called, filling the parameters during execution."
While you might be tempted to "do you" and use your own idiosyncratic definitions, I advise against it, since it makes it difficult for you to understand what others are saying, and vice versa.
lol, it's not a "you do you" thing, that's what they're actually named, "parameters" and "arguments" have distinct objective definitions in this context and those are it. In this specific case it's you who's using made up words for concepts that others already have a specific name for.
...by what authority? c'mon, communication is important, and insisting on the correctness of definitions tanks that.
EDIT: however, I will concede there's good evidence for widespread usage of this, and I'll adjust my usage accordingly. Insisting on "correctness" is just asinine, though.
I believe that since C23 foo() is now a nullary function. As this is the last approved standard and it supersedes all previous standards, it is technically correct to say that de-jure this is what the (unqualified) C standard mandates.
None, but that is not my point. Before C23, fn() already meant the same thing as fn(void) in function definitions, which the situation under discussion here.
C23 changed what fn() means outside a function definition.
Oh, yeah, the codegen for the fn() itself would likely be the same, but the prototype of that definition is still a K&R function. https://godbolt.org/z/Psvae55Pr
Far more common than what exactly? Because if you look at the range of the exponent, you should still come to the conclusion that floats can represent more non-integer numbers than integer numbers.
I just ran cargo check on nushell, and it took a minute and a half. I didn't time how long it took to compile, maybe five minutes earlier today? So I would call it faster, but still not fast.
I was all excited to conduct the "cargo check; mrustc; cc" is 100x faster experiment, but I think at best, the multiple is going to be pretty small.
Did you do it from a clean build? In that case, it's actually a slightly misleading metric, since rust needs to actually compile macros in order to typecheck code that uses them. (And therefore must also compile all the code that the macro depends on.) My bad for suggesting it, haha. Incremental cargo check is often a better way of seeing how long typechecking takes, since usually you haven't modified any macros that will need to be recompiled. On my project at work, incremental cargo check takes `1.71s`.
Side note: There's an effort to cache proc macro invocations so that they get executed only once if the item they annotate hasn't changed: https://github.com/rust-lang/rust/pull/129102
There are multiple caveats on providing this to users (we can't assume that macro invocations are idempotent, so the new behavior would have to be opt in, and this only benefits incremental compilation), but it's in our radar.
The actual reason that you don't have to care about this on your C++ project is because C++ doesn't let you define macros in C++, you can only define them in the preprocessor language. Therefore no compilation is needed to execute them.
https://randomascii.wordpress.com/category/uiforetw-2/
reply