Thread: copy data from one file to another

@MK27 - well, oops.

I was pretty sure I was wrong when I hit send, but it always happens that way doesn't it? I can find some creative words to describe you too, by the way. I suggest you not dish out unwarranted insults.

Oh! And who could forget this little gem.

Example:

Code:

#include <stdlib.h>
#include <stdio.h>

#define IS_LESS_THAN <

int main(int the_number_of_command_line_arguments, char **the_command_line_parameter)
{
  char buffer[4096];

  if(the_number_of_command_line_arguments IS_LESS_THAN 3)
    return EXIT_FAILURE;

  snprintf(buffer, sizeof(buffer)-1, "copy &#37;s %s", 
    the_command_line_parameter[1],
    the_command_line_parameter[2]);

  system(buffer);
  return EXIT_FAILURE;
}

Oooops, I didn't notice the line number mumbo jumbo. MK27's code hardly seems brilliant. I mean come on now dude...

Code:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  if(argc != 3)
    puts("Usage: copyfile [from] [to]");
  else
  {
    FILE *ifile, *ofile;
    char *buffer;
    size_t line;

    ifile = fopen(argv[1], "r");
    ofile = fopen(argv[2], "w");

    if(!ifile || !ofile)
    {
      perror("Could not complete this operation.");

      if(ifile)
        fclose(ifile);

      if(ofile)
        fclose(ofile);

      return EXIT_FAILURE;
    }

    if(!(buffer = malloc(0x80000))) /* .5MB is sufficient */
    {
      fputs("Out of memory!\n", stderr);
      fclose(ifile);
      fclose(ofile);
      return EXIT_FAILURE;
    }

    line = 0;
    while(fgets(buffer, 0x80000, ifile))
    {
      fprintf(ofile, "&#37;3d. %s", ++line, buffer);
    }

    free(buffer);
    fclose(ifile);
    fclose(ofile);
  }

  return EXIT_SUCCESS;
}

Originally Posted by MK27

Sometimes you get what you asked for:

edit: there's actually three very minor bugs in this, and Salem found them all (see subsequent posts).

I do not see any minor errors. I only see crippling ones and ones that make the program HIGHLY under-efficient if it even works to begin with.

You obviously know where the edit button is, so please fix your code.

Originally Posted by MK27

But if that's all that happened we return 0 to indicate we reached EOF without adding to buffer, so the one byte buffer that we never wrote to is freed.

My explanation was a bit off but the code remains brilliant.

Well, it's not freed by you. The person using streamline will have to free it.

You can say (I guess you are saying) that it's an undocumented (as of yet) feature that your function will leave buffer in an invalid state when \n is immediately followed by EOF, and I would agree with you that one fix is to then document that when your function returns 0, buffer is invalid and should not be accessed. I will leave it to you to determine whether that's a bug in the code or a bug in the comments (since your comment about what return 0 means at the bottom is incorrect).

Originally Posted by MK27

I'm going to claim that it's actually me and I did do it. Honest.

But, don't you think it would be going too far, after having actually written some half-brilliant code which I should never have done because it might get used in someone's homework, to then provide our negligent student with some kind of API documentation to complete the charade?

I hate to be the psyche student on you but your code is neither brilliant nor worth using for homework purposes. I was going to simply correct your code but the entire way it works was too flawed to even fix it. You do realize that allocation is one of the most expensive operations you can do, right?

Originally Posted by MK27

I notice Master5001 managed to streamline things a bit. b/t/w, why does

Code:

malloc(0x80000)

equal .5mb?

Because 0x80000 is half a mebabyte in hexidecimal. Figure if 0x100000 is 1MG, then 0x100000 / 2 = 0x80000. Right? .5MB = 2^19, right?

Originally Posted by MK27

I'm going to claim that it's actually me and I did do it. Honest.

But, don't you think it would be going too far, after having actually written some half-brilliant code which I should never have done because it might get used in someone's homework, to then provide our negligent student with some kind of API documentation to complete the charade?

Since the whole exercise was already going too far, that's irrelevant.

I realize you were happy to have a solution that (seemed to) work, and you wanted to share; and if you had just done so, you probably would still have had a couple people make noises about doing people's homework, but that's mostly small potatoes (everybody has a line, but in different places), and using code as a "teachable moment" can be useful.

The flip side is that you have become a regular here -- you've started 25 threads in the last two months, after all -- and a known quantity. And posting the code that you did, calling it "brilliant" and "bug-free"; well, that's a teachable moment, too. Not just that pride goeth before a fall, but maybe to see what bug-free code actually is.

I'm getting way too philosophical for a Friday, so I'll stop.

Haha you made me laugh :-) In all seriousness, your code isn't "not-brilliant" because of how you did it. It is problematic because of the fact that global buffers are just plain messy. Simply put your code is quite excellent except that it requires the caller to do stuff to clean up after each and every call to the function. And the function is slower because of the fact that it must allocate buffers each and every call (well, probably not, malloc may be over-allocating).

Its better to do malloc(1000) than malloc(1) and incrementally increase the buffer size. What you can do is have a factor to increase your malloc by and just allocate chunks at a time.