I'm currently porting code from stlport 5.1.3 to stl with MSVS 2010. I'm facing a problem and I hope someone can help me.
Somewhere in the code is:
HANDLE lHandle = CreateFileW(...);
ifstream lStream( lHandle );
// more job here...
This builds with stlport because the basic_ifstream has a cTor that takes a void*. But standard stl doesn't. I should write something like:
ifstream lStream( /*FileName*/ );
...but my file name is a wchar_t *. ifstream cTor only takes char *...
Do you know a work around?
Thanks in advance,
Dominique
Well, it seems that stl included in MSVC2010 provides all the stuff I needed but it was not in the doc.
CreateFile was use because the former std::fstream could not handle wide char file name. Now, it has a cTor and a open() member for that.
Also, the new flavor of ifstream allows the programmer to set a sharing protection mode. I needed that also and it was done by CreateFile...
Thus, the "new" stl give me all the power I needed. Just a little flaw in the doc.
Related
I am using gSoap to generate ANSI C source code, that I would like to build within the LabWindows/CVI environment, on a Windows 7, 64 bit OS. The gSoap file stdsoap2.c includes several instances of the _setmode() function, with the following prototype:
int _setmode (int fd, int mode);
Where fd is a file descriptor, and mode is set to either _O_TEXT or _O_BINARY.
Oddly enough, even though LW/CVI contains an interface to Microsoft's SDK, this SDK does not contain a prototype to _setmode in any of its included header files, even though the help link to the SDK contains information on the function.
Is anyone aware of the method in LabWindows/CVI used to set file (or stream) translation mode to text, or binary.
Thanks,
Ryyker
Closing the loop on this question.
I could not use the only offered answer for the reason listed in my comment above.
Although I did use the SDK, it was not to select a different version of the OpenFile function, rather it was to support the use of a function that an auto-code generator used, _setmode() but that was not supported by my primary development environment (LabWindows/CVI).
So, in summary, my solution WAS to include the SDK to give me definition for _setmode as well as including the following in my non- auto-generated code:
#define _O_TEXT 0x4000 /* file mode is text (translated) */
#define _O_BINARY 0x8000 /* file mode is binary (untranslated) */
So, with the caveat that this post describes what I actually did, I am going to mark the answer #gary offered as the answer, as it was in the ball park. Thanks #gary.
It sounds like you just want to open a file as either ASCII or binary. So you should be able to replace the instances of _setmode() with the LW/CVI OpenFile() function as described here. Here's a short example reading a file as binary.
char filename = "path//to//file.ext"
int result;
result = OpenFile(filename, VAL_READ_ONLY, VAL_OPEN_AS_IS, VAL_BINARY);
if (result < 0)
// Error, notify user.
else
// No error.
Also note this warning from the page:
Caution The Windows SDK also contains an OpenFile function. If you
include windows.h and do not include formatio.h, you will get compile
errors if you call OpenFile.
I need to port snprintf() to another platform that does not fully support GLibC.
I am looking for the underlying declaration in the Glibc 2.14 source code. I follow many function calls, but get stuck on vfprintf(). It then seems to call _IO_vfprintf(), but I cannot find the definition. Probably a macro is obfuscating things.
I need to see the real C code that scans the format string and calculates the number of bytes it would write if input buffer was large enough.
I also tried looking in newlib 1.19.0, but I got stuck on _svfprintf_r(). I cannot find the definition anywhere.
Can someone point me to either definition or another one for snprintf()?
I've spent quite a while digging the sources to find _svfprintf_r() (and friends) definitions in the Newlib. Since OP asked about it, I'll post my finding for the poor souls who need those as well. The following holds true for Newlib 1.20.0, but I guess it is more or less the same across different versions.
The actual sources are located in the vfprintf.c file. There is a macro _VFPRINTF_R set to one of _svfiprintf_r, _vfiprintf_r, _svfprintf_r, or _vfprintf_r (depending on the build options), and then the actual implementation function is defined accordingly:
int
_DEFUN(_VFPRINTF_R, (data, fp, fmt0, ap),
struct _reent *data _AND
FILE * fp _AND
_CONST char *fmt0 _AND
va_list ap)
{
...
http://www.ijs.si/software/snprintf/ has what they claim is a portable implementation of snprintf, including vsnprintf.c, asnprintf, vasnprintf, asprintf, vasprintf. Perhaps it can help.
The source code of the GNU C library (glibc) is hosted on sourceware.org.
Here is a link to the implementation of vfprintf(), which is called by snprintf():
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfprintf.c
I'm currently writing a Linux Kernel module which depends on the Linux Security Modules (LSM) at the moment it is nothing really, I just wanted to print out a simple message whenever a file is opened. The problem is: To register to the hook I need the function register_security, which - I found out after googleing - isn't exported anymore and thus can't be used by loadable kernel modules - only by modules which are compiled directly into the kernel.
Of course this makes sense for a security module, but it suckes for me developing.
So now the question to you: Is there a way of patching my module into the kernel? I mean, I don't want to recompile my kernel after every bugfix or for every minor change. I could live with rebooting my pc for every new try, but recompiling would take a little bit to long I guess..
Edit: Hm, noone yet :( I just had an idea, maybe someone can tell me if it's good or not: Can't I just add the EXPORT_SYMBOL in the kernel source for the functions I need, then recompile it and then add my code as a module? Of course this would be just for testing and debugging
Can't you just use fsnotify in kernel, or fanotify from user space?
It's not generally a good idea to export functions that the author didn't think it would be a good idea to export. If you call a function that isn't part of the public interface and that function has a side effect, you will probably break things. Besides, your module won't work on other machines, but maybe you don't care about this.
No, there is not. When a symbol is not exported, the in-kernel linker will not be able to find it. But adding the export to the kernel you use for testing should be OK. You can add your module to the export list by adding it to ./include/linux/Kbuild.
Also if testing in (user-mode-linux)[http://user-mode-linux.sourceforge.net/] or in virtual box, recompiling whole kernel might not be that big problem.
This may be a bit late as I see your question a while back. What I found to be a good solution is to write a module that you compile into the kernel and just exports the couple of functions you what to play with.
For example
//REGISTER FILE_PERMISSION
static void k_register_file_permission(int (*my_file_permission) (struct file *file, int mask)) {
my_file_permission_func = my_file_permission;
}
EXPORT_SYMBOL(k_register_file_permission);
Then you can just call k_register_file_permission from your kernel module, handy durring the development process.
You would also need a function like
int k_file_permission (struct file *file, int mask) {
if(my_file_permission_func == NULL)
{
//do nothing
}
else
{
return my_file_permission_func(file, mask);
}
return 0;
}
That you would register with the LSM at boot time.
IDE: VS2005
Is there anyway to know why ReadFile() failed? I can't find the reason some of the INI can't be read. Thanks.
EDIT:
CIniFile iniFile;
iniFile.SetPath( "C:\\Services\\Server\\Server.INI" );
if( iniFile.ReadFile())
my code...
The program never gets in the if block.
And, sorry for the confusing. I use this library for the CIniFile class. Hope this information helps to pinpoint the problem.
http://www.codeproject.com/kb/cpp/cinifileByCabadam.aspx
EDIT2: I found the reason, it's because some of the ini files are saved as Unicode. And that's the reason ReadFile() fails. But now the question is how to read Unicode ini files.
Normally GetLastError() should give you an error number to look up
EDIT: In the CIniFile project there seems to be no default constructor, try instead CIniFile( string const iniPath ) i.e.
CIniFile iniFile( "C:\\Services\\Server\\Server.INI" );
if( iniFile.ReadFile())
EDIT2: OK, you would need to modify the code to instead of using fstream use wfstream - see
I'm trying to build a shared library (DLL) on Windows, using MSVC 6 (retro!) and I have a peculiar link issue I need to resolve. My shared library must access some global state, controlled by the loading application.
Broadly, what I have is this:
application.c:
static int g_private_value;
int use_private_value() {
/* do something with g_private_value */
}
int main (...) {
return shared_library_method ();
}
shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method() {
use_private_value();
}
(Updated - I forgot the __declspec(dllexport) int __stdcall portion, but it's there in the real code)
How do I set up shared_library.dll so that it exports shared_library_method and imports use_private_value?
Please remember that A) I'm a unix programmer, generally, and B) that I'm doing this without Visual Studio; our automated build infrastructure drives MSVC with makefiles. If I'm omitting something that will make it easier to answer the question, please comment and I'll update it ASAP.
This is actually going to be pretty difficult to get working. On Unix/Linux you can have shared objects and applications import symbols from each other, but on Windows you can't have a DLL import symbols from the application that loads it: the Windows PE executable format just doesn't support that idiom.
I know that the Cygwin project have some sort of work-around to address this problem, but I don't believe that it's trivial. Unless you want to do lots of PE-related hacking you probably don't want to go there.
An easier solution might be to just have some sort of initializer method exported from the DLL:
typedef int (*func_ptr)();
void init_library(func_ptr func);
The application must call this at start-up, passing in the address of the function you want to share. Not exactly elegant, but it should work okay.
I'll start with half of the answer.
In shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method(void)
{
}
The MSDN article about exporting function from DLL:s.
For the second half you need to export the functions from your application.c.
You can do this in the linker with:
/export:use_private_value#0
This should get you a lib-file that you build with your DLL.
The option to link the lib-file is to use GetProcAddress().
As DavidK noted if you only have a few functions it is probably easier to pass the function pointers in an init function. It is however possible to do what you are asking for.