Program that generates brainfuck code that outputs given text The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Optimizing string replacement program that uses recursionClassifying lexemes in a given C programInterpreting Brainfuck code to C#, then compiling to a .exeC program that reverses a stringBrainfuck code optimization in PythonC program that recovers lost JPEG filesProgram to find megaPrime numbers between 2 given integersDice roll game that generates random numberProgram that prints out the initials of a given nameText to Brainfuck translator

Is there a writing software that you can sort scenes like slides in PowerPoint?

Wolves and sheep

What force causes entropy to increase?

Derivation tree not rendering

Wall plug outlet change

Is it ok to offer lower paid work as a trial period before negotiating for a full-time job?

Keeping a retro style to sci-fi spaceships?

Semisimplicity of the category of coherent sheaves?

How should I replace vector<uint8_t>::const_iterator in an API?

Mortgage adviser recommends a longer term than necessary combined with overpayments

Format single node in tikzcd

Program that generates brainfuck code that outputs given text

Is this wall load bearing? Blueprints and photos attached

does high air pressure throw off wheel balance?

What's the point in a preamp?

How to colour the US map with Yellow, Green, Red and Blue to minimize the number of states with the colour of Green

Relations between two reciprocal partial derivatives?

Finding the path in a graph from A to B then back to A with a minimum of shared edges

Difference between "generating set" and free product?

Who or what is the being for whom Being is a question for Heidegger?

Can the DM override racial traits?

The following signatures were invalid: EXPKEYSIG 1397BC53640DB551

Sort a list of pairs representing an acyclic, partial automorphism

Is there a trick to getting spices to fix to nuts?



Program that generates brainfuck code that outputs given text



The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Optimizing string replacement program that uses recursionClassifying lexemes in a given C programInterpreting Brainfuck code to C#, then compiling to a .exeC program that reverses a stringBrainfuck code optimization in PythonC program that recovers lost JPEG filesProgram to find megaPrime numbers between 2 given integersDice roll game that generates random numberProgram that prints out the initials of a given nameText to Brainfuck translator



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








5












$begingroup$


I created program that generates brainfuck code that outputs given text.
Arguments for the program are input file with the text and output file where code will be generated to.
Here is the code:



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

#define ALLOCATION_ERROR 1
#define FILE_ERROR 2
#define OTHER_ERROR 3

static inline FILE*
get_file_pointer(const char* filename,const char* mode)
FILE* file_pointer=fopen(filename,mode);
if(file_pointer==NULL)
fprintf(stderr,"Error: failed to open file %sn",filename);
exit(FILE_ERROR);

return file_pointer;

static inline char*
int_to_brainfuck(int difference)
if(difference==0)
return ".";
else
char character_in_loop=difference>0?'+':'-';
difference=difference>0?difference:-difference;
const unsigned int loop_body_length=17;
const unsigned int number_of_ones=(unsigned int)(difference%10);
const unsigned int number_of_tens=(unsigned int)(difference/10);
char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
if(number_of_tens>0)
brainfuck_code[strlen(brainfuck_code)]='>';
memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
strcat(brainfuck_code+strlen(brainfuck_code),"[<");
memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
brainfuck_code[strlen(brainfuck_code)]='.';
return brainfuck_code;


static inline void
generate_code(FILE* input_file,FILE* output_file)
int current_char,last_char=0;
while((current_char=fgetc(input_file))!=EOF)
char* brainfuck_code=int_to_brainfuck(current_char-last_char);
fputs(brainfuck_code,output_file);
if(brainfuck_code[0]!='.')
free(brainfuck_code);
last_char=current_char;


static inline void
parse_args(int argc)
if(argc!=3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);


int
main(int argc,char** argv)
parse_args(argc);
FILE* input_file=get_file_pointer(argv[1],"r");
FILE* output_file=get_file_pointer(argv[2],"wb");
generate_code(input_file,output_file);
fclose(input_file);
fclose(output_file);
return 0;










share|improve this question











