I noticed there are two ways of handling LPWSTR output types in the windows-rs crate; Both start with marshalling the string into a slice:
let len = (0..).take_while(|&i| *ptr.offset(i) != 0).count();
let slice = std::slice::from_raw_parts(ptr, len);
Then it seems we can do one of:
let output = OsString::from_wide(slice).to_string_lossy().into_owned()
or
let output = String::from_utf16_lossy(slice)
The first option I'm guessing is more correct, but in order to use it you have to bring std::os::windows::prelude::OsStringExt into scope. The problem for me right now is that prevents rust-analyzer from linting due to a bug: https://github.com/rust-analyzer/rust-analyzer/issues/6063
Using the later method sidesteps this to improve my development workflow. Is the later method likely cause me any problems?
Related
I am writing code in Go to call some of the Windows trust and crypt dlls to verify file signatures. There are many constants in wincrypt.h that I have tried to port over verbatim but i've hit some issues with integer overflow.
For example, all of the error codes that can be returned from WinVerifyTrust are negative values. If I take one example, TRUST_E_NOSIGNATURE, this is defined in winerror.h as so: #define TRUST_E_NOSIGNATURE _HRESULT_TYPEDEF_(0x800B0100L). In my Go code, I have const TRUST_E_NOSIGNATURE = int32(0x800B0100) but when compiled the error is:
constant 2148204800 overflows int32
when I really expected the value to be -2146762496
So, my questions 1) why does it not wrap like it does in other languages 2) Is there anyway to have the constant still use the hex representation of the number or will I have to change the code to const TRUST_E_NOSIGNATURE = int32(-2146762496) which works ok but will require me to make this change in many other constants that I have ported?
You just set it:
const TRUST_E_NOSIGNATURE = int32(-2146762496)
Use hex if you wish:
const TRUST_E_NOSIGNATURE = int32(-0x7ff4ff00)
But for this, you're probably just using the wrong data type. Use a uint32 instead:
const TRUST_E_NOSIGNATURE = uint32(0x800B0100)
why does it not wrap like it does in other languages?
Because it wasn't designed that way. Go follows the philosophy of being as obvious and intuitive as possible. Silent wrapping is very non-intuitive.
I am currently working on a high-performance Vector/Matrix Ruby gem C extension, as I find the built-in implementation cumbersome and not ideal for most cases that I have personally encountered, as well as lacking in other areas.
My first approach was implementing in Ruby as a subclass of Fiddle::CStructEntity, as a goal is to make them optimized for interop without need for conversion (such as passing to native OpenGL functions). Implementing in C offers a great benefit for the math, but I ran into a roadblock when trying to implement a minor function.
I wished to have a method return a Fiddle::Pointer to the struct (basically a pointer to Rdata->data. I wished to return an actual Fiddle::Pointer object. Returning an integer address, packed string, etc. is trivial, and using that could easily be extended in a Ruby method to convert to a Fiddle::Pointer like this:
def ptr
# Assume address is an integer address returned from C
Fiddle::Pointer.new(self.address, self.size)
end
This kind of opened up a question to me, and that is it possible to to even do such from C? Fiddle is not part of the core, library, it is part of the standard lib, and as such, is really just an extension itself.
The problem is trivial, and can be easily overcome with a couple lines of Ruby code as demonstrated above, but was more curious if returning a Fiddle object was even possible from a C extension without hacks? I was unable to find any examples of this being done, and as always when it comes to the documentation involving Fiddle, it is quite basic and does not explain much.
The solution for this is actually rather simple, though admittedly not as elegant or clean of a solution I was hoping to discover.
There are possibly more elaborate ways to go about this by including the headers for Fiddle, and building against it, but this was not really a viable solution, as I didn't want to restrict my C extension to only work with Ruby 2.0+, and would be perfectly acceptable to simply omit the method in the event Ruby version was less than 2.0.
First I include version.h, which gives access defines the macro RUBY_API_VERSION_MAJOR, which is all I really need to know in regards to whether or not Fiddle will be present or not.
This will be an abbreviated version to simply show how to get the Fiddle::Pointer class as a VALUE, and to create an instance.
#if RUBY_API_VERSION_MAJOR >= 2
rb_require("fiddle");
VALUE fiddle = rb_const_get(rb_cObject, rb_intern("Fiddle"));
rb_cFiddlePointer = rb_const_get(fiddle, rb_intern("Pointer"));
#endif
In this example, the class is stored in rb_cFiddlePointer, which can then be used to create and return a Fiddle::Pointer object from C.
// Get basic data about the struct
struct RData *rdata = RDATA(self);
VALUE *args = xmalloc(sizeof(VALUE) * 2);
// Set the platform pointer-size address (could just use size_t here...)
#if SIZEOF_INTPTR_T == 4
args[0] = LONG2NUM((long) rdata->data);
#elif SIZEOF_INTPTR_T == 8
args[0] = LL2NUM((long long) rdata->data);
#else
args[0] = INT2NUM(0);
#endif
// Get size of structure
args[1] = INT2NUM(SIZE_OF_YOUR_STRUCTURE);
VALUE ptr = rb_class_new_instance(2, args, rb_cFiddlePointer);
xfree(args);
return ptr;
After linking the function to an actual Ruby method, you can then call it to get a sized pointer to the internal structure in memory.
I'm trying to call a C function that expects a C string (char*) from go. I know about the C.CString function documented in the cgo documentation but as the function I'm calling will already make a copy, I'm trying to avoid the one Cstring makes.
Right now, I'm doing this, s being a go string
var cs *C.char = (*C.char)( unsafe.Pointer(& []byte(s) [0]))
But I get the feeling that the []bytes(s) is making its own copy. Is it possible to just get the char* ?
If you're doing this enough times that performance is a concern, it would really be advisable to keep the data in a slice to begin with.
If you really want to access to the address of the string, you can use the unsafe package to convert it into a struct matching the string header. Using the reflect.StringHeader type:
p := unsafe.Pointer((*(*reflect.StringHeader)(unsafe.Pointer(&s))).Data)
Or using a slice as a proxy, since they both put the data pointer and length integers in the same field locations
p := unsafe.Pointer(&(*(*[]byte)(unsafe.Pointer(&s)))[0])
Or because the data pointer is first, you could use a uintptr alone
p := unsafe.Pointer(*(*uintptr)(unsafe.Pointer(&s)))
https://play.golang.org/p/ps1Py7Ax6QK
None of these ways are guaranteed to work in all cases, or in future versions of Go, and none of the options are going to guarantee a null terminated string.
The best, supported option is to create a shim in the cgo preamble to accept the go string, and convert it to a *char. CGO provides access to the following function to do this:
const char *_GoStringPtr(_GoString_ s);
See the Go references to C section in the documentation.
I have defined the following:
std::atomic_int m_decoding_thread_count;
Can it be ensured that the following will be atomic? or can I ever have the result of load() to be different than the result of ++? i.e. can two threads ever get assigned the same thread_id?
int thread_id = (++m_decoding_thread_count).load();
Update
As rightfully pointed out in this response the code above does not compile (my bad). The alternatives I see are:
option 1:
++m_decoding_thread_count;
int thread_id = m_decoding_thread_count.load();
option 2:
int thread_id = m_decoding_thread_count.fetch_add(1)++;
I can see how option 1 is not atomic. Option 2, on the other hand, could be almost atomic except that, to my understanding of the documentation, fetch_add() will return the value before the add is made, therefore having to increment it a posteriori.
Am I missing anything?
The code doesn't make sense now, after the edit. operator++ is a shorthand for .fetch_add(1), but it returns a plain int. You can't call load on that, nor is there any point in doing so.
I am working on a Jitter which is based on LLVM. I have a real issue with performance. I was reading a lot about this and I know it is a problem in LLVM. However, I am wondering if there are other bottlenecks. Hence, I want to use in my Jitter the same mechanism offers by -time-passes, but saving the result to a specific file. In this way, I can do some simple math like:
real_execution_time = total_time - time_passes
I added the option to the command line, but it does not work:
// Disable branch fold for accurate line numbers.
llvm_argv[arrayIndex++] = "-disable-branch-fold";
llvm_argv[arrayIndex++] = "-stats";
llvm_argv[arrayIndex++] = "-time-passes";
llvm_argv[arrayIndex++] = "-info-output-file";
llvm_argv[arrayIndex++] = "pepe.txt";
cl::ParseCommandLineOptions(arrayIndex, const_cast<char**>(llvm_argv));
Any solution?
Ok, I found the solution. I am publishing the solution because It may be useful for someone else.
Before any exit(code) in your program you must include a call to
llvm::llvm_shutdown();
This call flush the information to the file.
My problem was:
1 - Other threads emitted exit without the mentioned call.
2 - There is a fancy struct llvm::llvm_shutdown_obj with a destructor which call to the mentioned method. I had declared a variable in the main function as follow:
llvm::llvm_shutdown_obj X();
Everybody know that the compiler should call the destructor, but in this case it was no happening. The reason is that the variable was not used, so the compiler removed it.
No variable => No destructor => No flush to the file