Please be more specific at which code you are refering to. There are a lot of code snippets within this thread, e.g. 2 for different algorithms, one for searching a (8 char) substring of a specific password candidate etc
Furthermore, counting the GB is not always a good idea because the code might create different "types of newlines" (carriage return and line feed vs just line feed etc). This could already "waste" several MB/GB of disk space. It's more clever to count the lines instead.
According to Mrfancypants it should have 2.1 billion lines (ranging from 0 to 0x7fffffff, e.g 2147483648 lines). If you multiply 2147483648 * 13 (e.g. 12 char password + 1 new line) = 27917287424 ~ 26GiB (calculated like this: 27917287424 / 1024 / 1024 / 1024).
Therefore, 26 GiB (or 28GB, calculate like this: 27917287424 / 1000 / 1000 / 1000) seems to be the correct file size (at least if Mrfancypants's statement about 2.1 billion possibilities is correct).
update: writing the password candidates to disk might not be needed and maybe even be much more slower (depending on your disk speed), you could just pipe the output of the compiled version of nvg599.c to hashcat). Using a pipe you would avoid wasting disk space and too much disk I/O. It depends on many factors which of them is slower and which one is faster (or in general: which one has more advantages compared to the disadvantages).
Furthermore, counting the GB is not always a good idea because the code might create different "types of newlines" (carriage return and line feed vs just line feed etc). This could already "waste" several MB/GB of disk space. It's more clever to count the lines instead.
According to Mrfancypants it should have 2.1 billion lines (ranging from 0 to 0x7fffffff, e.g 2147483648 lines). If you multiply 2147483648 * 13 (e.g. 12 char password + 1 new line) = 27917287424 ~ 26GiB (calculated like this: 27917287424 / 1024 / 1024 / 1024).
Therefore, 26 GiB (or 28GB, calculate like this: 27917287424 / 1000 / 1000 / 1000) seems to be the correct file size (at least if Mrfancypants's statement about 2.1 billion possibilities is correct).
update: writing the password candidates to disk might not be needed and maybe even be much more slower (depending on your disk speed), you could just pipe the output of the compiled version of nvg599.c to hashcat). Using a pipe you would avoid wasting disk space and too much disk I/O. It depends on many factors which of them is slower and which one is faster (or in general: which one has more advantages compared to the disadvantages).