I'm trying to remove a data source from a rrd db.
I found I can do something like
"rrdtool tune mydb.rrd DEL:source_name"
and it works, but I want to do it from C/C++ code.
I could use the system function in Linux, but I don't
like the overhead.
I looked in https://oss.oetiker.ch/rrdtool/doc/librrd.en.html
to see if there is something I could use, but I didn't find anything.
I also looked in the rrd source code from https://github.com/oetiker/rrdtool-1.x/tree/master/src
and I found they call rrd_modify_r2() to remove sources, but this function is static, so it's not exported (as opposed to rrdc_create_r2)
So, how can I remove a source from C/C++ code ?
thanks,
Catalin
You use of course rrdtool tune filename.rrd DEL:ds-name to do this from the commandline, as you note.
However the RRDTool C bindings in librrd are not as comprehensive, and do not appear to expose this functionality. Not sure why - the modify functions is clearly useful - but thats how it seems to be.
One option you have would be to simply call the external rrdtool binary with fork/exec, passing the appropriate commandline. This is not a particularly pretty way to do it, but is more portable and compatible with the published interface.
Related
Does anyone know of a vim plugin that allows to look up struct members/elements of structures in C or classes in case of C++?
I'm thinking something similar to jumping to a definition of a struct using cscope/ctags, but ideally I would want something similar to moving a cursor over the desired variable and a keystroke will pull up a table akin to when you use omni-complete?
I've been trying to find something but to no avail.
The requirement is: should be exclusively for vim.
99% of my development is sshing to a remote linux machine.
Normally my workflow is, git clone the project, setup ctags and cscope, open up the desired file and load up my cscope db and that's where I stay for the majority of the day, moving around the directory I have the nerd-tree plugin.
So far I use a combination of ctags/cscope, and calltree plugins to look up function callees.
I'm missing a plugin that allows me to simply look up struct elements.
I don't really use omnicompletion because it is notoriously slow and I've given up to make it faster.
Any ideas?
With universal-ctags, given you've used the right options, you can always obtain the members of a class/struct type.
If you read in between the lines, this means there is no efficient way to do it on a C++ variable if you stick to vimscript. I've tried do it, but I've given up on this path eventually ; path that has no way to support auto.
Now, I've started using (/implementing) another approach to analyse C++ code and exploit the information from vim: I rely on libclang. The catch is that it needs to operate on the current translation unit (TU), and if the TU is long (e.g if it includes many long files), it's takes time to parse it for the first time since the last time it has changed (I expect the solution to change with C++20 modules) -- the analysing is done on demand, and not in the background. Note: my plugin is currently under development and I haven't yet provided an high level Vim function that returns the type of a variable and its associated information (type, members, possible enum values...)
If your ultimate objective is completion of members, clang based tools provide a dedicated API for this purpose that'll be more efficient than completely analysing the current TU. The plugins you don't wish to use exploit this API. LSP servers even try to cache as much information as possible (for navigation and completion purpose only).
Note that there exist a few plugins, like tagbar, that tries to organize information extracted with ctags and present it in a hierarchic view. Note that it won't help with disambiguation nor with auto.
I've just seen this library ByteNode it's the same as ByteCode of java but this is for NodeJS.
This library compiles your JavaScript code into V8 bytecode, which protect your source code, I'm wondering is there anyway to Decompile byteNode therefore it's not secure enough. I'm wondering because I would like to protect my source code using this library?
TL;DR It'll raise the bar to someone copying the code and trying to pass it off as their own. It won't prevent a dedicated person from doing so. But the primary way to protect your work isn't technical, it's legal.
This library compiles your JavaScript code into V8 bytecode, which protect your source code...
Well, we don't know it's V8 bytecode, but it's "compiled" in some sense. All we know is that it creates a "code cache" via the built-in vm.Script.prototype.createCachedData API, which is officially just a cache used to speed up recompiling the code a second time, third time, etc. In theory, you're supposed to also provide the original source code as a string to the vm.Script constructor. But if you go digging into Node.js's vm.Script and V8 far enough it seems to be the actual code in some compiled form (whether actual V8 bytecode or not), and the code string you give it when running is ignored. (The ByteNode library provides a dummy string when running the code from the code cache, so clearly the actual code isn't [always?] needed.)
I'm wondering is there anyway to Decompile byteNode therefore it's not secure enough.
Naturally, otherwise it would be useless because Node.js wouldn't be able to run it. I didn't find a tool to do it that already exists, but since V8 is open source, it would presumably be possible to find the necessary information to write a decompiler for it that outputs valid JavaScript source code which someone could then try to understand.
Experimenting with it, local variable names appear to be lost, although function names don't. Comments appear to get lost (this may not be as obvious as it seems, given that Function.prototype.toString is required to either return the original source text or a synthetic version [details]).
So if you run the code through a minifier (particularly one that renames functions), then run it through ByteNode (or just do it with vm.Script yourself, ByteNode is a fairly thin wrapper), it will be feasible for someone to decompile it into something resembling source code, but that source code will be very hard to understand. This is very similar to shipping Java class files, which can be decompiled (there's even a standard tool to do it in the JDK, javap), except that the format Java class files are well-documented and don't change from one dot release to the next (though they can change from one major release to another; new releases always support the older format, though), whereas the format of this data is not documented (though it's an open source project) and is subject to change from one dot release to the next.
Certain changes, such as changing the copyright message, are probably fairly easy to make to said source code. More meaningful changes will be harder.
Note that the code cache appears to have a checksum or other similar integrity mechanism, since directly editing the .jsc file to swap one letter for another in a literal string makes the code cache fail to load. So someone tampering with it (for instance, to change a copyright notice) would either need to go the decompilation/recompilation route, or dive into the V8 source to find out how to correct the integrity check.
Fundamentally, the way to protect your work is to ensure that you've put all the relevant notices in the relevant places such that the fact copying it is a violation of copyright is clear, then pursue your legal recourse should you find out about someone passing it off as their own.
is there any way
You could get a hundred answers here saying "I don't know a way", but that still won't guarantee that there isn't one.
not secure enough
Secure enough for what? What's your deployment scenario? What kind of scenario/attack are you trying to defend against?
FWIW, I don't know of an existing tool that "decompiles" V8 bytecode (i.e. produces JavaScript source code with the same behavior). That said, considering that the bytecode is a fairly straightforward translation of the source code, I'm sure it wouldn't be very hard to write such a tool, if someone had a reason to spend some time on it. After all, V8's JS-to-bytecode compiler is open source, so one would only have to look at those sources and implement the reverse direction. So I would assume that shipping as bytecode provides about as much "protection" as shipping as uglified JavaScript, i.e. none that I would trust.
Before you make any decisions, please also keep in mind that bytecode is considered an internal implementation detail of V8; in particular it is not versioned and can change at any time, so it has to be created by exactly the same V8 version that consumes it. If you want to update your Node.js you'll have to recreate all the bytecode, and there is no checking or warning in place that will point out when you forgot to do that.
Node.js source already contains code for decompiling binary bytecode.
You can get a text string from your V8 bytecode and then you would need to analyze it.
But text string would be very long and miss some important information such as a constant pool. So you need to modify the Node.js source.
Please check https://github.com/3DGISKing/pkg10.17.0
I have attached exported xml file.
If you study V8, it would be possible to analyze it and get source code from it.
It keeping it short and sweet, You can try Ghidra node.js package which is based on Ghidra reverse engineering framework which was open-sourced by NSA in the year 2019. Ghidra is capable of disassembling and decompiling the v8 bytecode. The inner working of disassembling is quite complex, this answer is short but sufficient.
I have a directory with multiple source files of indeterminate name. The only thing I know is the file extension. I want to take each source file, and build a single target from each. The method I'm currently using is to determine the name of each source using a for loop:
targets = []
for file in listdir('.'):
if file.endswith('.xdm'):
targets += env.m4(source=file)
The advantage of doing it progrmatically like this is that the SConscript doesn't have to be maintained by the developers as they add new sources. The problem is that the targets are no longer cleaned because of something to do with dependencies that I don't entirely understand.
So my question is is there a more appropriate way to do this, using in-built SCons functionality, without relying on more traditional flow control, or should I just ensure that each of my sources is determined and list them individually in the SConscript?
Instead of fiddling with listdir I would simply use the Glob() method, as provided by SCons itself:
for file in Glob("*.xdm"):
env.m4(source=file)
This (like the example from your question) is a perfectly fine approach, since it uses the fact that SConscripts are actually Python scripts. The Glob() approach has the advantage of also finding *.xdm files that don't exist on the harddrive yet, but may get created as part of the build process later.
I wonder about the problems that you mentioned, regarding cleaning of the targets. The Q&A linked in your question above seems unrelated to me. If you experience actual "cleaning" problems with one of the approaches above, please post a separate question together with the full verbatim input and output. If it should turn out that this doesn't work out-of-the-box, I'd consider it to be a bug.
The question is pretty easy. I've download a version of the GSL on the official ftp (the last one to be more precise).
I can easily built the library and find the header file. But when I look for the implementation of gsl_fft_complex_forward for example using grep, I can only find the documentation, the header file and an use of it in an example.
So where can I find the .c that contain the function implementation?
This might help you in the right direction...
Inside fft folder, look in c_main.c
It includes c_pass.h and defines int FUNCTION(gsl_fft_complex,forward) which might just be what you are looking for.
This function basically passes its arguments plus one additional argument sign to another function defined later on in the same file int FUNCTION(gsl_fft_complex,transform) which in turn does some other stuff and then calls FUNCTION(fft_complex,pass_[2,3,4,5,6,7,n]) which are defined in their own files c_pass_[2,3,4,5,6,7,n]
I'm know very little about the Fast Fourier Transform to help you analyse the code any further though...
Also this way of defining and calling functions seems very unusual to me, but I'm not very experienced in c++
I have a driver that raises some warnings/errors during compilation, since the proc_fs api changed since its creation. The driver still uses create_proc_entry while the latest api version I am aware off, offers proc_create. Since I am new to driver programming under linux I tried to look at the source, however my ctags skills must be lacking since I only found proc_create in proc_fs.h. However, I would like to look at the implementation or some documentation, to know what error codes it returns so I know what I have to handle.
Can you point me to documentation for the proc api, or the source holding the definition of proc_create? A hint how it can be found would be appreciated as well.
create_proc is defined as an inline function, so it is fully implemented in the header proc_fs.h. It basically calls proc_create_data with a NULL for the data argument.
There seems very little documentation on these functions in the source so I'd recommend looking at other call sites within the kernel source, which you cam see listed in this LXR search.
BTW, creating new files in /proc seems frowned upon these days - it seems sysfs is where new interfaces should be created.
Best documentation for an API would be existing code itself. Check a few c files in fs/proc or grep for proc_create in the source code