$endgroup$


















    5












    $begingroup$


    I created program that generates brainfuck code that outputs given text.
    Arguments for the program are input file with the text and output file where code will be generated to.
    Here is the code:



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

    #define ALLOCATION_ERROR 1
    #define FILE_ERROR 2
    #define OTHER_ERROR 3

    static inline FILE*
    get_file_pointer(const char* filename,const char* mode)
    FILE* file_pointer=fopen(filename,mode);
    if(file_pointer==NULL)
    fprintf(stderr,"Error: failed to open file %sn",filename);
    exit(FILE_ERROR);

    return file_pointer;

    static inline char*
    int_to_brainfuck(int difference)
    if(difference==0)
    return ".";
    else
    char character_in_loop=difference>0?'+':'-';
    difference=difference>0?difference:-difference;
    const unsigned int loop_body_length=17;
    const unsigned int number_of_ones=(unsigned int)(difference%10);
    const unsigned int number_of_tens=(unsigned int)(difference/10);
    char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
    if(number_of_tens>0)
    brainfuck_code[strlen(brainfuck_code)]='>';
    memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
    strcat(brainfuck_code+strlen(brainfuck_code),"[<");
    memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
    strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

    memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
    brainfuck_code[strlen(brainfuck_code)]='.';
    return brainfuck_code;


    static inline void
    generate_code(FILE* input_file,FILE* output_file)
    int current_char,last_char=0;
    while((current_char=fgetc(input_file))!=EOF)
    char* brainfuck_code=int_to_brainfuck(current_char-last_char);
    fputs(brainfuck_code,output_file);
    if(brainfuck_code[0]!='.')
    free(brainfuck_code);
    last_char=current_char;


    static inline void
    parse_args(int argc)
    if(argc!=3)
    puts("Usage: bfgen <input> <output>");
    exit(OTHER_ERROR);


    int
    main(int argc,char** argv)
    parse_args(argc);
    FILE* input_file=get_file_pointer(argv[1],"r");
    FILE* output_file=get_file_pointer(argv[2],"wb");
    generate_code(input_file,output_file);
    fclose(input_file);
    fclose(output_file);
    return 0;










    share|improve this question











    $endgroup$














      5












      5








      5





      $begingroup$


      I created program that generates brainfuck code that outputs given text.
      Arguments for the program are input file with the text and output file where code will be generated to.
      Here is the code:



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

      #define ALLOCATION_ERROR 1
      #define FILE_ERROR 2
      #define OTHER_ERROR 3

      static inline FILE*
      get_file_pointer(const char* filename,const char* mode)
      FILE* file_pointer=fopen(filename,mode);
      if(file_pointer==NULL)
      fprintf(stderr,"Error: failed to open file %sn",filename);
      exit(FILE_ERROR);

      return file_pointer;

      static inline char*
      int_to_brainfuck(int difference)
      if(difference==0)
      return ".";
      else
      char character_in_loop=difference>0?'+':'-';
      difference=difference>0?difference:-difference;
      const unsigned int loop_body_length=17;
      const unsigned int number_of_ones=(unsigned int)(difference%10);
      const unsigned int number_of_tens=(unsigned int)(difference/10);
      char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
      if(number_of_tens>0)
      brainfuck_code[strlen(brainfuck_code)]='>';
      memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
      strcat(brainfuck_code+strlen(brainfuck_code),"[<");
      memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
      strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

      memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
      brainfuck_code[strlen(brainfuck_code)]='.';
      return brainfuck_code;


      static inline void
      generate_code(FILE* input_file,FILE* output_file)
      int current_char,last_char=0;
      while((current_char=fgetc(input_file))!=EOF)
      char* brainfuck_code=int_to_brainfuck(current_char-last_char);
      fputs(brainfuck_code,output_file);
      if(brainfuck_code[0]!='.')
      free(brainfuck_code);
      last_char=current_char;


      static inline void
      parse_args(int argc)
      if(argc!=3)
      puts("Usage: bfgen <input> <output>");
      exit(OTHER_ERROR);


      int
      main(int argc,char** argv)
      parse_args(argc);
      FILE* input_file=get_file_pointer(argv[1],"r");
      FILE* output_file=get_file_pointer(argv[2],"wb");
      generate_code(input_file,output_file);
      fclose(input_file);
      fclose(output_file);
      return 0;










      share|improve this question











      $endgroup$




      I created program that generates brainfuck code that outputs given text.
      Arguments for the program are input file with the text and output file where code will be generated to.
      Here is the code:



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

      #define ALLOCATION_ERROR 1
      #define FILE_ERROR 2
      #define OTHER_ERROR 3

      static inline FILE*
      get_file_pointer(const char* filename,const char* mode)
      FILE* file_pointer=fopen(filename,mode);
      if(file_pointer==NULL)
      fprintf(stderr,"Error: failed to open file %sn",filename);
      exit(FILE_ERROR);

      return file_pointer;

      static inline char*
      int_to_brainfuck(int difference)
      if(difference==0)
      return ".";
      else
      char character_in_loop=difference>0?'+':'-';
      difference=difference>0?difference:-difference;
      const unsigned int loop_body_length=17;
      const unsigned int number_of_ones=(unsigned int)(difference%10);
      const unsigned int number_of_tens=(unsigned int)(difference/10);
      char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
      if(number_of_tens>0)
      brainfuck_code[strlen(brainfuck_code)]='>';
      memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
      strcat(brainfuck_code+strlen(brainfuck_code),"[<");
      memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
      strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

      memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
      brainfuck_code[strlen(brainfuck_code)]='.';
      return brainfuck_code;


      static inline void
      generate_code(FILE* input_file,FILE* output_file)
      int current_char,last_char=0;
      while((current_char=fgetc(input_file))!=EOF)
      char* brainfuck_code=int_to_brainfuck(current_char-last_char);
      fputs(brainfuck_code,output_file);
      if(brainfuck_code[0]!='.')
      free(brainfuck_code);
      last_char=current_char;


      static inline void
      parse_args(int argc)
      if(argc!=3)
      puts("Usage: bfgen <input> <output>");
      exit(OTHER_ERROR);


      int
      main(int argc,char** argv)
      parse_args(argc);
      FILE* input_file=get_file_pointer(argv[1],"r");
      FILE* output_file=get_file_pointer(argv[2],"wb");
      generate_code(input_file,output_file);
      fclose(input_file);
      fclose(output_file);
      return 0;







      c brainfuck compiler






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 1 hour ago









      200_success

      131k17157422




      131k17157422










      asked 4 hours ago









      DeBos99DeBos99

      1267




      1267




















          1 Answer
          1






          active

          oldest

          votes


















          2












          $begingroup$

          I opened your code in CLion. The first thing it marked was:



          #define ALLOCATION_ERROR 1


          It's unused.



          Other than that, there were no warnings, which is already quite good.



          Next I compiled your code using both GCC and CLang:



          $ gcc -Wall -Wextra -Os -c bfgen.c
          $ clang -Wall -Weverything -Os -c bfgen.c
          bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
          #define ALLOCATION_ERROR 1
          ^
          1 warning generated.


          That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



          Now to the human part of the code review.



          I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



          The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



          In the get_file_pointer function, you should include the kind of error in the fprintf output:



          fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


          The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



          Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



          size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
          char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
          char *code = brainfuck_code;

          if (number_of_tens > 0)
          *code++ = '>';
          memset(code, '+', number_of_tens);
          code += number_of_tens;
          strcpy(code, "[<");
          code += 3;
          memset(code, character_in_loop, 10);
          code += 10;
          strcpy(code, ">-]<");
          code += 4;


          memset(code, character_in_loop, number_of_ones);
          code += number_of_ones;
          *code++ = '.';

          assert(brainfuck_code + code_len == code);

          return brainfuck_code;


          I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



          I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



          size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


          This allows you to quickly compare it to the code.



          Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



          typedef struct 
          FILE *out;
          bfgen;

          static void bfgen_emit_str(bfgen *gen, const char *code)
          ...


          static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
          ...



          Then you can simply write:



          static void
          bfgen_emit_difference(bfgen *gen, int difference)
          if (difference == 0)
          bfgen_emit_str(".");
          return;


          char character_in_loop = difference > 0 ? '+' : '-';
          unsigned int abs_diff = difference > 0 ? difference : -difference;
          unsigned int number_of_tens = abs_diff / 10;

          if (number_of_tens > 0)
          bfgen_emit_str(gen, ">");
          bfgen_emit_repeat(gen, '+', number_of_tens);
          bfgen_emit_str(gen, "[<");
          bfgen_emit_repeat(gen, character_in_loop, 10);
          bfgen_emit_str(gen, ">-]<");


          bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
          bfgen_emit_str(gen, ".");



          This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



          Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



          static void bfgen_emit_str(bfgen *gen, const char *code) 
          fputs(code, gen->out);


          static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
          for (size_t i = 0; i < n; i++)
          fputc(code, gen->out);




          Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




          It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



          static char *
          int_to_brainfuck(...)
          if (condition)
          return ".";
          else
          return allocated_string;




          You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




          In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




          The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



          An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



          The rewritten and restructured code is:



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

          #define FILE_ERROR 2
          #define OTHER_ERROR 3

          static FILE *
          xopen(const char *filename, const char *mode)
          FILE *file_pointer = fopen(filename, mode);
          if (file_pointer == NULL)
          fprintf(stderr, "Error: failed to open file '%s': %sn",
          filename, strerror(errno));
          exit(FILE_ERROR);

          return file_pointer;


          typedef struct
          FILE *out;
          bfgen;

          static void
          bfgen_emit_str(bfgen *gen, const char *code)
          fputs(code, gen->out);


          static void
          bfgen_emit_repeat(bfgen *gen, char code, size_t n)
          for (size_t i = 0; i < n; i++)
          fputc(code, gen->out);



          static void
          bfgen_emit_difference(bfgen *gen, int difference)
          if (difference == 0)
          return;


          char character_in_loop = difference > 0 ? '+' : '-';
          unsigned int abs_diff = difference > 0 ? difference : -difference;
          unsigned int number_of_tens = abs_diff / 10;

          if (number_of_tens > 0)
          bfgen_emit_str(gen, ">");
          bfgen_emit_repeat(gen, '+', number_of_tens);
          bfgen_emit_str(gen, "[<");
          bfgen_emit_repeat(gen, character_in_loop, 10);
          bfgen_emit_str(gen, ">-]<");


          bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


          static void
          bfgen_generate_code(bfgen *gen, FILE *input_file)
          int current_char, last_char = 0;
          while ((current_char = fgetc(input_file)) != EOF)
          bfgen_emit_difference(gen, current_char - last_char);
          bfgen_emit_str(gen, ".n");
          last_char = current_char;



          static void
          parse_args(int argc)
          if (argc != 3)
          puts("Usage: bfgen <input> <output>");
          exit(OTHER_ERROR);



          int
          main(int argc, char **argv)
          parse_args(argc);
          FILE *input_file = xopen(argv[1], "rb");
          FILE *output_file = xopen(argv[2], "w");
          bfgen gen = output_file;
          bfgen_generate_code(&gen, input_file);
          fclose(output_file);
          fclose(input_file);
          return 0;






          share|improve this answer











          $endgroup$













            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "196"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217422%2fprogram-that-generates-brainfuck-code-that-outputs-given-text%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2












            $begingroup$

            I opened your code in CLion. The first thing it marked was:



            #define ALLOCATION_ERROR 1


            It's unused.



            Other than that, there were no warnings, which is already quite good.



            Next I compiled your code using both GCC and CLang:



            $ gcc -Wall -Wextra -Os -c bfgen.c
            $ clang -Wall -Weverything -Os -c bfgen.c
            bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
            #define ALLOCATION_ERROR 1
            ^
            1 warning generated.


            That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



            Now to the human part of the code review.



            I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



            The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



            In the get_file_pointer function, you should include the kind of error in the fprintf output:



            fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


            The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



            Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



            size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
            char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
            char *code = brainfuck_code;

            if (number_of_tens > 0)
            *code++ = '>';
            memset(code, '+', number_of_tens);
            code += number_of_tens;
            strcpy(code, "[<");
            code += 3;
            memset(code, character_in_loop, 10);
            code += 10;
            strcpy(code, ">-]<");
            code += 4;


            memset(code, character_in_loop, number_of_ones);
            code += number_of_ones;
            *code++ = '.';

            assert(brainfuck_code + code_len == code);

            return brainfuck_code;


            I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



            I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



            size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


            This allows you to quickly compare it to the code.



            Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



            typedef struct 
            FILE *out;
            bfgen;

            static void bfgen_emit_str(bfgen *gen, const char *code)
            ...


            static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
            ...



            Then you can simply write:



            static void
            bfgen_emit_difference(bfgen *gen, int difference)
            if (difference == 0)
            bfgen_emit_str(".");
            return;


            char character_in_loop = difference > 0 ? '+' : '-';
            unsigned int abs_diff = difference > 0 ? difference : -difference;
            unsigned int number_of_tens = abs_diff / 10;

            if (number_of_tens > 0)
            bfgen_emit_str(gen, ">");
            bfgen_emit_repeat(gen, '+', number_of_tens);
            bfgen_emit_str(gen, "[<");
            bfgen_emit_repeat(gen, character_in_loop, 10);
            bfgen_emit_str(gen, ">-]<");


            bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
            bfgen_emit_str(gen, ".");



            This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



            Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



            static void bfgen_emit_str(bfgen *gen, const char *code) 
            fputs(code, gen->out);


            static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
            for (size_t i = 0; i < n; i++)
            fputc(code, gen->out);




            Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




            It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



            static char *
            int_to_brainfuck(...)
            if (condition)
            return ".";
            else
            return allocated_string;




            You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




            In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




            The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



            An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



            The rewritten and restructured code is:



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

            #define FILE_ERROR 2
            #define OTHER_ERROR 3

            static FILE *
            xopen(const char *filename, const char *mode)
            FILE *file_pointer = fopen(filename, mode);
            if (file_pointer == NULL)
            fprintf(stderr, "Error: failed to open file '%s': %sn",
            filename, strerror(errno));
            exit(FILE_ERROR);

            return file_pointer;


            typedef struct
            FILE *out;
            bfgen;

            static void
            bfgen_emit_str(bfgen *gen, const char *code)
            fputs(code, gen->out);


            static void
            bfgen_emit_repeat(bfgen *gen, char code, size_t n)
            for (size_t i = 0; i < n; i++)
            fputc(code, gen->out);



            static void
            bfgen_emit_difference(bfgen *gen, int difference)
            if (difference == 0)
            return;


            char character_in_loop = difference > 0 ? '+' : '-';
            unsigned int abs_diff = difference > 0 ? difference : -difference;
            unsigned int number_of_tens = abs_diff / 10;

            if (number_of_tens > 0)
            bfgen_emit_str(gen, ">");
            bfgen_emit_repeat(gen, '+', number_of_tens);
            bfgen_emit_str(gen, "[<");
            bfgen_emit_repeat(gen, character_in_loop, 10);
            bfgen_emit_str(gen, ">-]<");


            bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


            static void
            bfgen_generate_code(bfgen *gen, FILE *input_file)
            int current_char, last_char = 0;
            while ((current_char = fgetc(input_file)) != EOF)
            bfgen_emit_difference(gen, current_char - last_char);
            bfgen_emit_str(gen, ".n");
            last_char = current_char;



            static void
            parse_args(int argc)
            if (argc != 3)
            puts("Usage: bfgen <input> <output>");
            exit(OTHER_ERROR);



            int
            main(int argc, char **argv)
            parse_args(argc);
            FILE *input_file = xopen(argv[1], "rb");
            FILE *output_file = xopen(argv[2], "w");
            bfgen gen = output_file;
            bfgen_generate_code(&gen, input_file);
            fclose(output_file);
            fclose(input_file);
            return 0;






            share|improve this answer











            $endgroup$

















              2












              $begingroup$

              I opened your code in CLion. The first thing it marked was:



              #define ALLOCATION_ERROR 1


              It's unused.



              Other than that, there were no warnings, which is already quite good.



              Next I compiled your code using both GCC and CLang:



              $ gcc -Wall -Wextra -Os -c bfgen.c
              $ clang -Wall -Weverything -Os -c bfgen.c
              bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
              #define ALLOCATION_ERROR 1
              ^
              1 warning generated.


              That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



              Now to the human part of the code review.



              I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



              The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



              In the get_file_pointer function, you should include the kind of error in the fprintf output:



              fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


              The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



              Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



              size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
              char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
              char *code = brainfuck_code;

              if (number_of_tens > 0)
              *code++ = '>';
              memset(code, '+', number_of_tens);
              code += number_of_tens;
              strcpy(code, "[<");
              code += 3;
              memset(code, character_in_loop, 10);
              code += 10;
              strcpy(code, ">-]<");
              code += 4;


              memset(code, character_in_loop, number_of_ones);
              code += number_of_ones;
              *code++ = '.';

              assert(brainfuck_code + code_len == code);

              return brainfuck_code;


              I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



              I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



              size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


              This allows you to quickly compare it to the code.



              Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



              typedef struct 
              FILE *out;
              bfgen;

              static void bfgen_emit_str(bfgen *gen, const char *code)
              ...


              static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
              ...



              Then you can simply write:



              static void
              bfgen_emit_difference(bfgen *gen, int difference)
              if (difference == 0)
              bfgen_emit_str(".");
              return;


              char character_in_loop = difference > 0 ? '+' : '-';
              unsigned int abs_diff = difference > 0 ? difference : -difference;
              unsigned int number_of_tens = abs_diff / 10;

              if (number_of_tens > 0)
              bfgen_emit_str(gen, ">");
              bfgen_emit_repeat(gen, '+', number_of_tens);
              bfgen_emit_str(gen, "[<");
              bfgen_emit_repeat(gen, character_in_loop, 10);
              bfgen_emit_str(gen, ">-]<");


              bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
              bfgen_emit_str(gen, ".");



              This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



              Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



              static void bfgen_emit_str(bfgen *gen, const char *code) 
              fputs(code, gen->out);


              static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
              for (size_t i = 0; i < n; i++)
              fputc(code, gen->out);




              Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




              It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



              static char *
              int_to_brainfuck(...)
              if (condition)
              return ".";
              else
              return allocated_string;




              You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




              In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




              The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



              An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



              The rewritten and restructured code is:



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

              #define FILE_ERROR 2
              #define OTHER_ERROR 3

              static FILE *
              xopen(const char *filename, const char *mode)
              FILE *file_pointer = fopen(filename, mode);
              if (file_pointer == NULL)
              fprintf(stderr, "Error: failed to open file '%s': %sn",
              filename, strerror(errno));
              exit(FILE_ERROR);

              return file_pointer;


              typedef struct
              FILE *out;
              bfgen;

              static void
              bfgen_emit_str(bfgen *gen, const char *code)
              fputs(code, gen->out);


              static void
              bfgen_emit_repeat(bfgen *gen, char code, size_t n)
              for (size_t i = 0; i < n; i++)
              fputc(code, gen->out);



              static void
              bfgen_emit_difference(bfgen *gen, int difference)
              if (difference == 0)
              return;


              char character_in_loop = difference > 0 ? '+' : '-';
              unsigned int abs_diff = difference > 0 ? difference : -difference;
              unsigned int number_of_tens = abs_diff / 10;

              if (number_of_tens > 0)
              bfgen_emit_str(gen, ">");
              bfgen_emit_repeat(gen, '+', number_of_tens);
              bfgen_emit_str(gen, "[<");
              bfgen_emit_repeat(gen, character_in_loop, 10);
              bfgen_emit_str(gen, ">-]<");


              bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


              static void
              bfgen_generate_code(bfgen *gen, FILE *input_file)
              int current_char, last_char = 0;
              while ((current_char = fgetc(input_file)) != EOF)
              bfgen_emit_difference(gen, current_char - last_char);
              bfgen_emit_str(gen, ".n");
              last_char = current_char;



              static void
              parse_args(int argc)
              if (argc != 3)
              puts("Usage: bfgen <input> <output>");
              exit(OTHER_ERROR);



              int
              main(int argc, char **argv)
              parse_args(argc);
              FILE *input_file = xopen(argv[1], "rb");
              FILE *output_file = xopen(argv[2], "w");
              bfgen gen = output_file;
              bfgen_generate_code(&gen, input_file);
              fclose(output_file);
              fclose(input_file);
              return 0;






              share|improve this answer











              $endgroup$















                2












                2








                2





                $begingroup$

                I opened your code in CLion. The first thing it marked was:



                #define ALLOCATION_ERROR 1


                It's unused.



                Other than that, there were no warnings, which is already quite good.



                Next I compiled your code using both GCC and CLang:



                $ gcc -Wall -Wextra -Os -c bfgen.c
                $ clang -Wall -Weverything -Os -c bfgen.c
                bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
                #define ALLOCATION_ERROR 1
                ^
                1 warning generated.


                That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



                Now to the human part of the code review.



                I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



                The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



                In the get_file_pointer function, you should include the kind of error in the fprintf output:



                fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


                The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



                Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



                size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
                char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
                char *code = brainfuck_code;

                if (number_of_tens > 0)
                *code++ = '>';
                memset(code, '+', number_of_tens);
                code += number_of_tens;
                strcpy(code, "[<");
                code += 3;
                memset(code, character_in_loop, 10);
                code += 10;
                strcpy(code, ">-]<");
                code += 4;


                memset(code, character_in_loop, number_of_ones);
                code += number_of_ones;
                *code++ = '.';

                assert(brainfuck_code + code_len == code);

                return brainfuck_code;


                I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



                I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



                size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


                This allows you to quickly compare it to the code.



                Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



                typedef struct 
                FILE *out;
                bfgen;

                static void bfgen_emit_str(bfgen *gen, const char *code)
                ...


                static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                ...



                Then you can simply write:



                static void
                bfgen_emit_difference(bfgen *gen, int difference)
                if (difference == 0)
                bfgen_emit_str(".");
                return;


                char character_in_loop = difference > 0 ? '+' : '-';
                unsigned int abs_diff = difference > 0 ? difference : -difference;
                unsigned int number_of_tens = abs_diff / 10;

                if (number_of_tens > 0)
                bfgen_emit_str(gen, ">");
                bfgen_emit_repeat(gen, '+', number_of_tens);
                bfgen_emit_str(gen, "[<");
                bfgen_emit_repeat(gen, character_in_loop, 10);
                bfgen_emit_str(gen, ">-]<");


                bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
                bfgen_emit_str(gen, ".");



                This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



                Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



                static void bfgen_emit_str(bfgen *gen, const char *code) 
                fputs(code, gen->out);


                static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                for (size_t i = 0; i < n; i++)
                fputc(code, gen->out);




                Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




                It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



                static char *
                int_to_brainfuck(...)
                if (condition)
                return ".";
                else
                return allocated_string;




                You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




                In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




                The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



                An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



                The rewritten and restructured code is:



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

                #define FILE_ERROR 2
                #define OTHER_ERROR 3

                static FILE *
                xopen(const char *filename, const char *mode)
                FILE *file_pointer = fopen(filename, mode);
                if (file_pointer == NULL)
                fprintf(stderr, "Error: failed to open file '%s': %sn",
                filename, strerror(errno));
                exit(FILE_ERROR);

                return file_pointer;


                typedef struct
                FILE *out;
                bfgen;

                static void
                bfgen_emit_str(bfgen *gen, const char *code)
                fputs(code, gen->out);


                static void
                bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                for (size_t i = 0; i < n; i++)
                fputc(code, gen->out);



                static void
                bfgen_emit_difference(bfgen *gen, int difference)
                if (difference == 0)
                return;


                char character_in_loop = difference > 0 ? '+' : '-';
                unsigned int abs_diff = difference > 0 ? difference : -difference;
                unsigned int number_of_tens = abs_diff / 10;

                if (number_of_tens > 0)
                bfgen_emit_str(gen, ">");
                bfgen_emit_repeat(gen, '+', number_of_tens);
                bfgen_emit_str(gen, "[<");
                bfgen_emit_repeat(gen, character_in_loop, 10);
                bfgen_emit_str(gen, ">-]<");


                bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


                static void
                bfgen_generate_code(bfgen *gen, FILE *input_file)
                int current_char, last_char = 0;
                while ((current_char = fgetc(input_file)) != EOF)
                bfgen_emit_difference(gen, current_char - last_char);
                bfgen_emit_str(gen, ".n");
                last_char = current_char;



                static void
                parse_args(int argc)
                if (argc != 3)
                puts("Usage: bfgen <input> <output>");
                exit(OTHER_ERROR);



                int
                main(int argc, char **argv)
                parse_args(argc);
                FILE *input_file = xopen(argv[1], "rb");
                FILE *output_file = xopen(argv[2], "w");
                bfgen gen = output_file;
                bfgen_generate_code(&gen, input_file);
                fclose(output_file);
                fclose(input_file);
                return 0;






                share|improve this answer











                $endgroup$



                I opened your code in CLion. The first thing it marked was:



                #define ALLOCATION_ERROR 1


                It's unused.



                Other than that, there were no warnings, which is already quite good.



                Next I compiled your code using both GCC and CLang:



                $ gcc -Wall -Wextra -Os -c bfgen.c
                $ clang -Wall -Weverything -Os -c bfgen.c
                bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
                #define ALLOCATION_ERROR 1
                ^
                1 warning generated.


                That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



                Now to the human part of the code review.



                I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



                The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



                In the get_file_pointer function, you should include the kind of error in the fprintf output:



                fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


                The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



                Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



                size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
                char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
                char *code = brainfuck_code;

                if (number_of_tens > 0)
                *code++ = '>';
                memset(code, '+', number_of_tens);
                code += number_of_tens;
                strcpy(code, "[<");
                code += 3;
                memset(code, character_in_loop, 10);
                code += 10;
                strcpy(code, ">-]<");
                code += 4;


                memset(code, character_in_loop, number_of_ones);
                code += number_of_ones;
                *code++ = '.';

                assert(brainfuck_code + code_len == code);

                return brainfuck_code;


                I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



                I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



                size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


                This allows you to quickly compare it to the code.



                Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



                typedef struct 
                FILE *out;
                bfgen;

                static void bfgen_emit_str(bfgen *gen, const char *code)
                ...


                static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                ...



                Then you can simply write:



                static void
                bfgen_emit_difference(bfgen *gen, int difference)
                if (difference == 0)
                bfgen_emit_str(".");
                return;


                char character_in_loop = difference > 0 ? '+' : '-';
                unsigned int abs_diff = difference > 0 ? difference : -difference;
                unsigned int number_of_tens = abs_diff / 10;

                if (number_of_tens > 0)
                bfgen_emit_str(gen, ">");
                bfgen_emit_repeat(gen, '+', number_of_tens);
                bfgen_emit_str(gen, "[<");
                bfgen_emit_repeat(gen, character_in_loop, 10);
                bfgen_emit_str(gen, ">-]<");


                bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
                bfgen_emit_str(gen, ".");



                This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



                Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



                static void bfgen_emit_str(bfgen *gen, const char *code) 
                fputs(code, gen->out);


                static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                for (size_t i = 0; i < n; i++)
                fputc(code, gen->out);




                Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




                It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



                static char *
                int_to_brainfuck(...)
                if (condition)
                return ".";
                else
                return allocated_string;




                You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




                In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




                The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



                An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



                The rewritten and restructured code is:



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

                #define FILE_ERROR 2
                #define OTHER_ERROR 3

                static FILE *
                xopen(const char *filename, const char *mode)
                FILE *file_pointer = fopen(filename, mode);
                if (file_pointer == NULL)
                fprintf(stderr, "Error: failed to open file '%s': %sn",
                filename, strerror(errno));
                exit(FILE_ERROR);

                return file_pointer;


                typedef struct
                FILE *out;
                bfgen;

                static void
                bfgen_emit_str(bfgen *gen, const char *code)
                fputs(code, gen->out);


                static void
                bfgen_emit_repeat(bfgen *gen, char code, size_t n)
                for (size_t i = 0; i < n; i++)
                fputc(code, gen->out);



                static void
                bfgen_emit_difference(bfgen *gen, int difference)
                if (difference == 0)
                return;


                char character_in_loop = difference > 0 ? '+' : '-';
                unsigned int abs_diff = difference > 0 ? difference : -difference;
                unsigned int number_of_tens = abs_diff / 10;

                if (number_of_tens > 0)
                bfgen_emit_str(gen, ">");
                bfgen_emit_repeat(gen, '+', number_of_tens);
                bfgen_emit_str(gen, "[<");
                bfgen_emit_repeat(gen, character_in_loop, 10);
                bfgen_emit_str(gen, ">-]<");


                bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


                static void
                bfgen_generate_code(bfgen *gen, FILE *input_file)
                int current_char, last_char = 0;
                while ((current_char = fgetc(input_file)) != EOF)
                bfgen_emit_difference(gen, current_char - last_char);
                bfgen_emit_str(gen, ".n");
                last_char = current_char;



                static void
                parse_args(int argc)
                if (argc != 3)
                puts("Usage: bfgen <input> <output>");
                exit(OTHER_ERROR);



                int
                main(int argc, char **argv)
                parse_args(argc);
                FILE *input_file = xopen(argv[1], "rb");
                FILE *output_file = xopen(argv[2], "w");
                bfgen gen = output_file;
                bfgen_generate_code(&gen, input_file);
                fclose(output_file);
                fclose(input_file);
                return 0;







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 52 mins ago

























                answered 1 hour ago









                Roland IlligRoland Illig

                11.5k11946




                11.5k11946



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Code Review Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217422%2fprogram-that-generates-brainfuck-code-that-outputs-given-text%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    یوتیوب محتویات پیشینه[ویرایش] فناوری‌های ویدئویی[ویرایش] شوخی‌های آوریل[ویرایش] سانسور و فیلترینگ[ویرایش] آمار و ارقامی از یوتیوب[ویرایش] تأثیر اجتماعی[ویرایش] سیاست اجتماعی[ویرایش] نمودارها[ویرایش] یادداشت‌ها[ویرایش] پانویس[ویرایش] پیوند به بیرون[ویرایش] منوی ناوبریبررسی شده‌استYouTube.com[بروزرسانی]"Youtube.com Site Info""زبان‌های یوتیوب""Surprise! There's a third YouTube co-founder"سایت یوتیوب برای چندمین بار در ایران فیلتر شدنسخهٔ اصلیسالار کمانگر جوان آمریکایی ایرانی الاصل مدیر سایت یوتیوب شدنسخهٔ اصلیVideo websites pop up, invite postingsthe originalthe originalYouTube: Overnight success has sparked a backlashthe original"Me at the zoo"YouTube serves up 100 million videos a day onlinethe originalcomScore Releases May 2010 U.S. Online Video Rankingsthe originalYouTube hits 4 billion daily video viewsthe originalYouTube users uploading two days of video every minutethe originalEric Schmidt, Princeton Colloquium on Public & Int'l Affairsthe original«Streaming Dreams»نسخهٔ اصلیAlexa Traffic Rank for YouTube (three month average)the originalHelp! YouTube is killing my business!the originalUtube sues YouTubethe originalGoogle closes $A2b YouTube dealthe originalFlash moves on to smart phonesthe originalYouTube HTML5 Video Playerنسخهٔ اصلیYouTube HTML5 Video Playerthe originalGoogle tries freeing Web video with WebMthe originalVideo length for uploadingthe originalYouTube caps video lengths to reduce infringementthe originalAccount Types: Longer videosthe originalYouTube bumps video limit to 15 minutesthe originalUploading large files and resumable uploadingthe originalVideo Formats: File formatsthe originalGetting Started: File formatsthe originalThe quest for a new video codec in Flash 8the originalAdobe Flash Video File Format Specification Version 10.1the originalYouTube Mobile goes livethe originalYouTube videos go HD with a simple hackthe originalYouTube now supports 4k-resolution videosthe originalYouTube to get high-def 1080p playerthe original«Approximate YouTube Bitrates»نسخهٔ اصلی«Bigger and Better: Encoding for YouTube 720p HD»نسخهٔ اصلی«YouTube's 1080p – Failure Depends on How You Look At It»نسخهٔ اصلیYouTube in 3Dthe originalYouTube in 3D?the originalYouTube 3D Videosthe originalYouTube adds a dimension, 3D goggles not includedthe originalYouTube Adds Stereoscopic 3D Video Support (And 3D Vision Support, Too)the original«Sharing YouTube Videos»نسخهٔ اصلی«Downloading videos from YouTube is not supported, except for one instance when it is permitted.»نسخهٔ اصلی«Terms of Use, 5.B»نسخهٔ اصلی«Some YouTube videos get download option»نسخهٔ اصلی«YouTube looks out for content owners, disables video ripping»«Downloading videos from YouTube is not supported, except for one instance when it is permitted.»نسخهٔ اصلی«YouTube Hopes To Boost Revenue With Video Downloads»نسخهٔ اصلی«YouTube Mobile»نسخهٔ اصلی«YouTube Live on Apple TV Today; Coming to iPhone on June 29»نسخهٔ اصلی«Goodbye Flash: YouTube mobile goes HTML5 on iPhone and Android»نسخهٔ اصلی«YouTube Mobile Goes HTML5, Video Quality Beats Native Apps Hands Down»نسخهٔ اصلی«TiVo Getting YouTube Streaming Today»نسخهٔ اصلی«YouTube video comes to Wii and PlayStation 3 game consoles»نسخهٔ اصلی«Coming Up Next... YouTube on Your TV»نسخهٔ اصلی«Experience YouTube XL on the Big Screen»نسخهٔ اصلی«Xbox Live Getting Live TV, YouTube & Bing Voice Search»نسخهٔ اصلی«YouTube content locations»نسخهٔ اصلی«April fools: YouTube turns the world up-side-down»نسخهٔ اصلی«YouTube goes back to 1911 for April Fools' Day»نسخهٔ اصلی«Simon Cowell's bromance, the self-driving Nascar and Hungry Hippos for iPad... the best April Fools' gags»نسخهٔ اصلی"YouTube Announces It Will Shut Down""YouTube Adds Darude 'Sandstorm' Button To Its Videos For April Fools' Day"«Censorship fears rise as Iran blocks access to top websites»نسخهٔ اصلی«China 'blocks YouTube video site'»نسخهٔ اصلی«YouTube shut down in Morocco»نسخهٔ اصلی«Thailand blocks access to YouTube»نسخهٔ اصلی«Ban on YouTube lifted after deal»نسخهٔ اصلی«Google's Gatekeepers»نسخهٔ اصلی«Turkey goes into battle with Google»نسخهٔ اصلی«Turkey lifts two-year ban on YouTube»نسخهٔ اصلیسانسور در ترکیه به یوتیوب رسیدلغو فیلترینگ یوتیوب در ترکیه«Pakistan blocks YouTube website»نسخهٔ اصلی«Pakistan lifts the ban on YouTube»نسخهٔ اصلی«Pakistan blocks access to YouTube in internet crackdown»نسخهٔ اصلی«Watchdog urges Libya to stop blocking websites»نسخهٔ اصلی«YouTube»نسخهٔ اصلی«Due to abuses of religion, customs Emirates, YouTube is blocked in the UAE»نسخهٔ اصلی«Google Conquered The Web - An Ultimate Winner»نسخهٔ اصلی«100 million videos are viewed daily on YouTube»نسخهٔ اصلی«Harry and Charlie Davies-Carr: Web gets taste for biting baby»نسخهٔ اصلی«Meet YouTube's 224 million girl, Natalie Tran»نسخهٔ اصلی«YouTube to Double Down on Its 'Channel' Experiment»نسخهٔ اصلی«13 Some Media Companies Choose to Profit From Pirated YouTube Clips»نسخهٔ اصلی«Irate HK man unlikely Web hero»نسخهٔ اصلی«Web Guitar Wizard Revealed at Last»نسخهٔ اصلی«Charlie bit my finger – again!»نسخهٔ اصلی«Lowered Expectations: Web Redefines 'Quality'»نسخهٔ اصلی«YouTube's 50 Greatest Viral Videos»نسخهٔ اصلیYouTube Community Guidelinesthe original«Why did my YouTube account get closed down?»نسخهٔ اصلی«Why do I have a sanction on my account?»نسخهٔ اصلی«Is YouTube's three-strike rule fair to users?»نسخهٔ اصلی«Viacom will sue YouTube for $1bn»نسخهٔ اصلی«Mediaset Files EUR500 Million Suit Vs Google's YouTube»نسخهٔ اصلی«Premier League to take action against YouTube»نسخهٔ اصلی«YouTube law fight 'threatens net'»نسخهٔ اصلی«Google must divulge YouTube log»نسخهٔ اصلی«Google Told to Turn Over User Data of YouTube»نسخهٔ اصلی«US judge tosses out Viacom copyright suit against YouTube»نسخهٔ اصلی«Google and Viacom: YouTube copyright lawsuit back on»نسخهٔ اصلی«Woman can sue over YouTube clip de-posting»نسخهٔ اصلی«YouTube loses court battle over music clips»نسخهٔ اصلیYouTube to Test Software To Ease Licensing Fightsthe original«Press Statistics»نسخهٔ اصلی«Testing YouTube's Audio Content ID System»نسخهٔ اصلی«Content ID disputes»نسخهٔ اصلیYouTube Community Guidelinesthe originalYouTube criticized in Germany over anti-Semitic Nazi videosthe originalFury as YouTube carries sick Hillsboro video insultthe originalYouTube attacked by MPs over sex and violence footagethe originalAl-Awlaki's YouTube Videos Targeted by Rep. Weinerthe originalYouTube Withdraws Cleric's Videosthe originalYouTube is letting users decide on terrorism-related videosthe original«Time's Person of the Year: You»نسخهٔ اصلی«Our top 10 funniest YouTube comments – what are yours?»نسخهٔ اصلی«YouTube's worst comments blocked by filter»نسخهٔ اصلی«Site Info YouTube»نسخهٔ اصلیوبگاه YouTubeوبگاه موبایل YouTubeوووووو

                    Magento 2 - Auto login with specific URL Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Customer can't login - Page refreshes but nothing happensCustom Login page redirectURL to login with redirect URL after completionCustomer login is case sensitiveLogin with phone number or email address - Magento 1.9Magento 2: Set Customer Account Confirmation StatusCustomer auto connect from URLHow to call customer login form in the custom module action magento 2?Change of customer login error message magento2Referrer URL in modal login form

                    Rest API with Magento using PHP with example. Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How to update product using magento client library for PHP?Oauth Error while extending Magento Rest APINot showing my custom api in wsdl(url) and web service list?Using Magento API(REST) via IXMLHTTPRequest COM ObjectHow to login in Magento website using REST APIREST api call for Guest userMagento API calling using HTML and javascriptUse API rest media management by storeView code (admin)Magento REST API Example ErrorsHow to log all rest api calls in magento2?How to update product using magento client library for PHP?