I was looking through the source code of the PHP interpreter and found this piece of code :
Why is there a static char * variable defined but not used? I'm sure there has to be a reason for that, but with the data I have, I don't get it :-/
https://github.com/php/php-src/blob/master/main/strlcat.c
It seems to be the case on a lot of C files, here is another:
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/libkern/rindex.c?txt
From wikipedia (Source Code Control System)
SCCS is also known for the sccsid string, for example:
static char sccsid[] = "#(#)ls.c 8.1 (Berkeley) 6/11/93";
This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "#(#)" and can be used determine which source code files were used during compilation.
Note that RCS evolved from SCCS.
Related
See https://opensource.apple.com/source/file_cmds/file_cmds-82/touch/touch.c Line36:
__RCSID("$FreeBSD: src/usr.bin/touch/touch.c,v 1.20 2002/09/04 23:29:07 dwmalone Exp $");
What does this line mean? What is __RCSID and what is the meaning of the string? Is this some standard message for version control?
In cdefs.h I found
#ifndef __RCSID
#define __RCSID(s) __IDSTRING(rcsid,s)
#endif
and
#define __IDSTRING(name, string) static const char name[] __used = string
But I still don't know what they are for.
This comes from the Revision Control System, one of the earliest version control systems, and later adopted by some other version control systems. If a file contains a string of the form $keyword:...$, the .. portion is replaced automatically by information about the version of the file when the file is checked in and out.
This is typically put into a static variable so that you can then search the resulting object file for the string, to find out what version of the source code was used to generate it. See the ident command for how this is used.
I checked some of my Linux systems and they don't have ident, but you can simply use strings:
strings /usr/bin/touch | grep FreeBSD:
I've googled this for a bit but I don't seem to get anything resembling what I’m asking.
I'm creating a very simple C script which creates a bunch of template files (none of them are code or libraries or anything, they're just txt files), depending on an argument passed through the console, the way I was gonna resolve this is to just use fopen and fwrite, basically assembling the files line by line, replacing only the ones I need, but I figure there must be a way to bundle some files into the code so I can open and replace just what needs to change from case to case.
I imagine i could also create a couple of const char *file_text and that would do the trick, but I'd like to know if what I'm asking is possible should the need to use something harder to work with than text arise.
Problem is I can't seem to find how, to be clear, I want to do something like this on the console:
./Gen.sh ProjectName
And have Gen.sh be a self-contained file, with no need to keep the original templates around on the same folder.
You can use the linker to do such embedding
$ ld -r -b binary cat.png -o cat.o
The object file will have three symbols in it,
$ nm cat.o
_cat_start
_cat_end
_cat_size
To use them from C, declare some extern variables
extern const char cat_start;
extern const char cat_end;
extern const int cat_size;
Then you can link the generated object file ,the same can be used for text files
I'm testing some GTK+ examples.
At some given function, a reference to some path of a XML file appears in
C code. It explains that the code in C is reading the XML content to
later compile it to be usable from the C code:
static void
example_app_window_class_init (ExampleAppWindowClass *class)
{
gtk_widget_class_set_template_from_resource (GTK_WIDGET_CLASS (class),
"/org/gtk/exampleapp/window.ui");
}
I can understand what is happening here, but not how is it reading the source XML? window.ui, in this case. Because the repo has no folder
as they mention (/org/gtk/exampleapp/).
So, in my function I expect to do something like:
static void my_style_window_class_init(MyStyleWindowClass *class) {
gtk_widget_class_set_template_from_resource(GTK_WIDGET_CLASS(class),
"window.ui");
}
All my XML content is in the same folder as *.c and *.h files. This is a testing decision and have no other meaning.
The _from_resource() part of the function name indicates that the path /org/gtk/exampleapp/window.ui is not a filesystem path, but rather a resource path. Resource paths tie into a feature of GLib called GResource which allows you to embed binary data inside a program or shared library.
You would write an XML file to describe what local files map to what resource paths, and then as part of your build process, you would convert that to a C source file with the glib-compile-resources tool. You then build that C source file into your program. The full details are on the page that I linked in the first paragraph.
(Note that these are not the same as the embedded resources in Windows executables, which use a different technology altogether, but work in similar ways.)
If you want to load something from a file, GLib and GTK+ and other libraries built on them provide a _from_file(), _from_data(), or _from_stream() alternative to the _from_resource() function. _from_file() reads the data from a file directly. _from_data() reads from memory. _from_stream() reads from a GStream, which is an object-oriented I/O endpoint defined by GLib in its GIO module. The function name suffix is optional; it varies.
In the case of gtk_widget_class_set_template_from_resource(), the equivalent provided is gtk_widget_class_set_template(), which follows the _from_data() pattern of reading from memory. The memory is stored in a GBytes object, so you have to read from your local file into the GBytes.
It's an oldie and the question seems answered but I'd like to take a direct approach and place solution - turns out that we can substitute this line
gtk_widget_class_set_template_from_resource (widget_class,
"/org/gnome/gtksourceview/tests/ui/test-widget.ui");
with this line to make the code work.
if (g_file_get_contents("test-widget.ui", &contents, &len, &err) == FALSE)
g_error("error reading test-widget.ui: %s", err->message);
bytes = g_bytes_new_take(contents, len);
gtk_widget_class_set_template(GTK_WIDGET_CLASS(klass), bytes);
IN LINUX:
Not sure if it is possible. I have 100 source file, and 100 respective executable files.
Now, given the executable file, is it possible to determine, respective source file.
I guess you can give this a try.
readelf -s a.out | grep FILE
I think you can add some grep and sed magic to the above command and get the source file name.
No, since your assumption, that a single binary comes from exactly one source file, is very false.
Most real applications consist of hundreds, if not thousands, of individual source files that are all compiled separately, with the results liked together to form the binary.
If you have non-stripped binaries, or (even better) binaries compiled with debugging information present, then there might (or will, for the case of debugging info) be information left in the file to allow you to figure out the names of the source files, but in general you won't have such binaries unless you build them yourself.
If source filenames are present in an executable, you can find them with:
strings executable | grep '\.c'
But filenames may or may not be present in the executable and they may or may not represent the source filenames.
Change .c to whatever extension you assume the program has been written in.
Your question only makes sense if we presume that it is a given fact that every single one of these 100 executables comes from a single source file, and that you have all those source files and are capable of compiling them all.
What you can do is to declare within each source file a string that looks like "HERE!HERE!>>>" + __FILE__ and then write a utility which searches for "HERE!HERE!>>>" inside the executable and parses the string which follows it. __FILE__ is a preprocessor directive which expands to the full pathname of the source file being compiled.
This kind of help falls in the 'close the barn door after the horse has run away' kind of thing, but it might help future posters.
This is an old problem. UNIX and Linux support the what command which was invented by Mark Rochkind (if I remember correctly), for his version of SCCS. Handles exactly this type of problem. It is only 100% reliable for one source file -> one exectuable (or object file ) kind of thing. There are other more important uses.
char unique_id[] = "#(#)identification information";
The #(#) is called a "what string" and does not occur as a by-product of compiling source into an executable image. Use what from the command line. Inside code use maybe something like this (assumes you get only one file name as an answer, therefore choose your what strings carefully):
char *foo(char *whoami, size_t len_whoami)
{
char tmp[80]={0x0};
FILE *cmd;
sprintf(tmp, "/usr/bin/grep -F -l '%s' /path/to/*.c", unique_id);
cmd=popen(tmp, "r");
fgets(whoami, len_whoami, cmd);
pclose(cmd);
return whoami;
}
will return the source code file name with the same what string from which your executable was built. In other words, exactly what you asked, except I'm sure you never heard of what strings, so they do not exist in your current code base.
I'd like to hack on an existing GLib based C project using Vala.
Basically what I'm doing is, at the beginning of my build process, using valac to generate .c and .h files from my .vala files and then just compiling the generated files the way I would any .c or .h file.
This is probably not the best way, but seems to be working alright for the most part.
My problem is that I'm having a hard time accessing my existing C code from my Vala code. Is there an easy way to do this?
I've tried writing my own .vapi files (I didn't have any luck with the tool that came with vala), but I can't find any decent documentation on how to write these.
Does any exist? Do I need one of these files to call existing C code?
Yes, to call a C function, you need to write a binding for it. The process is described in http://live.gnome.org/Vala/Tutorial#Binding_Libraries_with_VAPI_Files, however, this doesn't apply directly to custom functions or libraries written without GObject. You'll probably need help from #vala IRC channel if you have complex binding for non-GObject libraries.
However, most of the time, we use simple vapi files to bind some autoconf define or some functions written in plain C, for efficiency reason or broken vala, or whatever other reason. And this is the way that most people do:
myfunc.vapi
[CCode (cheader_filename = "myfunc.h")]
namespace MyFunc {
[CCode (cname = "my_func_foo")]
public string foo (int bar, Object? o = null);
}
myfunc.h (and corresponding implementation in a .c linked with your project)
#include <glib-object.h>
char* my_func_foo(int bar, GObject* o)
example.vala could be
using MyFunc;
void main() {
baz = foo(42);
}
When compiling with valac, use --vapidir= to give the directory location of the myfunc.vapi. Depending on your build system, you may need to pass extra argument to valac or gcc CFLAGS in order to link everything together.
The only addition I would make to elmarco's answer is the extern keyword. If you're trying to access a single C function that's already available in one of your packages or the standard C/Posix libraries, you can access it easily this way.
For GLib-based libraries written in C you can try to generate gir-files from your C-sources: Vala/Bindings.
Doing it manually is no problem too. Suppose you have a library which defines SomelibClass1 in C with a method called do_something which takes a string.
The name of the headerfile is "somelib.h". Then the corresponding vapi is as simple as the following:
somelib.vapi:
[CCode (cheader_filename="somelib.h")]
namespace Somelib {
public class Class1 {
public void do_something (string str);
}
}
Documentation for writing vapis for non-GLib libraries can be found here: Vala/LegacyBindings
This is actually really easy. Lets take an excerpt from posix.vapi:
[Compact]
[CCode (cname = "FILE", free_function = "fclose", cheader_filename = "stdio.h")]
public class FILE {
[CCode (cname = "fopen")]
public static FILE? open (string path, string mode);
[CCode (cname = "fgets", instance_pos = -1)]
public unowned string? gets (char[] s);
}
This implements the following C-Function:
FILE *fopen (const char *path, const char *mode);
char *fgets (char *s, int size, FILE *stream);
When discarding the instance_pos attribute vala assumes that the object is the first parameter to a method. This way it is possible to bind c-constructs that are roughly object-oriented. The free_method of the compact-class is called when the object is dereferenced.
The CCode(cname)-attribute of a method, class, struct, etc. has to be the name of it as it would be in C.
There is a lot more to this subject, but this should give you a general overview.
It would probably be easier to just access your vala code from c. As all you have to do is just compile to C.