How can I create an account on discuss.rust-lang.org? I tried to sign
up, but clicking the link in the confirmation email and clicking on
“Activate your account” resulted in a response which is literally
“['BAD CSRF']”.
___
Rust-dev mailing list
* Florian Weimer:
How can I create an account on discuss.rust-lang.org? I tried to sign
up, but clicking the link in the confirmation email and clicking on
“Activate your account” resulted in a response which is literally
“['BAD CSRF']”.
Never mind, something is wrong with my Firefox ESR
* Steve Klabnik:
Bugs with crypto don't often happen because of poorly implemented
primitives: they happen when you combine those primitives in bad ways.
Formal analysis doesn't help there.
That's exactly where formal analysis does help. However, real-world
protocols are quite difficult to
* Daniel Micay:
Rust's tasks are often called *lightweight* but at least on Linux the only
optimization is the lack of preemption. Since segmented stacks have been
dropped, the resident/virtual memory usage will be identical.
Doesn't the lack of a corresponding kernel thread save something on
* Daniel Micay:
It's undefined behaviour for a C++ function to throw an exception past an
`extern C` boundary
I don't think this is true. Certainly GCC supports throwing from C as
an extension (if the C side has been compiled with -fexceptions), and
requires that non-throwing functions are
* Steven Blenkinsop:
On Saturday, 19 October 2013, Florian Weimer wrote:
The problem is that if err is of type error, err != nil is true
after the assignment of a pointer value to err. So the usual error
checking idiom doesn't work if your function returns a
pointer-to-struct
* Patrick Walton:
* I can pretty much guarantee you that that simple of a static
analysis to determine stack size is going to fail on any reasonable
program.
It's needed to show total correctness, and often done with tool
support in the embedded space. GCC has some support for it.
* Patrick Walton:
In other words: Why bet, as Go did, that the failure case won't
happen much in practice when we can adopt an error-handling strategy
that rules it out entirely?
Uh-oh, I thought that Rust has ruled out error handling constructs
based on implicit control flow? :-)
But
* Igor Bukanov:
So the Go style is to call a function, check if the was an error,
update the error object (or create a new wrapping the old one) with
extra information relevant to the current call stack frame and
propagate the updated error object to the caller.
It's more common to simply
* Chris Morgan:
I would love this to be the case. It's the biggest problem I had with Go's
error handling: that it's far too easy to just ignore a return value
accidentally.
I did an informal study some time ago, and it does not appear to be
that common a mistake. (I was biased and tried to
* Patrick Walton:
On the other hand, Cindy Rubio-González's work shows that in the Linux
kernel, forgetting to handle error codes is *extremely* common.
http://www.eecs.berkeley.edu/~rubio/
I don't see anything fundamentally different with Go's approach that
will lead to a different
* Skirmantas Kligys:
I am trying to write a native wrapper for
https://github.com/pascalj/rust-expat
(BTW, if there is a native Rust XML parser, I am interested to hear
about it, did not find it). I have trouble calling back into Rust
from C code:
It's probably better to avoid calling
* Graydon Hoare:
How much of a performance penalty is it worth? I believe you can trap
this in C presently with a gcc flag too (-ftrapv); but it's a flag
rarely turned on.
GCC cannot use the OF flag, but LLVM has overflow-checking
instructions, and Clang actually emits instructions using the
* Michael Neumann:
I am writing a redis client [1] for rust but somehow TCP performance
seems to be veery slow. I basically just sent a string
to redis and read the response (I commented out parsing). Doing this
10_000 times takes about 4.5 seconds, while doing the same in Ruby
takes just
I went over tutorial and spotted a few typos (see below).
I think the SHA-1 example shouldn't use the static buffer because it
is not task-safe.
More significantly, the gettimeofday example still uses the wrong
types for time_t and suseconds_t. time_t is usually signed and not
always 64 bit (or
* Ziad Hatahet:
Ah, you mean after repeated invocations of the containing function in case
the timeout event keeps firing?
Yes, that's the problem. In most cases I've seen, the cause for a
timeout does not go away quickly, so such a programming pattern tends
to spread the congestion even
* David Bruant:
Most of my concerns are appearant in the following piece of Go code
(32'41'' in the video):
c:= make(chan Result)
go func() { c - Web(query) } ()
go func() { c - Image(query) } ()
go func() { c - Video(query) } ()
timeout :=
* Ziad Hatahet:
On Wed, Jul 11, 2012 at 10:27 AM, Florian Weimer f...@deneb.enyo.de wrote:
This approach is fundamentally broken. If the timeout ever kicks in,
goroutines will pile up without bounds.
I just want to be clear on your comment. You mean the goroutines would pile
up
* Patrick Walton:
// after:
if foo() == bar then 10 else 20
This paves the way to:
if foo() == bar then
f();
g();
I expect that if braces are optional, some users will want an option
to make them mandatory again.
* Niko Matsakis:
Here is a proposal to work around a potentially serious problem with
the modular type classes we have been discussing. The problem, as
explained, is that collections (and possibly other data structures)
can lose coherence if they are used with incompatible implementations
* Igor Bukanov:
With most fonts it is not possible to see that the following ES
fragment should alert 1, not 2. I guess such problems are not
considered high on the list of language designs.
javascript:var a = 1; а = 2; alert(a);
Same problem with ASCII and some fonts:
javascript:var l =
21 matches
Mail list logo
