How to read the type of a property in IORegistry from IOKit? - macos

For example, in the following example from IOKit documentation, each entry for this device has different types, such as Data, Number, etc
How can I use IOKit to read the type of it? I know that we can use IORegistryEntryCreateCFProperties to create a dictionary for an entry and read the property as void pointer and cast it to the type we know it is, but how can I know its type without taking a look using IORegistry Explorer?

Note that you can use a similar function, IORegistryEntryCreateCFProperty to query only one property, which is usually more useful unless you're actually trying to build something similar to IORegistryExplorer itself and don't yet know the names of the properties you want to inspect.
In both cases, this really boils down to a Core Foundation question. You'll notice that rather than a truly opaque void*, IORegistryEntryCreateCFProperty() actually returns a CFTypeRef, and likewise, IORegistryEntryCreateCFProperties() promises to only return CoreFoundation-type objects in its dictionary. This means you can query the object's type using CFGetTypeID(). The exact value of this is meaningless, but it can be compared to the type IDs for the expected set of types, e.g. CFStringGetTypeID() for CFString, CFDataGetTypeID() for CFData and so on.
If you're using Objective-C, you can also perform a bridging cast and treat the property values as NSObject - and then find out the specific type using e.g. [object isKindOfClass:[NSString class]].

Related

Ruby Fiddle: Nested union of structs within a struct

I have seen this question asked a few times on this site, and others, and have yet to see a legitimate and actual answer aside from posting links to the Ruby docs that don't answer the question either.
Is it possible, and if so how, to have a union of structs within another struct using Ruby Fiddle? Everything within the documentation simply indicates how to create structs/unions using primitive types, but not how it would be possible to nest them, as is a common convention to do.
The Fiddle::CParser cannot parse anything other than primitive types, as well as manual creation using signatures.
I have attempted to simply use TYPE_VOIDP and use that pointer to as a location to the address create the struct, which I was fairly sure should work, but I get only junk, as if the address is incorrect. I imagine this is because not enough memory is allocated, but I since the structs within the union are different sizes, I cannot allocate it ahead of time, leading me in circles.
The basic format is something like this: (this is psuedo-code just to give idea)
struct1 = [float, float, float, int]
struct2 = [int, int]
struct3 = [float, enum, enum, float, double, float]
structMaster = [
int, // Determines the type of the within the union
char[16],
char[16],
union[struct1, struct2, struct3]
]
I have looked extensively over all the Fiddle documentation, and it never indicates if this is even possible. I am familiar with Fiddle::CStructBuilder and related classes, and posting links to it is not the answer, as I have seen in other posts asking a similar question.
I have successfully done it accomplished this with old Win32API and using binary blobs, but am now trying to accomplish this with Fiddle, and am getting myself very frustrated.
EDIT:
I did manage to find some success by calculating the offset and reading the memory directly, and casting the pointer to the proper type, but I would still love to know if there is a way to do this cleaner with a nested struct, instead of the "hackish" way I am accomplishing it.

Finding functions that return a specific type

