These are chat archives for rust-lang/rust

29th
Jun 2018
Kelly Thomas Kline
@kellytk
Jun 29 2018 02:37
I don't know the name of the feature which is making it difficult to find docs on it, where can I learn more about #[deny(unsafe_code)]?
Kelly Thomas Kline
@kellytk
Jun 29 2018 04:11
Thanks @ozkriff. What's the name for the #[x] feature?
Andrey Lesnikov
@ozkriff
Jun 29 2018 04:17
deny/allow/warn - is a part of lint check syntax itself (https://doc.rust-lang.org/reference/attributes.html#lint-check-attributes)
and all the standard lints are documented here - https://doc.rust-lang.org/rustc/lints/index.html - with their exact names. they are written with - if used as cli flags, and with _ in code
tsoernes
@tsoernes
Jun 29 2018 07:16
how do you efficiently sum a ndarray of bools?
James Sewell
@jamessewell
Jun 29 2018 07:25
If I have lots of different threads receiving file chunks and I want to assemble them in memory what would be the best file structure to use?
sorry not file structure,
I don't suppose there are any types which implement an array multiple threads can add to?
Fredrik Portström
@portstrom
Jun 29 2018 07:26
@tsoernes I guess you use iter and fold like you would do with any array.
@jamessewell Have a look at this: https://crates.io/crates/aovec
trsh
@trsh
Jun 29 2018 07:29
anybody good exp with vcpkg?
trsh
@trsh
Jun 29 2018 07:56
@tanriol the problem is that vcpkg adds to rust compile and somehave doesn't effect the cc built. It's still C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64\\cl.exe" "/nologo" "/MT" "/Z7" "/W4" "/DWITH_OPENSSL" "/FoC:\\janis_work\\manu\\backEnd2\\target\\debug\\build\\manu-33dbc0061b1a9e7b\\out\\src/applications/api/externapis/fedex/wsdls/addressvalidation\\wrapper.o" "/c" "src/applications/api/externapis/fedex/wsdls/addressvalidation/wrapper.c
Looks like dead end
Sylwester Rąpała
@xoac
Jun 29 2018 09:48
@tanriol Sorry I slept. I have #![cfg_attr(feature = "nightly", feature(bufreader_buffer))] at the begin of lib.rs and I would like to enable that future when I compile on nightly automatically and skip on stable
And better I would like to enable bufreader_buffer also on stable as soon as it will be stable without removing cfg if thats possible. I want to use https://doc.rust-lang.org/std/io/struct.BufReader.html#method.buffer when available
tsoernes
@tsoernes
Jun 29 2018 10:18
In the lambda |&y| y+2, is the pattern matching a trick to dereference y?
trsh
@trsh
Jun 29 2018 10:19
Hi! Again
Im trying to read some info returned from external C
let bb = output.AddressResults.wrapping_offset(x as isize);
            let cc = (*bb);
The line with cc = hangs and exits with error: process didn't exit successfully:C:\janis_work\manu\backEnd2\target\debug\manu.exe(exit code: 3221225477)
It works on Unix and not in Windows. Any ideas? Any known problems?
Zakarum
@omni-viral
Jun 29 2018 11:19
@xoac Unfortunately this seem impossible for now
There is no built-in "nightly" feature. You have to specify it manually when you build on nightly channel
Sylwester Rąpała
@xoac
Jun 29 2018 11:40
thanks
And there is no way for build section in Cargo.toml one for stable and one for nightly?
trsh
@trsh
Jun 29 2018 11:48
Rust + win is one million problems
Sylwester Rąpała
@xoac
Jun 29 2018 11:49
do you mean windows?
trsh
@trsh
Jun 29 2018 11:50
Yes
Dylan DPC
@Dylan-DPC
Jun 29 2018 11:51
@xoac what are you trying to do
Zakarum
@omni-viral
Jun 29 2018 12:05
@xoac maybe you can detect channel in build.rs
Is your crate a library or binary?
If former then you can rely on user to enable "nightly" feature for you
trsh
@trsh
Jun 29 2018 12:49
Reading extern C returned pointers is like playing Russian roulette on windows. One time it's ok, then it segmentation foult.
Zakarum
@omni-viral
Jun 29 2018 12:51
@trsh docs should explain possible usage of returned pointers
Checking for 0 is not enough
trsh
@trsh
Jun 29 2018 12:52
@omni-viral what are you talking about?
it just crashes when I do *some_pointer
Zakarum
@omni-viral
Jun 29 2018 12:53
You can't just *some_arbitrary_pointer
That's what I'm talking about :smile:
First you need to check if it's valid at the moment
Sylwester Rąpała
@xoac
Jun 29 2018 12:54
@omni-viral just learning purpose. If it's nightly I can turn on optimize function. I will specific nightly futures so manually
Zakarum
@omni-viral
Jun 29 2018 12:55
@xoac That's what everybody do
trsh
@trsh
Jun 29 2018 12:55
@omni-viral can you show me some example?
Document?
Zakarum
@omni-viral
Jun 29 2018 12:56
Refer to documentation of the extern C function that gives you the pointer
trsh
@trsh
Jun 29 2018 12:57
Nothing special about it
I can do any shit on C side
Zakarum
@omni-viral
Jun 29 2018 12:58
What do you mean?
trsh
@trsh
Jun 29 2018 12:58
I have no idea what u mean
Zakarum
@omni-viral
Jun 29 2018 12:59
I mean that when you call extern C functions you should carefully read documentation for that function.
And if you write C function you should carefully document it
trsh
@trsh
Jun 29 2018 13:00
@omni-viral so I did that. So when I run my wrapper directly in C everything is fine. And then I return it to rust, and there stuff goes to hell.
Zakarum
@omni-viral
Jun 29 2018 13:00
Can you show me a snippet? So we could talk more specifically
One time the ClientReferenceId is ok, another is one letter, then it's segm foult
And in C
Anything is fine
So the bridge some-have get's corrupted
value = "MultiUnitBase\u{1}"
name = "ZIP4Match"
value = "UniqueZIP<�\u{f}"
Faulty strings
trsh
@trsh
Jun 29 2018 13:08
Sometimes like this, sometimes Ok
Zakarum
@omni-viral
Jun 29 2018 13:11
So. If I understand correctly you get AddressValidationReply which contains pointer to array AddressResults and array length __sizeAddressResults. And with rust it segfaults on *output.AddressResults.offset(x as isize)
And both snippets got the AddressValidationReply from the same C function
The biggest difference I see is that rust code copies whole elements of AddressResults while C code reads only some fields
trsh
@trsh
Jun 29 2018 13:15
I removed these in C
soap_destroy(soap);
soap_end(soap);
soap_free(soap);
And it seems stable
It's kind of freeing resources
But if I leave them removed, I will run into memory problems?
Zakarum
@omni-viral
Jun 29 2018 13:21
You should place those calls so that there is no use-after-free
I guess C version also uses freed objects but doesn't segfaults by luck (memory is not returned to OS)
trsh
@trsh
Jun 29 2018 13:25
@omni-viral but how to I do that? I can't call stuff after return :D
Return object to rust and the back, and free them ..?
Zakarum
@omni-viral
Jun 29 2018 13:27
If you return a pointer after calling some destroy function on it you are your own evil buratino.
You have to return valid pointer and destroy them from caller side after usage
Zakarum
@omni-viral
Jun 29 2018 13:30
Expose extern C function to free objects ofc
trsh
@trsh
Jun 29 2018 13:31
@omni-viral but all of the context is gone, when C function returns the val
In C it self
Zakarum
@omni-viral
Jun 29 2018 13:32
What context? Could you return context as well?
trsh
@trsh
Jun 29 2018 13:32
If I free before return, it's same problem.. So it's kind of trickey
Zakarum
@omni-viral
Jun 29 2018 13:33
Or. Make rust code an owner of context
And add Context* argument to all functinos that need context
You know. In C you must think of ownership the same way as you do in Rust. You just can't express it in code
So I must return soap to rust to later free it
?
gh
Zakarum
@omni-viral
Jun 29 2018 13:37
You must expose soap_new function to rust. And take soap* as argument in other functions
And soap_destroy/free/end functions as well
trsh
@trsh
Jun 29 2018 13:38
Huge object.. Ok, tnx for your input.
Thinking now how to do it less painfull
Zakarum
@omni-viral
Jun 29 2018 13:39
Focus on making it less UB first :smile:
Ergonomics comes second
trsh
@trsh
Jun 29 2018 13:41
@omni-viral UB stands for?
Zakarum
@omni-viral
Jun 29 2018 13:41
Undefined behaviour
That's what you get when *invalid_pointer for example
As I mentioned before about documentation
soap_destroy(ctx); // clean up allocated class instances
soap_end(ctx); // clean up allocated temporaries
soap_free(ctx); // delete context
So it is pretty obvious that pointer that you return becomes invalid after those
trsh
@trsh
Jun 29 2018 13:48
@omni-viral jip. I wonder how it worked on Unix with all of this :D
Zakarum
@omni-viral
Jun 29 2018 13:49
By luck. Since it is undefined behaviour it can even work as expected.
And it is the worst outcome since bug remains hidden until you will receive an email from angry consumer
Also it can go and eat your laundry.
trsh
@trsh
Jun 29 2018 13:59
:D
trsh
@trsh
Jun 29 2018 14:21
which is not FFI-safe: this struct has no fields any chance yo supress those w?
Zakarum
@omni-viral
Jun 29 2018 14:22
Are you really want to?
Cause &[T] may have different layout for fieldless structs
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:28
Not only because of that
structs without fields in general have different representation in Rust and other langs
In particular, they will be zero-size in Rust, but non-zero-size in C/C++, so you can't just pass them between
Zakarum
@omni-viral
Jun 29 2018 14:31
Well, yeah. &() can be represented by whatever usize
Since rust will never try to read from it
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:32
&() is not valid for other reason - tuples are not FFI-safe on their own, no matter the number of fields
Zakarum
@omni-viral
Jun 29 2018 14:32
For one more reason then
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:32
so while #[repr(C)] struct MyStruct(u32, u32); is FFI-safe, (u32, u32) on its own is not
Zakarum
@omni-viral
Jun 29 2018 14:33
Cause it is not #[repr(C)]
But (u32,) should be safe though. Even if not guaranteed
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:34
Well kinda, tuple in general just isn't guaranteed to have same layout as struct
But yeah, thinking of it as non-repr-C-and-you-cant-make-it-such is enough for the matter of FFI
Zakarum
@omni-viral
Jun 29 2018 14:35
Even struct is not guaranteed to have some predefined layout if not #[repr(C)]
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:35

But (u32,) should be safe though. Even if not guaranteed

Define "safe". You can't really expect how it will look like in memory.

Zakarum
@omni-viral
Jun 29 2018 14:35
Unless there is only one field. Which doesn't guarantee to have predefined layout but will have the only one reasonable layout
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:36
Not necessarily, again, it's architecture-dependant and not something to rely upon
Zakarum
@omni-viral
Jun 29 2018 14:36
I wouldn't recomend to rely on that for sure :smile:
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:36
Struct with one field doesn't necessarily have same layout and data type as type of that field
Which was the whole motivation behind adding repr(transparent)
Zakarum
@omni-viral
Jun 29 2018 14:37
I just not sure that if you would rely on that it will ever break something
But to be sure you need some #[repr]
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:38
It surely can, and it did for me in the past (that was in particular for #[repr(C)] struct S(u32); vs u32 or something like that
For tuples you have even less guarantees, so no, under any circumstances you can't rely on which way it's going to be represented
Zakarum
@omni-viral
Jun 29 2018 14:38
But how? Did S had have different size than u32?
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:39
It can due to alignment
But also it changes other properties, in my case it was how it was returned from and passed to functions
On some architectures C structs, no matter the size, are passed as pointers, while primitives are passed as-is, so you get FFI incompatibility
Zakarum
@omni-viral
Jun 29 2018 14:40
That's another side of the ABI compatibility.
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:40
That's all the same, about FFI safety
Zakarum
@omni-viral
Jun 29 2018 14:41
True
trsh
@trsh
Jun 29 2018 14:52
"Are you really want to?" -> Yes :D
Just want to pass an object, that I dont care about
Touching in any other way
Btw its working, but the warning is getting on nerves
Ingvar Stepanyan
@RReverser
Jun 29 2018 14:54
Again, it's UB. You shouldn't rely on it, instead just fix the type.
How are you passing it? As a pointer?
trsh
@trsh
Jun 29 2018 15:00
@RReverser yes. And it's huge object. I dont really want to add all its methods and fields, etc.
Ingvar Stepanyan
@RReverser
Jun 29 2018 15:02
If it's a huge object then why doesn't it have any properties?
Zakarum
@omni-viral
Jun 29 2018 15:02
If you see it as opaque object then use #[repr(transparent)] Type(c_void)
Ingvar Stepanyan
@RReverser
Jun 29 2018 15:02
If you just want to pass an opaque pointer, use *const libc::c_void or *mut libc::c_void
Which already points to non-zero-size opaque object, and so won't have ABI issues
trsh
@trsh
Jun 29 2018 15:04
Okay, tnx Guys
Ingvar Stepanyan
@RReverser
Jun 29 2018 15:04
You can see how it's implemented to work around these issues here if you're interested: https://doc.rust-lang.org/1.8.0/src/libc/up/src/liblibc/src/lib.rs.html#93-103
But anyway, this is the direct equivalent of void* in C which sounds like what you want
tsoernes
@tsoernes
Jun 29 2018 15:56
Say I have a big struct type. Is there a way to initialize it, using default (as by trait, i.e. 0 for ints etc) values for all but 1 type?
Ingvar Stepanyan
@RReverser
Jun 29 2018 15:57
Do you mean to provide custom Default implementation or just do that in own method?
If the latter, then it's pretty easy:
MyStruct {
  x: 42,
  ..Default::default() // will fill all the other fields from the Default implementation
}
tsoernes
@tsoernes
Jun 29 2018 15:58
Whether to use fn new or custom default is the same for me, but it has to be such that an instance can be created with 1 custom default value, the rest inherited defaults
Ingvar Stepanyan
@RReverser
Jun 29 2018 15:59
Then this should work for you
tsoernes
@tsoernes
Jun 29 2018 15:59
oh yes, you can return the above fn new right?
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:00
Sure
Something like
fn new(custom_field: u32) -> Self {
  MyStruct {
    custom_field,
    ..Default::default()
  }
}
tsoernes
@tsoernes
Jun 29 2018 16:08

@RReverser It's a bit awkward. Consider:

extern crate time;
use time::{now, Tm};
#[derive(Default)]
struct Stats {
    time: Tm, 
    a0: i32,
    a1: i32,
    ..
    an: i32,
}

Can't do:

impl Default for Tm {
    fn default() -> Tm {
        now()
    }
}

because cannot define traits for extern crates.
Can't do:

impl Stats {
    pub fn new() -> Self {
        Stats {
            time: now(),
            ..Default::default()
        }
    }
}

Because deriving default doesn't work with a Tm field.
Any way to do it w/o creating a wrapper for Tm?

(the ans are just placeholders for the sake of illustration; the point being that I don't want to write out their defaults by hand)
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:16
@tsoernes Oh yeah, this isn't fun when external crate is involved
You have two options: 1) create a newtype around Tm that just implements Default or 2) write a macro or something to expand each field to field: Default::default(),
I think there were also some crates that allow overriding particular traits on per-field basis, but you need to search
From a quick search, this seems like an option: https://crates.io/crates/smart-default
But as I love writing macros, I would probably do just that :)
tsoernes
@tsoernes
Jun 29 2018 16:19
Okay. THanks
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:19
Alternatively, can't you separate struct and move all the fields that don't need time to a separate one?
Then you will be able to derive Default on that one and constructor of this wrapper struct will be much simpler
Without any hacks
tsoernes
@tsoernes
Jun 29 2018 16:24
there's only 1 time field so I think that approach is equivalent to creating a type wrapper around Tm. Anyhow I solved my problem (I think) by using precise_time_s() -> f64 from the same library instead, and just instantiating the time field in fn new
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:25
How did you work around not being able to derive Default though?
tsoernes
@tsoernes
Jun 29 2018 16:25
you can derive default, since it returns f64 and not Tm
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:25

