I'm having issues with Vala adding padding to struct values. Is there an equivalent to C's #pragma pack(1) or C#'s [StructLayout(LayoutKind.Sequential, Pack=1)], or possibly a workaround for this? Thanks in advance.
~ Michael K.
Not natively. You can define your packed structure in a separate C header file with the appropriate #pragma or __attribute__ and then create a VAPI binding for it.
It might be possible to abuse Vala's code generation to do it (e.g., set the [CCode(cname)]], but I would advise against it.
Related
I have program that uses std::string, but memmove the std::string` instances.
It worked fine until gcc 5.1.
However this no longer works as of gcc 5.3. I think developers finally did SSO with internal pointer.
I will definitely fix that, but is there easy way to fix it with some define or pragma?
Code looks similar to this:
// MyClass have std::string inside
MyClass *a = malloc(MAX * sizeof(MyClass));
// ...
// placement new on a[0]
// ...
memmove(&a[1], &a[0], sizeof(MyClass));
// ...
process(a[1]);
This is old code, please do not comment about malloc usage.
I will refactor or switch to std::vector, but I want the code to work until I do so.
You are experiencing effects of undefined behavior, but I think you know this. You cannot rely on the effects of byte-wise copying non-POD resp. not trivially copyable types, and the compiler is free to change that behavior.
I think it may be possible to define a safe overload for memmove with your class as arguments and use the copy-constructor inside it. I don't know if that is strictly legal, but you seem to be using the C-function instead of the C++ version in namespace std, so at least you are not changing namespace std which is not allowed.
void memmove(MyClass* a, MyClass* b, size_t)
{
*a = *b;
}
Strictly speaking, I think this is still undefined behavior because 17.6.4.3 of the C++ standard specifies that
If a program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by this Clause, its
behavior is undefined.
In addition, all names in C library are reserved names and shall not be used by the program (17.6.4.3.2). Practically, I think this will work.
You may need to compile with -fno-builtin to prevent gcc from replacing memmove globally. If it is illegal to overwrite the function, you can replace it dynamically with LD_PRELOAD.
This is a hack solution! Your code may still not work because the compiler makes the assumption that, when you memmove it is a POD/TriviallyCopyable object and uses that for some optimisation, e.g. by assuming that after the memmove, both objects are represented by identical bytes. This is broken when you re-implement memmove with the copy-constructor.
What is difference between dynamically creating kobject using kobject_create_and_add and kobject_init_and_add function?
kobject_create_and_add allocates a new kobject, while kobject_init_and_add initialize and the kobject passed to it.
struct uio_mem {
struct kobject kobj;
unsigned long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
};
I want to use uio_mem in my show and store function, can i Use kobject_create_and_add?
static ssize_t test_attr_show(struct kobject *kobj, struct kobj_attribute *attr,
Is it possible to get uio_mem from the kobj?
I know that this question is a bit old but anyway I wanted to answer it (it may be helpful for other people in the future).
First of all: kobjects are really well described (as a fundamental kernel structure) in ldd.3 (Ch14) as well as in documentation (https://lwn.net/Articles/54651/, http://lwn.net/Articles/51437/). Below I provide a shortcut based on these sources and my understanding. For more details please use these sources and kernel code.
Let's start from the end: why do we need kobjects?
They are kernel structures that provide way to implement inheritance for Linux drivers. Each driver related to sysfs should handle reference to kobject (you can think about it as a common ancestor).
The way how that is implemented: kobject needs to be embedded inside the driver structure (in your case struct uio_mem).
Code that works with kobjects often has the opposite problem: given a struct kobject pointer, what is the pointer to the containing structure?
In general programming tricks such as manipulation of object should be avoided and, instead use a container_of macro.
The way to convert a pointer to a struct kobject called kp embedded within a struct uio_struct would be:
// container_of(pointer, type, member)
struct cdev *uio_struct = container_of(kp, struct uio_struct, kobj);
Also with attributes by themself, you can find show/store function that didn't give you any kobject.
A good example that I have in mind is virtio driver:
see http://lxr.free-electrons.com/source/drivers/virtio/virtio.c?v=3.7
To answer your first question, we need to explain why we need kobject_create and kobject_init?
Main reason is that to run kobject_init you need to make sure that all fields are filled by zeros if that is not the case bad things can happen.
Function kobject_create doesn't have this issue: in implementation, it creates object using kzalloc and then adds it.
As I understand this function it is safer than init, but I don't see there a bigger difference between the two from a functional perspective.
Another thing to consider is dependencies between objects (if you have a different dependent kobject in your driver), then make sense to use first of all init and then create other objects see for example iommu_group_alloc (by using kobject_create_and_add you won't get any attributes by default but will be like parent/folder, init will create attributes by ktype)
I would like to utilize both RcppArmadillo and RcppGSL via sourceCpp. Basically I am interested in modifying the B-spline example
http://dirk.eddelbuettel.com/blog/2012/12/08/
so that the B-splines are functions of R^3 instead of only R^1. This entails working with 3-dimensional arrays which apparently is not supported in GSL (there is an extension here http://savannah.nongnu.org/projects/marray though). However, RcppArmadillo has the arma::cube type which I could use if only I could get RcppArmadillo and RcppGSL to "work together." This I am unfortunately not able to do. I have looked at
Multiple plugins in cxxfunction
but have not succeeded in creating the mentioned combined plugin. Any help is greatly appreciated!
Adam
Edit: It seems like it is actually possible to compile a .cpp file with sourceCpp containing the following sequence of commands at the top:
// [[Rcpp::depends(RcppGSL)]]
// [[Rcpp::depends(RcppArmadillo)]]
#include <RcppArmadillo.h>
#include <RcppGSL.h>
#include <gsl/gsl_bspline.h>
Furthermore, it also seems possible to store values like
double gsl_vector_get (const gsl_vector * v, size_t i)
in an arma::cube structure.
RcppArmadillo.h and RcppGSL.h are modelled similarly. They first include RcppCommon.h, then some forward declarations, then they include Rcpp.h that uses those forward declarations, then implementations.
It is definitely possible to use them both if you come up with the right order of includes.
This is definitely an Rcpp question as what is preventing you from using them both is (good or bad) design decisions.
You need to study RcppArmadillo.h and RcppGSL.h and come up with the right include order, or wait for someone to follow these hints and give you the answer. I might not have time to do it myself in the next few days.
Armadillo types and GSL types are not interchangeable.
You could rewrite the GSL algorithm for Armadillo, but it is not automatic but any means. I am also not sure if the theory behind splines extends just like that from the real line to three-dimensions.
If I have access to the C struct definition in the header files but want to define my storable instance manually without using something like hsc2hs, how do I find the alignment value?
Also could a wrong alignment value cause a crash or just affect performance?
Edit: Apologies, I misread the question and thought you were asking about doing this with hsc2hs, not without. Incorrect alignment can lead to incorrect data and cause crashes (consider if you're marshalling an array of structs), so you really should use something portable.
According to the FFI cookbook, you can define
#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
which is then used as
instance Storable Struct where
alignment _ = #{alignment my_struct}
sizeOf _ = #{size my_struct}
The alignment keyword should be available in ghc > 7.2.1, so you wouldn't need to define it yourself with very new ghc's.
With gcc, you can find the alignment per __alignof__ (type) more. The value is, however, architecture-dependent, so for portability, you should determine the alignment on each machine by a macro. Which means that hsc2hs is probably the better way.
I think the wrong alignment can lead to crashes, but I don't know for sure.
I just noticed this line in the getrusage man page:
Including <sys/time.h> is not required these days, but increases portability. (Indeed, struct timeval is defined in <sys/time.h>)
What? Since struct rusage contains struct timeval as a member, surely sys/resource.h must include sys/time.h or the type would be incomplete and unusable?
How could this comment ever have made sense? How could it ever have not been necessary? How could portability have ever been helped?
In general, it was not uncommon in the early days of C for you to have to manually include header file A before header file B. Maybe an early version of the preprocessor couldn't do nested includes, or maybe it was just stylistic (manpages would often directly include the header files for relevant structures).
"These days", sys/resource.h must either include sys/time.h or repeat the definition of struct timeval, but not every system follows the standard completely.
It's because the BSD's require it:
FreeBSD and OpenBSD need sys/time.h, not just time.h, before
sys/resource.h.
See this page on UNIX Portability for details.