Index
> Compiler Internals > Suggestion: Save Virtual Block as FileGoto page 1, 2, 3 Next |
| Author |
|
|
baldr 18 Jun 2014, 18:05
And there is m3ntal, who probably knows about e-mail and private messages more than anybody else but don't use them to contact the particular person.
 |
|||
18 Jun 2014, 18:05 |
|
|
Tomasz Grysztar 18 Jun 2014, 20:31
m3ntal wrote: FASM can load external source+binary files (include+file), but there is no way to save files as .EXT at assembly time. You must assemble the entire project as .EXT (format binary as '.EXT'). Example: But I'm not sure about the syntax. Maybe something like: Code: store p as 'name.ext' ________________ * Though it would sometimes hit some performance problems when having multiple passes but saving file early in the source, when assembler does not yet know that it will need another pass. |
|||
|
18 Jun 2014, 20:31 |
|
|
m3ntal 18 Jun 2014, 21:36
Quote: Is "p" in your example the addressing space label (one defined with "::")? That would make sense Quote: But I'm not sure about the syntax. Maybe something like: Code: store p as 'name.ext' Thanks for your response. |
|||
|
18 Jun 2014, 21:36 |
|
|
l_inc 18 Jun 2014, 23:04
Tomasz Grysztar
I think, spawning arbitrary files at arbitrary file system locations is a bit too far from what a compiler should do. I would definitely agree, that this possibility could be useful for many use cases, but those are not really compiler related. Like the next ideas could be to create folders, to write into the registry or to call arbitrary external library functions, which are no doubt useful but those are rather tasks for some scripting languages like shell or autohotkey. I'm not sure I want to be afraid of compiling some unknown fasm sources, because the very compilation could lead to polluting my system with hundreds of fat files. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
18 Jun 2014, 23:04 |
|
|
revolution 19 Jun 2014, 00:59
m3ntal wrote: (PS: There are users who are not experienced enough in programming to understand why this feature would be useful and there are knowledgeable programmers who are good at answering questions but they don't have the creativity to imagine the possibilities. And there are users who have knowledge of macros but can't seem to understand the difference between an immediate and displacement. That's why Z6502 needs the =i prefix). BTW: How is this related to macros and immediate displacements? Seems to be a non sequitur. |
|||
|
19 Jun 2014, 00:59 |
|
|
m3ntal 19 Jun 2014, 03:04
I think the only additional feature that's needed is the ability to check if the file currently exists (ifexists?).
revolution: Not referring to you. I'm the real dummy who has a horrible addiction to programming when I should be concerned about making money and taking care of responsibilities. To answer your question, though, there are many cases where I've needed to save a block of memory as "FILE.EXT" - utilities, conversions, create resources, make files, etc. |
|||
|
19 Jun 2014, 03:04 |
|
|
revolution 19 Jun 2014, 03:39
m3ntal wrote: To answer your question, though, there are many cases where I've needed to save a block of memory as "FILE.EXT" - utilities, conversions, create resources, make files, etc. It would seem to be similar to edfed's suggestion where we could create arbitrary files at compile time. http://board.flatassembler.net/topic.php?t=15850 |
|||
|
19 Jun 2014, 03:39 |
|
|
m3ntal 19 Jun 2014, 05:15
Same argument can be used against the "if" directive or "file" (which could insert malicious code into the executable).
"An assembler shouldn't do that" - FASM is *not* just another typical assembler. It is unique and can do things that other assemblers can't. For example, FASM macros have multiple inheritance that goes beyond C++/Java's concept of OOP. |
|||
|
19 Jun 2014, 05:15 |
|
|
revolution 19 Jun 2014, 05:24
m3ntal wrote: "An assembler shouldn't do that" - FASM is *not* just another typical assembler. It is unique and can do things that other assemblers can't. For example, FASM macros have multiple inheritance that goes beyond C++/Java's concept of OOP. |
|||
|
19 Jun 2014, 05:24 |
|
|
evk1 19 Jun 2014, 05:33
It can be a good idea. But what about saving files to another folders?
Code: store p as 'folder\name.ext' Then we need directory creating and directory existence check directives too. _________________ Sorry for my English |
|||
|
19 Jun 2014, 05:33 |
|
|
JohnFound 19 Jun 2014, 06:13
This idea raises some security issues. For example, one can hide malicious code in his source code and then save it to somewhere on the system, masking the infiltration with some useful program compiled from the source. Even worse, if the source is obfuscated good enough and looking like a library, it can be reused by beginners and this way spreading the malicious code even further.
|
|||
|
19 Jun 2014, 06:13 |
|
|
m3ntal 19 Jun 2014, 06:33
revolution: You misunderstood. I'm saying that it's false categorization to throw FASM in the same boat with other assemblers because FASM is different. My reason for making this suggestion is: FASM has the ability to load external files but it can't save.
It's not an argument to say, in other words, "An assembler should not do that". Everyone has their own ideas of what an assembler is supposed to do based on their definition of what assembler is and their limited experience. Who cares? I'm only concerned about good ideas. evk: You answered your question  'folder\file.ext', '..\..\file.ext'. (Awesome examples in non-x86!). |
|||
|
19 Jun 2014, 06:33 |
|
|
m3ntal 19 Jun 2014, 06:49
John: Programmers can hide malicious code in runtime examples, too. If you don't trust someone, just don't download or run their code. It's that simple.
|
|||
|
19 Jun 2014, 06:49 |
|
|
evk1 19 Jun 2014, 06:51
m3ntal: I just want to say if we add such feature in FASM then we also have to add directives for creating directories, checking directory existence, checking file existence and maybe even for listing and removing directories. The idea is good, but as you can see there are many questions about implementation.
_________________ Sorry for my English Last edited by evk1 on 19 Jun 2014, 07:02; edited 1 time in total |
|||
|
19 Jun 2014, 06:51 |
|
|
Tomasz Grysztar 19 Jun 2014, 06:59
A similar feature was requested on several occasions, for a various reasons. At the time when there was variant of LOAD directive that could load directly from files, it was suggested that there should be analogous STORE feature. For the most of the time it did not appeal to me, but I think it could be nice to be able to track the contents of some virtual blocks.
The security concerns are valid (it reminds me of the time when someone did make a web-based fasm feature and I pointed out to him that I could assemble something like "file '/etc/passwd'"), but I think this could be remedied by requiring this feature to be explicitly enabled with a command line switch. As for the checking for file existence, creating directories, etc. - no, I don't think any of this would be good idea, that's what the batch/script/make files are for. What appeals to me in this feature is not the ability to mess with file system, but the ability to store some additional information beside the main output format. The DISPLAY is there for this purpose, but ability to create supplementary files could sometimes make one's life easier. |
|||
|
19 Jun 2014, 06:59 |
|
|
Tomasz Grysztar 19 Jun 2014, 07:03
evk1 wrote: It can be a good idea. But what about saving files to another folders? |
|||
|
19 Jun 2014, 07:03 |
|
|
l_inc 19 Jun 2014, 10:21
Tomasz Grysztar
Quote: but I think this could be remedied by requiring this feature to be explicitly enabled with a command line switch This goes the direction, when one needs to try some command line arguments in order to find out, how a source should be compiled. I.e. the reason behind the emergence of the SSSO principle would become invalidated. As an alternative I'd rather suggest to define a specific folder using an environment variable (similar to Include), the value of which is allowed to be the only destination of such stores. If the variable is not defined, then current folder is used. No path (not even relative path) arguments should be allowed to be passed to such new stores. Quote: ability to create supplementary files could sometimes make one's life easier I definitely remember requests that could be gratified by this. Like automatic build number incrementation. Or randomization of the generated code between different compilations: %t is a way to go, but this topic's suggestion would allow to implement a real PRNG. Still not sure, if this is a good idea. Anyway if you're going to implement this, there are a number of things to consider. The current way of the output generation is a multipass convergence against a solution satisfying a number of declarative constraints imposed by the source code. The new store directive is rather an imperative construct making the compiler create a file, which makes it quite different to what the normal compilation output is. Considering the above I see the implementation as creating an in-memory copy of an addressing space in question each time the new store directive is encountered. A pass failure or the whole compilation failure discards all the copies created this way, so that no files are created. The files must be created in-order, so that an order of multiple stores to the same file is defined. Another question is whether the load or even include accesses should be redirected to the in-memory copies as well as how to tell these directives to read from the new store destination directory. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
19 Jun 2014, 10:21 |
|
|
m3ntal 19 Jun 2014, 15:05
I respect Tomasz's opinions.
evk: I knew they wouldn't go for that. If there was a preprocessor language that supports file I/O, it'd have to use a unique prefix such as ? on all directives to prevent conflict with runtime names: ?open, ?create, ?write, ?exists, etc. Multi-pass would make it hard to implement these features. Remember, we can make our own assemblers, too, and edited versions of FASM. l_inc: Quote: No path (not even relative path) arguments should be allowed to be passed to such new stores. Quote: those are rather tasks for some scripting languages... |
|||
|
19 Jun 2014, 15:05 |
|
|
Tomasz Grysztar 19 Jun 2014, 15:36
l_inc wrote: This goes the direction, when one needs to try some command line arguments in order to find out, how a source should be compiled. I.e. the reason behind the emergence of the SSSO principle would become invalidated. As for the command line option, I thought that it could just make this STORE variant do nothing, like when you redirect DISPLAY output to nul. |
|||
|
19 Jun 2014, 15:36 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|