Joined: Fri Oct 27, 2006 9:42 am Posts: 1925 Location: Athens, GA, USA
|
OK, I am taking a somewhat more detailed look at it now, and have some questions. - What is this supposed to mean?
Code: //Comments with PHP-style verbosity for the full //effects that each of them cause. It will make //for a much better reference from the code itself //and much easier to read and understand. - Why did you comment out some of the header inclusions, and insert their details into the file itself? Why are some not commented out, and more specifically, why did you add some of their function prototypes anyway?
- Are you aware that <unistd.h>, <sys/stat.h>, and <sys/types.h> are Unix/POSIX specific, and in particular, that there is no requirement for a C library on a non-POSIX OS such as Windows to support functions such as stat() and mkdir()?
- Why did you prefix ever function in the file with OPCODE__Application_ and OPCODE__Compiler_, when the whole thing is a single file and there are no external declarations for them? Even from a namespace control perspective, this make no sense.
- Why any of these specialized versions of standard operations, defined in terms of those standard operations but in a way that is less clear than the standard versions? This isn't what was talking about when I mentioned buffer control! The whole point of that is to hide these details, not bring them front and center!!!!!
Code: int OPCODE__Application_get_Executable_Path(char **Executable_Path);
FILE * OPCODE__Application_open_Local_ReadOnly_ASCII_7bit_Name_BinaryFile(char *file_name);
FILE * OPCODE__Application_open_Local_ReadWrite_ASCII_7bit_Name_BinaryFile(char *file_name);
int OPCODE__Application_read_C_long_BinaryFile(FILE *srcfilehandle, long *longvalue);
int OPCODE__Application_write_C_long_BinaryFile(FILE *srcfilehandle, long longvalue);
int OPCODE__Application_write_C_long_BinaryFile_Position(FILE *srcfilehandle, long longvalue, unsigned long filepos);
int OPCODE__Application_write_C_long_BinaryFile_PositionPreserve(FILE *srcfilehandle, long longvalue, unsigned long filepos);
int OPCODE__Application_read_C_unsigned_char_byte_BinaryFile(FILE *srcfilehandle, unsigned char *charvalue);
long OPCODE__Application_read_C_unsigned_char_buffer_BinaryFile(FILE *srcfilehandle, unsigned char **charvalue, long length);
long OPCODE__Application_write_C_unsigned_char_buffer_BinaryFile(FILE *srcfilehandle, unsigned char *charvalue, unsigned long length); long OPCODE__Application_writeln_C_unsigned_char_buffer_BinaryFile(FILE *srcfilehandle, unsigned char *charvalue, unsigned long length);
long OPCODE__Application_write_C_unsigned_char_buffer_BinaryFile_PositionPreserve(FILE *srcfilehandle, unsigned char *charvalue, unsigned long length); long OPCODE__Application_writeln_C_unsigned_char_buffer_BinaryFile_PositionPreserve(FILE *srcfilehandle, unsigned char *charvalue, unsigned long length);
long OPCODE__Application_get_Opened_File_Size(FILE *filehandle);
int OPCODE__Application_move_File_Position(FILE *srcfilehandle, long newabspos);
long OPCODE__Application_get_File_Position(FILE *srcfilehandle);
int OPCODE__Application__is_EOF(FILE *filehandle);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_find_Nearest_NewlineMarkers(FILE *src, FILE *lines_dat_file);
void OPCODE__Compiler_copy_ASCIIZ_string(unsigned char *src, unsigned char **dest);
int OPCODE__Compiler_Print_ASCII_7bit_String(char *str);
int OPCODE__Compiler_Println_ASCII_7bit_String(char *str);
int OPCODE__Compiler_Print_ASCII_7bit_C_long_HexString(long value);
int OPCODE__Compiler_is_Version_String_Request(char *cmdlinearg);
void OPCODE__Compiler_Print_Version_to_Screen();
int OPCODE__Compiler_Create_build_Directory(char *str);
int OPCODE__Compiler_Open_Global_Compilation_Files();
int OPCODE__Compiler_define_ASCII_text_lines(FILE *lines_metadata_file, FILE *srcfilehandle);
int OPCODE__Compiler_Load_ASCII_Text_File(FILE *filehandle, FILE *line_data_file);
void OPCODE__Compiler_Unload_ASCII_Text_File(FILE *filehandle);
int OPCODE__Compiler_Switch_ASCII_Text_File(FILE *filehandle);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_readline(FILE *src, FILE *lines_dat_file, unsigned long linenumber);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_readline_char_size(FILE *src, FILE *lines_dat_file, unsigned long linenumber, unsigned long charpos, unsigned long size);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_getLength_line_char(FILE *lines_dat_file, unsigned long linenumber, unsigned long charpos);
long OPCODE__Application_read_C_ASCIIZ_byte_string_BinaryFile(FILE *srcfilehandle, unsigned long length);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_goto_line_char(FILE *src, FILE *lines_dat_file, unsigned long linenumber, unsigned long charpos);
long OPCODE__Compiler_BinarySourceFile_ASCII_8bit_get_line_char_from_fileOffset(FILE *src, FILE *lines_dat_file, unsigned long fileOffset, unsigned long *linenumber, unsigned long *charpos);
int OPCODE__Compiler_BinarySourceFile_ASCII_8bit_compare_string(FILE *src0, unsigned long file0ptrpos, FILE *src1, unsigned long file1ptrpos, unsigned long length, int movePointer);
int OPCODE__Compiler_ASCII_8bit_compare_string(unsigned char *str0, unsigned char *str1, unsigned long str0len);
- Why is a compiler targeting an assembler even handling binary files at all?
- Binary source files? WTF are you talking about with that?
- Why specify 7-bit ASCII vs 8-bit ASCII, when there is no such thing as a standard 8-bit ASCII character set? What are you trying to say with those names? Is it to allow for UTF-8 (which is not ASCII, even if the ASCII character set is a subset of the standard UTF-8 code points), or some other 8-bit+ ASCII-derived encoding like Latin-1, and if so, why not call it that?
- Why are all of your 'buffers' declared as pointers? Are you intending to dynamically allocate the buffers in every single case, and if so, why, and how do you intend to determine the sizes for the buffers before you have read them? The usual practice is to allocate a large-ish buffer (say, 1024 bytes), fill that, and process that buffer's worth of data; you would then re-load that buffer as needed, rather than trying to find the file size ahead of time. Why isn't that adequate for your needs, when the alternative you seem to want involves filesystem-specific details that the standard C library can't access?
- Why are you hardcoding file paths, of all things? Seriously, file paths????
- Reading the source file line by line... don't. Just don't. Seriously, if you can't figure that much out yet, you have no business writing code in C, never mind writing a C compiler in C.
- This, just... THIS!
Code: //General use variables: /// //General use variables: /// unsigned char *COMPILER__fileBuf0000=NULL; long COMPILER__fileBuf0000_logical_file_offset=0; long COMPILER__fileBuf0000_file_buffer_offset=0; long COMPILER__fileBuf0000_charbuflen=0; long COMPILER__fileBuf0000_origfilepos0=0; long COMPILER__fileBuf0000_newlineMarkerSZ=0; long COMPILER__fileBuf0000_bufferOverrun=0;
Appalling naming 'convention' aside, it never occurred to you to bundle these into a struct? - Why are you using a long for the newline marker size - hell, why is it there at all, rather than, say, a null-delimited string of the newline for this system? Actually, let me re-phrase that as: WHY THE HECK WOULD THE COMPILER NEED TO EVEN KNOW WHAT THE NEWLINE IS, IN A LANGUAGE WHICH TREATS ALL WHITESPACE IDENTICALLY (not counting line comments and preprocessor operations)? You don't need to know the size of the newline, because no matter what else, it is going to be either a whitespace character, or a group of two or more whitespace characters - and any sequence of one or more whitespace characters is treated as a single space. Period, end of subject.
- You might object to this in saying that you need to know how many lines the program has. This, however, is only true for the purposes of producing a program listing and error messages - the compiler itself doesn't need that information at all. For those things that do need it? The tokenizer should handle it. THAT'S WHY YOU HAVE ONE. For most of the things in the compiler, the exact text of the token isn't important, and for those things where it does matter, such as literals, it should be handled in the symbol table.
- What in Eris' name is the 'bufferOverrun' counter for, and why would it need to be a long? Are you expecting to be compiling source files larger than 4 GiB, and if so... no, I won't even finish that sentence, I honestly don't want to know.
And this is still only scratching the surface. I am genuinely at a loss as to what you think you are doing with this, or what you think any of this garbage has to do with compiling C code.
Attachments: |
c.c [50.74 KiB]
Downloaded 104 times
|
_________________ Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF Ordo OS Project Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
|
|