Re: [rust-dev] Rust crypto highlights
Regarding rust-crypto and timing attacks: in general the library tries to provide constant time implementations where possible. There are two implementations of AES - the AES-NI implementation and a bit-sliced pure software implementation. There isn't currently a table lookup based implementation included. I believe that the AES-NI implementation is likely constant time since all that actual crypto work is being done by the AES-NI instructions. The bit sliced software implementation is hopefully constant time - there aren't any conditionals or table lookups on keys, plaintext, or ciphertext in the code. However, no one has verified that LLVM optimizations don't add some in. Memory comparisons are done using assembly code to prevent LLVM doing optimizations and there are implementations for x86 and ARM. It might be possible to adopt these routines to build something like rust-constanttime. Rust-crypto isn't currently doing anything special to protect key material or plaintext data in memory other than using as little unsafe code as possible. -Palmer Cox On Fri, Oct 3, 2014 at 9:35 PM, Kevin Cantu m...@kevincantu.org wrote: Thanks for the updates, Tony! Kevin On Wed, Oct 1, 2014 at 1:47 PM, Tony Arcieri basc...@gmail.com wrote: On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls ea...@lastyearswishes.com wrote: Is there an Ed22519 implementation for Rust yet? There's an Ed25519 binding in sodiumoxide: https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs Also, I take it none of this is actually secure yet, since it's not been audited and lacks time-constant code and what not sodiumoxide is fine, since it's a binding to the libsodium C/ASM code. Likewise rust-openssl is fine Pure Rust implementations of cryptographic primitives are definitely in need of expert scrutiny before they should be used for anything serious. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to find Unicode string length in rustlang
What about renaming len() to units()? I don't see len() as a problem, but maybe as a potential source of confusion. I also strongly believe that no one reads documentation if they *think* they understand what the code is doing. Different people will see len(), assume that it does whatever they want to do at the moment, and for a significant portion of strings that they encounter it will seem like their interpretation, whatever it is, is correct. So, why not rename len() to something like units()? Its more explicit with the value that its actually producing than len() and its not all that much longer to type. As stated, exactly what a string is varies greatly between languages, so, I don't think that lacking a function named len() is bad. Granted, I would expect that many people expect that a string will have method named len() (or length()) and when they don't find one, they will go to the documentation and find units(). I think this is a good thing since the documentation can then explain exactly what it does. I much prefer len() to byte_len(), though. byte_len() seems like a bit much to type and it seems like all the other methods on strings should then be renamed with the byte_ prefix which seems unpleasant. -Palmer Cox On Thu, May 29, 2014 at 3:39 AM, Masklinn maskl...@masklinn.net wrote: On 2014-05-29, at 08:37 , Aravinda VK hallimanearav...@gmail.com wrote: I think returning length of string in bytes is just fine. Since I didn't know about the availability of char_len in rust caused this confusion. python 2.7 - Returns length of string in bytes, Python 3 returns number of codepoints. Nope, depends on the string type *and* on compilation options. * Python 2's `str` and Python 3's `bytes` are byte sequences, their len() returns their byte counts. * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code units count which may be UCS2 or UCS4 (depending whether the interpreter was compiled with `—enable-unicode=ucs2` — the default — or `—enable-unicode=ucs4`. Only the latter case is a true code points count. * Python 3.3's `str` switched to the Flexible String Representation, the build-time option disappeared and len() always returns the number of codepoints. Note that in no case to len() operations take normalisation or visual composition in account. JS returns number of codepoints. JS returns the number of UCS2 code units, which is twice the number of code points for those in astral planes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to find Unicode string length in rustlang
Thinking about it more, units() is a bad name. I think a renaming could make sense, but only if something better than len() can be found. -Palmer Cox On Thu, May 29, 2014 at 10:55 PM, Palmer Cox palmer...@gmail.com wrote: What about renaming len() to units()? I don't see len() as a problem, but maybe as a potential source of confusion. I also strongly believe that no one reads documentation if they *think* they understand what the code is doing. Different people will see len(), assume that it does whatever they want to do at the moment, and for a significant portion of strings that they encounter it will seem like their interpretation, whatever it is, is correct. So, why not rename len() to something like units()? Its more explicit with the value that its actually producing than len() and its not all that much longer to type. As stated, exactly what a string is varies greatly between languages, so, I don't think that lacking a function named len() is bad. Granted, I would expect that many people expect that a string will have method named len() (or length()) and when they don't find one, they will go to the documentation and find units(). I think this is a good thing since the documentation can then explain exactly what it does. I much prefer len() to byte_len(), though. byte_len() seems like a bit much to type and it seems like all the other methods on strings should then be renamed with the byte_ prefix which seems unpleasant. -Palmer Cox On Thu, May 29, 2014 at 3:39 AM, Masklinn maskl...@masklinn.net wrote: On 2014-05-29, at 08:37 , Aravinda VK hallimanearav...@gmail.com wrote: I think returning length of string in bytes is just fine. Since I didn't know about the availability of char_len in rust caused this confusion. python 2.7 - Returns length of string in bytes, Python 3 returns number of codepoints. Nope, depends on the string type *and* on compilation options. * Python 2's `str` and Python 3's `bytes` are byte sequences, their len() returns their byte counts. * Python 2's `unicode` and Python 3's `str` before 3.3 returns a code units count which may be UCS2 or UCS4 (depending whether the interpreter was compiled with `—enable-unicode=ucs2` — the default — or `—enable-unicode=ucs4`. Only the latter case is a true code points count. * Python 3.3's `str` switched to the Flexible String Representation, the build-time option disappeared and len() always returns the number of codepoints. Note that in no case to len() operations take normalisation or visual composition in account. JS returns number of codepoints. JS returns the number of UCS2 code units, which is twice the number of code points for those in astral planes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] reader.lines() swallows io errors
Why not just modify the Lines iterator to return values of IoResult~str? All the caller has to do to unwrap that is to use if_ok!() or try!() on the returned value, so, its basically just as easy to use and it means that errors are handled consistently. I don't see why this particular use case calls for a completely different error handling strategy than any other IO code. -Palmer Cox On Wed, Feb 19, 2014 at 6:31 AM, Michael Neumann mneum...@ntecs.de wrote: Am 19.02.2014 08:52, schrieb Phil Dawes: Is that not a big problem for production code? I think I'd prefer the default case to be to crash the task than deal with a logic bug. The existence of library functions that swallow errors makes reviewing code and reasoning about failure cases a lot more difficult. This is why I proposed a FailureReader: https://github.com/mozilla/ rust/issues/12368 Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] reader.lines() swallows io errors
Thinking about this a bit more, I think that another solution would be:
7 - Update lines() to return an IteratorIoResult and then create an
iterator wrapper that fails on any error except for EOF. I think by using
an extension method, the syntax could be:
fn main() {
for line in io::stdin().lines().fail_on_error() {
print!(received: {}, line);
}
}
Which I don't think is too bad. Importantly, it makes it explicit at the
call site what the desired behavior is while also making lines() behave
like all other IO-related methods do.
So, I now favor of either doing something like this or removing it. I
posted more on https://github.com/mozilla/rust/issues/12368.
-Palmer Cox
On Wed, Feb 19, 2014 at 7:37 PM, Kevin Ballard ke...@sb.org wrote:
On Feb 19, 2014, at 3:40 PM, Jason Fager jfa...@gmail.com wrote:
Can you point to any scripting langs whose lines equivalent just silently
ignores errors? I'm not aware of any; even perl will at least populate $!.
No, because I typically don't think about errors when writing quick
scripts. If the script blows up because I had a stdin error, that's fine,
it was never meant to be robust.
I just commented on #12368 saying that now I'm leaning towards suggestion
#2 (make .lines() fail on errors and provide an escape hatch to squelch
them). This will more closely match how scripting languages behave by
default (where an exception will kill the script).
I opened https://github.com/mozilla/rust/issues/12130 a little while ago
about if_ok!/try! not being usable from main and the limitations for simple
use cases that can cause. Forgive a possibly dumb question, but is there a
reason main has to return ()? Could Rust provide an 'ExitCode' trait that
types could implement that would provide the exit code that the process
would spit out if it were returned from main? IoResult's impl would just
be `match self { Ok(_) = 0, Err(_) = 1 }` and your example would look like
fn main() - IoResult~str {
for line in io::stdin().lines() {
print!(received: {}, try!(line));
}
}
There is no precedent today for having a function whose return type must
conform to a trait, without making the function generic. Furthermore, a
function that is generic on return value picks its concrete return type by
the type constraints of its call site, rather than by the implementation of
that function. I also question whether this will work form an
implementation standpoint. Today the symbol for the main() function is
predictable and is the same for all main functions. With your suggested
change, the symbol would depend on the return type. I don't know if this
matters to rustc; the start lang item function is passed a pointer to the
main function, but I don't know how this pointer is created.
But beyond that, there's still issues here. Unlike in C, a Rust program
does not terminate when control falls out of the main() function. It only
terminates when all tasks have ended. Terminating the program sooner than
that requires `unsafe { libc::abort() };`. Furthermore, the main() function
has no return value, and does not influence the exit code. That's set by
`os::set_exit_status()`. If the return value of main() sets the error code
that will overwrite any error code that's already been set.
Perhaps a better approach is to define a macro that calls a function that
returns an IoResult and sets the error code to 1 (and calls libc::abort())
in the Err case, and does nothing in the Ok case. That would allow me to
write
fn main() {
abort_on_err!(main_());
fn main_() - IoResult() {
something_that_returns_io_result()
}
}
---
While writing the above code sample, I first tried actually writing the
read_line() loop, and it occurs to me that it's more complicated than
necessary. This is due to the need for detecting EOF, which prevents using
try!(). We may actually need some other macro that converts EOF to None,
returns other errors, and Ok to Some. That makes things a bit simpler for
reading, as I can do something like
fn handle_stdin() - IoResult() {
let mut r = BufferedReader::new(io::stdin());
loop {
let line = match check_eof!(r.read_line()) {
None = break,
Some(line) = line
};
handle_line(line);
}
}
Still not great, but at least this is better than
let line = match r.read_line() {
Ok(line) = line,
Err(IoError{ kind: EndOfFile, .. }) = break,
Err(e) = return Err(e)
};
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] issue numbers in commit messages
I believe that bors never does a fast forward merge and that the merge commits always contain the pull number. So, if you have a particular commit and you want to find the issue that it was part of, I believe you can always look look through its children until you find a commit by bors which should have a commit message like: auto merge of #12313 : bjz/rust/tuple, r=huonw which contains the issue number. Let says that the commit you are interested in is 6f39eb1. I think if you run the command: git log --author bors --ancestry-path 6f39eb1..origin/master And look at the commit at the very bottom of the list, that will be the merge commit that you are interested in. I'm not a git expert - there may be a better way to do that. -Palmer Cox On Mon, Feb 17, 2014 at 4:50 PM, Nick Cameron n...@ncameron.org wrote: How would people feel about a requirement for all commit messages to have an issue number in them? And could we make bors enforce that? The reason is that GitHub is very bad at being able to trace back a commit to the issue it fixes (sometimes it manages, but not always). Not being able to find the discussion around a commit is extremely annoying. Cheers, Nick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] issue numbers in commit messages
The PR# and who reviewed it is already available in the merge commit and its already possible to take any arbitrary commit and to see which merge commit merged it into master. So, I don't see any benefit in changing anything about the merge commit. Unless I'm missing something, this isn't a question of information not being available; its a question of that information being inconvenient to get to. I think having bors rewrite the commit messages would be somewhat problematic since it would change all the hashes. So, I think the only solution would be to manually put the issue number into the messages. However, many PRs aren't related to issues. So, if some large percentages of commits are just annotated with no issue or the like, it seems to really impact the utility of this change. Thus, I think it would really have to be the PR# instead of an issue # since every commit is related to a PR. However, I think it isn't a zero impact procedure. I always right the changes I want to merge before opening the PR. So, when I'm making my changes, I don't know what the eventual PR# is going to be. Only after I open the PR with the commits already created, I find out the PR#. So, then I'd have to rewrite all of the commit messages and force push back into the branch to get the numbers right. Its not the worst thing in the world, but it is an extra few steps. So, I strongly agree that the current procedure for finding the github discussion is fairly unpleasant and I very much wish that Github had a button that would take me to the PR that merged it. However, I don't think there is a 100% consistent, zero impact workaround for that missing feature in Github. My vote would be to leave things as they are. A little scripting could improve the situation quite a bit, although it still won't be as nice as being able to click on a link in Github. -Palmer Cox On Mon, Feb 17, 2014 at 9:02 PM, Scott Lawrence byt...@gmail.com wrote: What about having bors place the hash of each commit merged into the auto-merge message? Then finding the PR, and any closed issues, consists of backwards-searching in git-log. (Having bors modify commit messages would probably cause major problems with hashes changing.) On Tue, 18 Feb 2014, Nick Cameron wrote: Adding a few chars to a commit is not onerous and it is useful. You may not want it now, but perhaps you would if you had it to use. _I_ certainly want it, and I think others would find it useful if it was there to use. On Tue, Feb 18, 2014 at 1:37 PM, Steve Klabnik st...@steveklabnik.com wrote: Yeah, I'm not into modifying every single commit, I basically only want what bors already (apparently) already does. -- Scott Lawrence ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] issue numbers in commit messages
If bors rewrites the commit messages, it means that if someone approves commit ABC, what actually gets merged will be commit XYZ. This seems potentially confusing to me and might also make it more difficult to start with a reviewed commit on Github, such as https://github.com/gentlefolk/rust/commit/37bf97a0f9cc764a19dfcff21d62384b2445dcbc, and then track back to the actually merged commit in the history. I'm also not 100% sure, but I think git might have some issues with it as well. If I do my work on a throwaway branch, after merging, will git know that the changes in that branch were merged? Or, will git require me to do a git branch -D to delete that branch? Are there other projects that rewrite commit messages before merging? It seems to me that the ideal case would be for Github to add a link on the commit view page back to the PR that merged that commit. I'd be concerned that if Github adds support for such a feature in the future that it might not work if we've re-written all of the commit messages in the meantime. -Palmer Cox On Mon, Feb 17, 2014 at 9:28 PM, Nick Cameron li...@ncameron.org wrote: You are right, it is about convenient access to the info, not the lack of info. What is problematic about bors rewriting commit messages and changing hashes? My workflow is to always work on throw away branches and merge back into master. Is it common to work on master and merge back on top of your PR? Or are there other problems with changing the hash? On Tue, Feb 18, 2014 at 3:22 PM, Palmer Cox palmer...@gmail.com wrote: The PR# and who reviewed it is already available in the merge commit and its already possible to take any arbitrary commit and to see which merge commit merged it into master. So, I don't see any benefit in changing anything about the merge commit. Unless I'm missing something, this isn't a question of information not being available; its a question of that information being inconvenient to get to. I think having bors rewrite the commit messages would be somewhat problematic since it would change all the hashes. So, I think the only solution would be to manually put the issue number into the messages. However, many PRs aren't related to issues. So, if some large percentages of commits are just annotated with no issue or the like, it seems to really impact the utility of this change. Thus, I think it would really have to be the PR# instead of an issue # since every commit is related to a PR. However, I think it isn't a zero impact procedure. I always right the changes I want to merge before opening the PR. So, when I'm making my changes, I don't know what the eventual PR# is going to be. Only after I open the PR with the commits already created, I find out the PR#. So, then I'd have to rewrite all of the commit messages and force push back into the branch to get the numbers right. Its not the worst thing in the world, but it is an extra few steps. So, I strongly agree that the current procedure for finding the github discussion is fairly unpleasant and I very much wish that Github had a button that would take me to the PR that merged it. However, I don't think there is a 100% consistent, zero impact workaround for that missing feature in Github. My vote would be to leave things as they are. A little scripting could improve the situation quite a bit, although it still won't be as nice as being able to click on a link in Github. -Palmer Cox On Mon, Feb 17, 2014 at 9:02 PM, Scott Lawrence byt...@gmail.com wrote: What about having bors place the hash of each commit merged into the auto-merge message? Then finding the PR, and any closed issues, consists of backwards-searching in git-log. (Having bors modify commit messages would probably cause major problems with hashes changing.) On Tue, 18 Feb 2014, Nick Cameron wrote: Adding a few chars to a commit is not onerous and it is useful. You may not want it now, but perhaps you would if you had it to use. _I_ certainly want it, and I think others would find it useful if it was there to use. On Tue, Feb 18, 2014 at 1:37 PM, Steve Klabnik st...@steveklabnik.com wrote: Yeah, I'm not into modifying every single commit, I basically only want what bors already (apparently) already does. -- Scott Lawrence ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Will smart-pointer deref operator allow making iter::ByRef more generic?
Hi, I was looking at some structs in Rust that implement the Decorator pattern - structs that take some value, wrap it, and then provider the same interface as the value that they are wrapping while providing some extra behavior. BufferedReader is an example here - it takes another Reader and provides buffering functionality while still presenting the same interface. Anyway, I noticed that there seem to be two different patterns that are being used in Rust to do this - some structs take ownership of the value to be wrapped while other structs take a borrowed reference to the object to be wrapped. Both approaches have advantages and disadvantages. If you take ownership you have the advantage that the resulting struct is Send, however if all you have is a reference to the object you want to wrap, it won't work. The following, for example won't compile: let mut r = File::open(Path::new(/)).unwrap(); let br = BufferedReader::new(mut r); If the wrapping struct takes a reference, the example above will work. However, the resulting struct won't be Send. So, in both cases, the result is that some use-cases won't work. I noticed that the iter module addressed this issue with the ByRef struct. All Iterators that wrap other iterators take ownership of the value to be wrapped. If you want to prevent that, you can use ByRef (which hold a reference to the value to be wrapped) and pass it to the wrapping Iterator which takes ownership of the ByRef instance as opposed to the iterator you are wrapping. The problem with ByRef, though, is that it only works for Iterators. Its possible to implement different versions of ByRef for other types as well. However, this seems a bit tedious. This is a relatively common and fairly useful pattern, so it would seem that it would be nice to be able to support all of the use cases for all types. Anyway, its my understanding that future plans for Rust call for a custom derefence trait to be added to allow for the implementation of custom smart pointers. What I was wondering if that trait would also allow for making iter::ByRef into a smart pointer that could provide this type of behavior for any type as opposed to just Iterators. If that's the case, it seems like all of the structs that implement the decorator pattern could be modified to take the value they are wrapping by value and let the caller use the ByRef struct if they would prefer not to transfer ownership of the value to be wrapped. The upsides are that it seems that this would allow all use cases to be met and it would make all the Decorators consistent; the downside is that it would making wrapping a borrowed reference a little bit more verbose. I don't think that would be all that bad, though. This doesn't look too bad to me: let mut r = File::open(Path::new(/)).unwrap(); let br = BufferedReader::new(ByRef::new(mut r)); Thoughts? Things I'm wrong on? Thanks, -Palmer Cox ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust-ci updates (project categories and documentation)
I've got to say, I'm very much against these changes - it sounds like I now need to write some documentation for rust-crypto! Boo! Just kidding - this sounds fantastic. Thanks for the great work! -Palmer Cox On Mon, Jan 20, 2014 at 10:47 PM, Kevin Ballard ke...@sb.org wrote: Now that is beautiful :) Thanks for the quick fix! -Kevin On Jan 20, 2014, at 6:54 PM, Hans Jørgen Hoel hansj...@gmail.com wrote: I've switched from an iframe to proxying: http://www.rust-ci.org/kballard/rust-lua/doc/lua/ A bit slow at the moment. I'll add some caching asap. -- Hans Jørgen On 21 January 2014 01:42, Kevin Ballard ke...@sb.org wrote: That's pretty cool. http://www.rust-ci.org/kballard/rust-lua/doc/luanow contains documentation for rust-lua! Although there are two issues with the documentation as it exists now. Both are caused by the fact that the docs link actually embeds the real documentation in an iframe. The first issue is that the title of the page is always Rust CI. The second is that clicking a link in the documentation will only navigate that iframe, and therefore the URL bar doesn't get updated and the browser back button (and history list) is broken. -Kevin On Jan 20, 2014, at 4:01 PM, Hans Jørgen Hoel hansj...@gmail.com wrote: Hi, Rust-ci (http://www.rust-ci.org/) has been updated with some new features * documentation can be uploaded during Travis CI builds (see project page - owner actions - get config for docs upload) * categorization of projects * projects can now be edited and deleted by owners (aka Web 2.0 compliance) For a view of projects by category see: http://www.rust-ci.org/projects/ I've added likely categories to projects based on name and description, but I've probably missed a few so please take a look at your own project (owner actions - edit project to change). Categories are fixed for now. Give me a ping if you want to have a category added or changed. Projects on the frontpage with a padlock in the status column are missing Travis CI authentication due to an earlier bug. To fix this, go to the project page and select Authenticate. If you encounter any other issues, please report it here: https://github.com/hansjorg/rust-ci Next up: * benchmarks upload (and graphing) cheers, Hans Jørgen ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller trop...@bluewin.ch wrote: Daniel Micay danielmi...@gmail.com wrote: On Sun, Jan 12, 2014 at 1:23 PM, Tobias Müller trop...@bluewin.ch wrote: Isaac Dupree m...@isaac.cedarswampstudios.org wrote: In general, Rust is a systems language, so fixed-size integral types are important to have. They are better-behaved than in C and C++ in that signed types are modulo, not undefined behaviour, on overflow. It could be nice to have integral types that are task-failure on overflow as an option too. As you note, bignum integers are important too; it's good they're available. I think bignum rationals would be a fine additional choice to have (Haskell and GMP offer them, for example). Wrapping overflow is just as bad as undefined behavior IMO. Do you know what undefined behavior is? It doesn't mean unspecified. True, but despite beeing so often cited it won't format your hard disk (even in C). The result of an integer addition will always be an integer in every compiler I know so in this specific case I don't fear the UB. I don't think that's quite accurate. Its true that the result of undefined behavior is unlikely to be that your harddrive is formatted. However, you aren't guaranteed to end up with an integer in any compiler that I'm aware of either. Its subtle, but important to remember that the instruction that actually overflows the integer register isn't really the undefined behavior. Its not that a program is operating in a defined mode and then the integer overflow occurs and then the program transitions into an undefined mode. Instead, a program that will execute an integer overflow at some point in the future is as the mercy of undefined behavior from the very first instruction. The compiler, knowing that you aren't allowed to overflow an integer, uses that information to do a variety of optimizations, including dead code elimination. Since overflowing an integer is undefined, the compiler assumes that you won't do it and will use that assumption to eliminate as much code as possible. So, the end result could be that an entire branch of the program is eliminated. See http://blog.regehr.org/archives/213 (look for Type 3 Functions) for an example. So, the end result of integer overflow undefined behavior might not an actual overflow since the compiler could remove the add instruction along with whatever else it thinks it can. This could result in a program that works fine in debug modes, but once you crank up the optimization level, it fails to run. Or, it could result in a program that runs fine on a particular compiler version, but then fails mysteriously after an update. Or, as in the example, it could result in a program that runs fine, but silently doesn't do an important check. I cannot remember a single case of using signed integers where wrapping would make any sense. It often makes sense in codecs, hashing algorithms and cryptography. I'm sure there exist many cases where _unsigned_ int overflow makes sense. For _signed_ integers I'm a bit sceptical but I am no expert in that field. In any case it should not be the default but rather 'opt-in'. But this is not what I meant. Let me rephrase it differently: Assume that signed int overflow is UB (like in C). That means, all actual overflows at runtime have to be considered bugs. Now I cannot imagine any such case (bug) where guaranteed wrapping would actually behave nicer. If you don't have clear bounds and don't want modular arithmetic, you need big integers. Or proper input validation. The type defines the bounds. And you lose some optimization opportunities. It's treated as undefined because there are more optimization opportunities that way. That's what I wanted to say. If you guarantee wrapping overflow you lose those opportunities. So why not take the path of the rust memory management and enforce bounds statically? It would need annotations on the types, like lifetimes, but it would be very rusty. Like C but safe. Rust isn't supposed to be really hard to write. Complex dependent typing would I'm not sure that this would be so complex. At least not more than the lifetime system. Is simple arithmetics on the bounds. In reality (rust beeing a systems PL) fixed width ints _will_ be used, and I am sure that overflow will often just be neglected. So why not enforce it statically? Tobi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why doesn't rust require mut param prefix at call site?
I could be pretty wrong, so if I am, I apologize and please ignore. Anyway,
I thought I once read somewhere that when you call a function defined like:
fn foo(a: mut int) { ... }
with code that looks like
fn bar(b: mut int) {
foo(b);
}
that despite what it looks like, you aren't really passing the value b into
the function foo(). My understanding, is that when you pass a reference to
foo(), that it takes ownership of that reference making it inaccessible to
any following code. Since this is generally not what anyone wants, Rust
silently re-borrows b and passes that re-borrowed version of the reference
to foo() which takes ownership of it. Since b wasn't actually passed to
foo(), code after the call to foo() can continue to use b since bar() still
owns b.
Anyway, if that is all correct, and I'm not sure how likely that is all to
be correct, it feels like what this email thread really boils down to is a
proposal to eliminate automatic re-borrowing of a mut to mut when
invoking a function. I'm may be wrong, but, I'm also under the impression
that manually re-borrowing would look something like:
foo(mut (*b))
which is extremely unpleasant, so, I'd imagine that the 2nd part of the
proposal is to make some sort of nicer syntax for that.
To me, this doesn't sound as much like a proposal for a change in syntax as
a proposal to remove a bit of magic that Rust is currently doing. I don't
know that I'm necessarily in favor or that though, since it would certainly
make code more wordy. That wordiness might be nice, however, if it makes it
clearer where variables might be mutated (eg: imagine that foo() is
originally defined to take a ,so bar() assumed that the variable won't be
mutated. However foo() is later redefined to take a mut which silently
breaks bar()'s assumption about foo()).
-Palmer Cox
On Wed, Jan 1, 2014 at 11:41 PM, Vadim vadi...@gmail.com wrote:
I think the real answer is at this point nobody wants to tweak basic Rust
syntax yet again. See the other thread about Rust roadmap, etc. Oh
well...
On Wed, Jan 1, 2014 at 3:49 PM, Martin Olsson mar...@minimum.se wrote:
Short version of my question:
Why doesn't rust require mut param prefix at call sites? i.e. to avoid
non-const ref badness that C++ has?
Longer version of my question:
Since this question was asked recently by vadim and not really answered
clearly (imo), I'm also including this longer verbose version of my
question.
For example in C the call f(a,b); might modify b but not a so the
token acts as a call site heads-up flag when reading the code. In C#
the out/ref keywords are mandatory at the call site if the callee uses
them in its param declaration so there you also get a little in hint when
reading the code near the call site. C++ of course has non-const references
so f(a,b); might modify both a and b so the hint is missing and I
really have to look up the code for f() to be sure. If some function
foo() passes a to a bunch of functions then I have to find each such
function and check if a can be modified or not, so potentially I have to
open a bunch of files and read code there before I can fully understand the
code near the call sites.
Because of this many large C++ projects have coding styles that disallow
non-const refs. See for example the google C++ coding style guide:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=
Reference_Arguments#Reference_Arguments
Right now, it seems that rust works similar to C++ in this regard,
meaning that there is no hint at the call site that a parameter may or may
not be modified by the function.
In the snippet below, if I'm reading foo() in main.rs and I wonder which
lines in foo() could possibly change the value of i, then I have to open
up 4 additional files and find the relevant source locations to double
check which functions might mutate their arguments.
Why isn't it a good idea to require some parameter prefix like mut at
the call site so that when I read main.rs I immediately will know which
lines among the calls to funcA()..funcD() that might change the value of
i ?
// ---[ funcA.rs ]---
fn funcA(i: int) - int{
return 2**i;
}
// ---[ funcB.rs ]---
fn funcB(i: mut int) - int {
*i += 1;
return 0;
}
// ---[ funcC.rs ]---
fn funcC(i: int) - int {
return 3**i;
}
// ---[ funcD.rs ]---
fn funcD(i: int) - int{
return 2**i;
}
// ---[ main.rs ]---
fn foo(i: mut int) {
*i += 1;
funcA(i);
funcB(i); // no mut!
funcC(i);
funcD(i);
}
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
Martin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust
Re: [rust-dev] on quality success
Everyone is entitled to their own opinions. However, those opinions should be expressed in a polite manner. Phrases such as Choice he (since its mostly men) and mentally masturbate do not seem to foster a welcoming, inclusive environment. Quoting from https://github.com/mozilla/rust/wiki/Note-development-policy#conduct: * We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, disability, ethnicity, religion, or similar personal characteristic Thanks, -Palmer Cox On Tue, Dec 31, 2013 at 6:56 AM, spir denis.s...@gmail.com wrote: Holà! [This is a rather personal and involved post. Press del if you feel like it...] [also, it is long] [copy to rust-dev mailing list: actually the post is inspired by a thread there Thoughts on the Rust Roadmap] There is a point obvious to me; apparently most people including many language designers don't share it, or act as if they did not: a language should be successful iff it is of high quality A kind of symmetric statement also holds; let us hope low quality languages have no success! There are various reasons to hope this, the most stupid beeing that successful languages influence others, present future. This is in my view a symptom of our civilisation's funny spirit (read: madness), and related to the actual points I intend to state (if, for once, I manage to express my thought). Apparently, many language designers proceed more or less the following way: there are a few key points (for them) they consider mis-designed or missing or wrong in some way in existing languages (not all the same for every language). Thus, they want to make a language that repairs these points, all together. Then, certainly in fear that too many changes may repel potential adopters of their language, in hope to maximise its chances of success *despite* it breaking habits on the key points more important to them, they won't change anything else, or only the bare minimum they can. They want instead to remain as mainstream as possible on everything else. [4] I consider this spirit bad; I mean, very bad. This is the way basic design errors propagate from successful languages to others, for instance. [1] Apparently, it takes a great dose of courage to break any existing practice in a _new_ language: tell me why, I do not understand. Note that I am here talking of wrong design points in the opinion of a given language designer. Choices he (since it's mostly men) would not do if programming were a new field, open to all explorations. (There are indeed loads of subjective or ideological design points; see also [1] [3]) However, while programming is not a new field anymore, it is indeed open to all explorations, for you, for me, if you or me wants it. Nothing blocks us but our own bloackages, our own fears, and, probably, wrong rationales, perhaps non-fully-conscious ones. Deciding to reuse wrong, but mainstream, design decisions in one's own language is deciding to intentionally make it of lower quality. !!! Funny (read: mad), isn't it? It is thus also intentionally deciding to make it not worth success. This, apparently, to make its actual chances of success higher. (Isn't our culture funny?) Then, why does one _actually_ make a new language? For the joy of making something good? To contribute to a better world, since languages and programming are a common good? [2] For the joy of offering something of as high a quality as humanly possible? Else, why? For fame, honour, status, money, power? To mentally masturbate on the idea of having made something sucessful (sic!)? We are not in need of yet another language trying, or pretending, to improve on a handful of disparate points, leaving all the rest as is, meaning in bad state. And, as an example, we are not in need of yet another failed trial for a successor to C as major low-level lang. Differences, thought of by their designer as significant quality improvements, are the *reasons* for programmers to adopt a new language. There are the _only_ (good) reasons to do so. Thinking that programmers may adopt a new language _despite_ its differences is thinking backwards; this, in addition to preventing oneself from working for the common good; by fear, probably; fear of truely thinking by oneself and/or of making one's true thinking public truely. (I can understand that, however: I often do not disclose my thinking by fear of the terrible level of violence, in my view, present in the programming community [hum!], and among geeks in general. This, rather than sharing and mutual help and cooperation, for the common wealth. Our civilisation... again.) I have recently decided to adopt possible differences even if i am not that convinced of their betterness; to give alternatives a try; to give them at least a chance to show us (or just me) how good they actually are, or not, in practice, maybe
Re: [rust-dev] RFC: Iterator naming convention
I'm not a big fan of Hungarian notation either. I'm not sure that having a naming convention for Iterators is Hungarian notation, however. For example, if you are doing Windows programming, you'll see stuff like: DWORD dwFoo = 0; In this case, the dw prefix on the variable indicates that we have a DWORD variable. However, the Iterator suffix that I'm proposing here is a suffix on the type names, not the actual variable names. So, if you are writing Rust code, you'd write something like this: let chunks = some_vector.chunks(50); So, the actual variable name doesn't have the Hungarian notation and the types aren't even generally visible since the compiler infers much of that. However, someone reading through the documentation and/or code will see a struct named ChunkIterator and instance know how the struct behaves - as an Iterator. So, I think the suffix serves less to describe the datatype and more to describe class of behavior that the struct implements. Anyway, as I said, I prefer #1. But, I also have done lots of Java programming so I'm probably much more used to verbosity than others. I'm not horribly against some sort of other naming convention, either, of course, but I would like to see some consistency. My main motivation for opening the request was because I created MutChunkIter and then realized that it was named differently than majority of other Iterators. I don't want to be responsible for someone reading through the docs and seeing something thats inconsistent for no good reason! Also, I was reading through some code and happened upon a Map and was exceptionally confused about it, until I realized it was iter::Map as opposed to container::Map. I figured I probably wasn't the only person that was going to be confused by something like this. -Palmer Cox On Sat, Dec 21, 2013 at 3:14 PM, Kevin Cantu m...@kevincantu.org wrote: IMHO Hungarian notation is for things the type system and tooling cannot deal with. I'm not sure this is one of them... Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Iterator naming convention
Are there examples of structs that implement Iterator that also implement other non-Iterator related traits? Although its possible to do that, I can't think of a use case for it off the top of my head. An Iterator basically represents the state of an ongoing computation and once that computation is completed, the object is mostly uselss. It seems like it would be awkward to implement other traits for such an object. Maybe I'm not thinking of something, however. -Palmer Cox On Sat, Dec 21, 2013 at 4:24 PM, Kevin Cantu m...@kevincantu.org wrote: Iterators are just structs which implement the Iterator or a related trait, right? These structs which do can also implement lots of other traits, too: no reason to make -Iter special. Kevin On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox palmer...@gmail.com wrote: I'm not a big fan of Hungarian notation either. I'm not sure that having a naming convention for Iterators is Hungarian notation, however. For example, if you are doing Windows programming, you'll see stuff like: DWORD dwFoo = 0; In this case, the dw prefix on the variable indicates that we have a DWORD variable. However, the Iterator suffix that I'm proposing here is a suffix on the type names, not the actual variable names. So, if you are writing Rust code, you'd write something like this: let chunks = some_vector.chunks(50); So, the actual variable name doesn't have the Hungarian notation and the types aren't even generally visible since the compiler infers much of that. However, someone reading through the documentation and/or code will see a struct named ChunkIterator and instance know how the struct behaves - as an Iterator. So, I think the suffix serves less to describe the datatype and more to describe class of behavior that the struct implements. Anyway, as I said, I prefer #1. But, I also have done lots of Java programming so I'm probably much more used to verbosity than others. I'm not horribly against some sort of other naming convention, either, of course, but I would like to see some consistency. My main motivation for opening the request was because I created MutChunkIter and then realized that it was named differently than majority of other Iterators. I don't want to be responsible for someone reading through the docs and seeing something thats inconsistent for no good reason! Also, I was reading through some code and happened upon a Map and was exceptionally confused about it, until I realized it was iter::Map as opposed to container::Map. I figured I probably wasn't the only person that was going to be confused by something like this. -Palmer Cox On Sat, Dec 21, 2013 at 3:14 PM, Kevin Cantu m...@kevincantu.org wrote: IMHO Hungarian notation is for things the type system and tooling cannot deal with. I'm not sure this is one of them... Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Iterator naming convention
I noticed recently that there seem to be 3 distinct Iterator naming conventions currently in use: 1. Use the Iterator suffix. Examples of this are SplitIterator and DoubleEndedIterator. 2. Use the Iter suffix. Examples of this are ChunkIter and ComponentIter. 3. Use no particular suffix. Examples of this are Invert and Union. Iterators are somewhat special objects, so, it makes sense to me that they have a suffix in common to denote their common behavior. It seems non-ideal, however, that there appear to be 3 separate conventions in use since that is just confusing. Personally, I think I prefer #1 because its far and away the most common and and because I think #2 and #3 have issues: #2 (Iter suffix): If we used this suffix, would we rename DoubleEndedIterator to DoubleEndedIter? That looks awkward since we abbreviated Iterator without abbreviating anything else. However, DblEndedIter is a monstrosity. So, this convention seems non-ideal to me. #3 (no suffix): I think its pretty confusing while reading through code that there are both iter::Map and container::Map since they are completely unrelated. I'm also not a big fan of Union since I think as a union as a collection of information that I can iterate multiple times. However, since Union is itself an Iterator, I can only iterate it once. This means I would have to be careful passing a Union around to make sure I don't pass around an already iterated Union object. So, I opened up https://github.com/mozilla/rust/pull/11001 to standardize on #1 - all Iterators have an Iterator suffix. Thoughts? -Palmer Cox ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
Why not use Result instead of Option for these types of things? Result is already defined to be able to return error codes using Err. The only way to indicate an error when returning an Option is to return None which doesn't allow for that. Also, IMO, None doesn't necessarily mean error to me. Lets say we have a function defined as: fn do_something(value: Option~str); It seems like it would be much to easy to accidentally write something like: do_something(str::from_utf8(...)) which might result in the error being hidden since do_something might not consider None to be an error input. -Palmer Cox On Fri, Dec 6, 2013 at 4:52 PM, Simon Sapin simon.sa...@exyr.org wrote: On 06/12/2013 21:50, Eric Reed wrote: Personally, I prefer making functions that don't fail and use Option or Result and then composing them with functions that fail for certain outputs, but I think I'm in the minority there. Yes, this is what I’m suggesting. -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
Especially if ResultT, () is optimized into a single word, it seems ideal to me to get rid of str::from_utf_opt([u8]) - Option~str and just have str::from_utf([u8]) - Result~str, (). This makes simple programs that don't care about error handling a little more complicated, of course, since it forces them to handle the error case. Although, the only extra complication is .unwrap() so, its not that bad. For more complex programs that do care about error handling it makes it explicit at the call site how the error condition should be handled which I think is a big win. Return code checking is a C idiom, and there is nothing wrong with that style of error handling. However, the C compiler doesn't do much of anything to force you to check the return codes which leads to lots of code that fails to do so. Using a Result, however, forces the caller to do those checks. Result still supports various chaining functions just like Option to make that easier. However, you don't have to worry about accidentally passing a None to a function that takes an Option as an input parameter with non-error semantics. Also, I like unwrap() since to me, nothing about get() says: this is an error handling function that might lead to killing the current task. get() sounds simple and safe, buts its not if called on an Option. -Palmer Cox On Fri, Dec 6, 2013 at 11:14 PM, Patrick Walton pcwal...@mozilla.comwrote: On 12/6/13 6:46 PM, Niko Matsakis wrote: I agree. I've personally been moving towards `ResultT, ()` in preference to `OptionT` when one of the branches reflects an error. It's worth noting that the compiler could still optimize this into a pointer-null-pointer representation, though I doubt it does so now. IIRC it does. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] List comprehensions / Do notation
Hi, Rust seems like a really excellent language. One feature that Rust doesn't seem to have is a built-in list-comprehension syntax. Wikipedia points out that macros can be used to simulate this feature, but the resulting syntax is a bit clunky. Are there plans to add such a syntax to the language? I'm also curious if there are plans to add a Haskell style do-notation syntax to the language? It seems that macros can also be used to simulate this, but the end result is even more clunky than using macros to simulate list-comprehensions. I would think that such a syntax might be very useful for working with the results from multiple tasks. Thanks, -Palmer Cox ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
