2

I just created a simple PDF Document containing a word "Test" in it and created a byte stream out of it in C# Console Application:

buff = File.ReadAllBytes(<Path of File>);

The size of the file is around 9,651 bytes. I also created a Win32 C dll that exports a function which takes the file byte array and the length of the byte array as an argument, declared in C# using this:

[DllImport("<path to dll>", CallingConvention = CallingConvention.Cdecl)] public static extern int file_data(byte[] byteArray, int length);

The method in C dll is exported as below:

#define FILEDATA_API __declspec(dllexport) FILEDATA_API int file_data(char *byteArray, int size);

I then invoked ret = file_data(buff, buff.length); and in the C code, wrote the character pointer received directly to a temp file character by character as below:

    while (length> 0)
    {
        fprintf(outFile, "%c", *fileData); //fileData is the actual byte array received from C# Code
        fileData++;
        length--;
    }

But the problem arises here, the C code that dumps out the byte array to a file character by character generates a file of size 9,755 bytes. Most of the content inside it seems to look correct, except some new lines that gets introduced(as far as i know and may be some additional data), which causes the PDF file to get corrupted and this dumped out version does not open in Adobe. Can someone please provide some pointers on where I might be going wrong? I cannot use %s in fprint since some combination of the byte array in the PDF results in null terminated string in C which then dumps out even lesser data than I expect.

Thanks.

UPDATE:

  1. The desired behavior is that the file byte array as received from C# and when written using C code to a file should make the file open successfully in Adobe.
  2. The code present in the problem should be sufficient for someone to generate a win32 dll, that simply writes out the char pointer to a file, but I have added few more details.
ardila
  • 1,277
  • 1
  • 13
  • 24
learn_develop
  • 1,735
  • 4
  • 15
  • 33
  • What is the signature of the C function? – Yacoub Massad Nov 27 '15 at 13:02
  • 1
    What mode are you opening the `outFile` in? Have you tried using `fwrite` instead of `fprintf`? – cbr Nov 27 '15 at 13:03
  • 1
    Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example. – too honest for this site Nov 27 '15 at 13:03
  • This is the signature of the C function: `int file_data(char *byteArray, int size);` – learn_develop Nov 27 '15 at 13:04
  • I am opening the file in `"w"` mode, is there any problem we see using `fprintf`? I can definitely give `fwrite` a shot and see if it works. – learn_develop Nov 27 '15 at 13:06
  • 1
    Use `"wb"`. See the second last paragraph of the Parameters section [here](http://www.cplusplus.com/reference/cstdio/fopen/#parameters). – cbr Nov 27 '15 at 13:10
  • It works @cubrr :) What a stupid mistake that was. – learn_develop Nov 27 '15 at 13:15
  • 1
    it is only a stupid mistake if you do it again tomorrow – Hugh Jones Nov 27 '15 at 13:18

1 Answers1

2

You're probably calling fopen without the b mode flag. Append b to your mode specifier:

FILE *outFile = fopen("file.txt", "wb")

From this site (emphasis mine):

Text files are files containing sequences of lines of text. Depending on the environment where the application runs, some special character conversion may occur in input/output operations in text mode to adapt them to a system-specific text file format. Although on some environments no conversions occur and both text files and binary files are treated the same way, using the appropriate mode improves portability.

In my experience, this "conversion" on Windows changes \n to \r\n at least.

cbr
  • 12,563
  • 3
  • 38
  • 63