there's only 1 time field so I think that approach is equivalent to creating a type wrapper around Tm

Yeah it is, but somewhat simpler to work with as you can probably move most private methods to that struct, and nicely separate.

Ah yeah, that works too
I don't think you need precise time though, I don't think Tm uses it
Unless you are indeed interested in performance measurements
tsoernes
@tsoernes
Jun 29 2018 16:27
It's performance measurements so I'm interested in delta time, however the time span is on the order of minutes so I don't think the precise part is important
anyhow precise_time returns a counter which has unknown t0, i.e. you don't know what wall clock time it corresponds to but it doesn't matter as I only need deltas
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:29
Yeah, but apart from that it might be slower than regular one on some systems
Again, it all depends whether you care
tsoernes
@tsoernes
Jun 29 2018 16:29
good to know
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:29
Are you using time crate?
tsoernes
@tsoernes
Jun 29 2018 16:31
yes
Ingvar Stepanyan
@RReverser
Jun 29 2018 16:31
Unless you're using it for maintenance reason, you might be better off switching to chronos, as time is deprecated and unsupported
Also chronos has a bit more flexibility in functions as to which precision you want: https://docs.rs/chrono/0.4.4/chrono/struct.DateTime.html#method.timestamp
Syed Faraaz Ahmad
@faraazahmad
Jun 29 2018 18:15
Is there an implementation of wget command in Rust?
Ingvar Stepanyan
@RReverser
Jun 29 2018 18:17
Hmm why?
Dylan DPC
@Dylan-DPC
Jun 29 2018 18:18
there is this. It is not a library though
but you can see how easy it is by using the hyper crate :smile:
hey, can someone give me some hints what the next steps would be in the deprecation of std::env::home:dir?
tsoernes
@tsoernes
Jun 29 2018 21:56
How to capture ctrl-c key event from terminal without blocking? Need a command to check if the key combination has been pressed in order to gracefully exit
tsoernes
@tsoernes
Jun 29 2018 22:30
ill give that a go, thanks
Sylwester Rąpała
@xoac
Jun 29 2018 22:32
if u are familiar with tokio you can check https://docs.rs/tokio-signal/0.2.1/tokio_signal/