Perhaps this is a silly question, but is there a way to find all functions (in the standard library or GOPATH) that return a specific type?
For example there are many functions that take io.Writer as an argument. Now I want to know how to create an io.Writer and there are many ways to do so. But how can I find all the ways easily without guessing at packages and looking through all the methods to find those that return an io.Writer (or whatever other type I'm after)?
Edit: I should extend my question to also find types that implement a specific interface. Sticking with the io.Writer example (which admittedly was a bad example for the original question) it would be good to have a way to find any types that implement the Writer interface, since those types would be valid arguments for a function that takes takes an io.Writer and thus answer the original question when the type is an interface.
Maybe not the best way but take a look at the search field at the top of the official golang.org website. If you search for "Writer":
http://golang.org/search?q=Writer
You get many results, grouped by categories like
Types
Package-level declarations
Local declarations and uses
and Textual occurrences
Also note that io.Writer is an interface, and we all know how Go handles interfaces: when implementing an interface, there is no declaration of intent, a type implicitly implements an interface if the methods defined by the interface are declared. This means that you won't be able to find many examples where an io.Writer is created and returned because a type might be named entirely different and still be an io.Writer.
Things get a little easier if you look for a non-interface type for example bytes.Buffer.
Also in the documentation of the declaring package of the type the Index section groups functions and methods of the package by type so you will find functions and methods of the same package that return the type you're looking for right under its entry/link in the Index section.
Also note that you can check the dependencies of packages at godoc.org. For example you can see what packages import the io package which may be a good starting point to look for further examples (this would be exhausting in case of package io because it is so general that at the moment 23410 packages import it).
In my days coding I'm personally rare in need to find functions returning Int16 and error(func can return few values in Go, you know)
For second part of your question there exists wonderful cmd implements written by Dominik Honnef go get honnef.co/go/implements
After discover type that satisfy your conditions you can assume constructor for type (something like func NewTheType() TheType) would be just after TheType declaration in source code and docs. It's a proven Go practice.

ToLookup vs. ReadOnlyCollection

I've been using LINQ-to-objects for quite a while, but I just now noticed the Enumerable.ToLookup extension method and read its documentation. I came across it while looking for the quickest way to get a read-only interface to an IEnumerable<T>. It seems to me that appending .ToLookup( o => o ) onto the enumerable results in a System.Linq.Lookup object that can serve the same purpose as a ReadOnlyCollection<T>.
So why would I ever create a direct instance of ReadOnlyCollection<T> again?
A lookup is not, conceptually, the same as a read-only enumerable. It's more like a dictionary where each key has multiple values, and is used to look up matching values by key. Calling ToLookup enumerates the input fully and builds the lookup.
A ReadOnlyCollection<T> would be far less expensive as it merely wraps any IList<T>, as well as matching the semantic meaning of a read only interface to an IEnumerable<T>.

How to design for a future additional enum value in protocol buffers?

One of the attractive features of protocol buffers is that it allows you extend the message definitions without breaking code that uses the older definition. In the case of an enum according to the documentation:
a field with an enum type can only have one of a specified set of constants as its value (if you try to provide a different value, the parser will treat it like an unknown field)
therefore if you extend the enum and use the new value then a field with that type in old code will be undefined or have its default value, if there is one.
What is a good strategy to deal with this, knowing that in future the enum may have additional values added?
One way that comes to mind is to define an "undefined" member of the enum and make that the default, then old code will know it has been sent something that it can't interpret. Is that sensible, are there better ways to deal with this situation?
Yes, the best approach is to make the first value in the enum something like UNKNOWN = 0. Then old programs reading a protobuf with an enum value they don't recognize will see it as UNKNOWN and hopefully they can handle that reasonably, eg by skipping that element.
If you want to do this you'll also want to make the enum be optional not required.
required, generally, means "I'd rather the program just abort than handle something it doesn't understand."
Note that it must be the first value declared in the proto source - just being the zero value doesn't make it the default.
At least in the java implementation of proto3, it creates a default value. The value will start with "UNKNOWN_ENUM_VALUE_"
Code references:
https://github.com/protocolbuffers/protobuf/blob/0707f2e7f556c8396d6027d0533ec3a56d1061db/java/core/src/main/java/com/google/protobuf/Descriptors.java#L640-L642
https://github.com/protocolbuffers/protobuf/blob/0707f2e7f556c8396d6027d0533ec3a56d1061db/java/core/src/main/java/com/google/protobuf/GeneratedMessageV3.java#L2750-L2751
https://github.com/protocolbuffers/protobuf/blob/0707f2e7f556c8396d6027d0533ec3a56d1061db/java/core/src/main/java/com/google/protobuf/Descriptors.java#L1832
https://github.com/protocolbuffers/protobuf/blob/0707f2e7f556c8396d6027d0533ec3a56d1061db/java/core/src/main/java/com/google/protobuf/Descriptors.java#L2034-L2045

Getting a reflect.Type from a name

If I have a name of a type (i.e "container/vector"), is there a way to lookup the reflect.Type that has the given name? I'm trying to write a simple database-backed workqueue system and this it would be very difficult without this feature.
I can't see how this would be possible in any trivial way (or at all), since name resolution is part of the compiler/linker, not the runtime.
However, http://github.com/nsf/gocode might offer up some ideas. Though I'm pretty sure that works by processing the .a files in $GOROOT, so I still don't see how you'd get the reflect.Type. Maybe if the exp/eval package was more mature?
Of course if you know all the possible types you'll encounter, you could always make a map of the reflect.Type. But I'm assuming you're working with unpredictable input, or you would've thought of that.
Only way to create a reflect.Type is by having a concrete value of the intended type first. You can't even create composite-types, such as a slice ([]T), from a base type (T).
The only way to go from a string to a reflect.Type is by entering the mapping yourself.
mapping := map[string]reflect.Type {
"string": reflect.Typeof(""),
"container/vector": reflect.Typeof(new(vector.Vector)),
/* ... */
}

Resources