Index
> Compiler Internals > Problems with labels in 1.71.08 and 1.71.09 beta releases.Goto page Previous 1, 2 |
| Author |
|
|
l_inc 03 Apr 2013, 14:33
revolution
Again, the point is not to find a solution for this particular case, but to give a notion of general guidelines for writing safe headers and macros. It is generally not good to define a global label in a general-purpose header. It is generally not good to allow a macro to be called outside of it's intended context such as this one: Code: .else mov eax,1 .endif It is generally not good to define a non-unique symbol inside of a header, which is not a part of the header's interface, such as defargs@proc (even considering the "@proc" notation). All this produces side effects, which at some point result in complicated problems similar to this one. _________________ Faith is a superposition of knowledge and fallacy |
|||
03 Apr 2013, 14:33 |
|
|
l_inc 03 Apr 2013, 15:19
Tomasz Grysztar
Quote: I think it is quite to the contrary - the usual function of a header file is to define some global symbols. First of all, there's a crucial difference between the term "symbol" and the term "label". Secondly, the key point is here the header's file interface, i.e. all the features the header file provides to it's user. If the purpose of the header file is to define global labels, it should define labels. But in the context of the cited statement such headers are not considered to be general-purpose. As I previously said, macros should generally avoid using anonymous labels, but this is obviously not applicable to this macro, as defining an anonymous label is it's exact functionality. Thirdly, I suppose, we need to define the term "header file" in the context of fasm. The header files in fasm are used to be the files with the extension inc. How many of those are intended to define global labels without invocation of their macros? Thus I'd define a header file as a file, that produces no output (into the resulting compiled executable) as a standalone compilation unit. Therefore I still insist, that header files generally should not define non-unique global labels, whereby it's obviously not a problem to define a macro (as a part of the header's interface), which in turn does define global labels, such as the import macro, but only if this is it's intended functionality. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
03 Apr 2013, 15:19 |
|
|
Tomasz Grysztar 03 Apr 2013, 15:59
l_inc wrote: Tomasz Grysztar l_inc wrote: The header files in fasm are used to be the files with the extension inc. l_inc wrote: How many of those are intended to define global labels without invocation of their macros? I would say that header, by its name, is something that needs to be included before the actual program/data. Thus the encoding includes in their new version are a more general kind of include rather than simply a header, because now they can be included from anywhere, and any number of times. |
|||
|
03 Apr 2013, 15:59 |
|
|
l_inc 03 Apr 2013, 17:03
Tomasz Grysztar
Quote: Yes, the term "label" is specific to assembly language, and what I stated about headers is a bit more general. There are labels in different languages such as in C. But my statements here are all related to fasm only. Quote: The .INC extension is a generic one for an include file, which may be defined as a file that cannot be assembled by itself, but needs to be included in a actual project The fasm documentation mentions only .inc-files as headers. And there's no problem to include .asm-files, which implies, that any (includable) file is an include file as soon as it's included. Thus I always thought, that "macro packages" are also headers. Code: Well, the most standard header (not a macro package) would define some function imports (like with EXTRN directive) What do you mean under "would"? If we are still talking about fasm, then there are no examples of standard fasm headers, that directly expose labels to external symbols, unless a corresponding macro is invoked? The standard fasm headers are just macro packages. If we were talking about C headers or macrodefinitions, I would definitely suggest completely different guidelines and also use different terminology. Quote: and data structures Data structures are a completely different thing in fasm, as those are simulated with macros and therefore do not produce side effects per se. If global labels were not producing side effects, I also would never suggest to avoid including global labels into header files. Quote: I would say that header, by its name, is something that needs to be included before the actual program/data. The terminology does not necessarily have to retain it's etymological meaning, even though this is mostly desirable. The problem with your definition is that due to the fasm's features, what actually has to be included before are the macro packages, because preprocessor symbols cannot be forward-referenced as opposed to the labels. Therefore the usual meaning of headers (where you forward-declare labels, because you can't forward-reference those) is not well applicable to fasm. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
03 Apr 2013, 17:03 |
|
|
Tomasz Grysztar 03 Apr 2013, 17:15
l_inc wrote: What do you mean under "would"? If we are still talking about fasm, then there are no examples of standard fasm headers, that directly expose labels to external symbols, unless a corresponding macro is invoked? With headers for direct executable output it became more problematic, since in fasm you have then to build import table yourself. But that's just a specific case. l_inc wrote: Data structures are a completely different thing in fasm, as those are simulated with macros and therefore do not produce side effects per se. |
|||
|
03 Apr 2013, 17:15 |
|
|
l_inc 03 Apr 2013, 18:09
Tomasz Grysztar
Quote: They have the same kind of side effect, because "struct" macro defines global labels (the structure field offsets). Oh. Sorry. My bad. This makes my argumentation invalid, as using current fasm's feature set the struct-related side effects are unavoidable without a trade-off. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
03 Apr 2013, 18:09 |
|
|
hopcode 04 Apr 2013, 16:39
well,well,well, i was so curious eh eh eh
the input:: is only in the utf8.inc. all other *.inc there, the macros and the manual too are yet free from that javadoc-feature! 1) the utf-8 du redefine should not output utf-16, in all cases, whether having Windows OS or not; whether having an utf-8 text editor or not. reasons are not only for the difficoulty it hides on place. example in the attached img you are warned,developers 
2) switching encoding may be solved in design mode (considering global labels, as sugested aboveetc). or alternatively, all the ENCODE\encodings macros in the .inc may be enabled/disabled/reenabled at preprocessing time. advantage is they all already redefine du. anyway, it is not needed getting rid of the javastyle-feature input:: Cheers, 
_________________ ⠓⠕⠏⠉⠕⠙⠑ |
||||||||||
|
04 Apr 2013, 16:39 |
|
|||||||||
|
l_inc 05 Apr 2013, 23:08
Tomasz Grysztar
I see, that you're still using non-unique non-interface symbols, i.e. __encoding . How about the following situation? I'm declaring some strings using one of the custom encodings and wanna restore the original encoding after that. As long as du is an interface symbol of the header, I'm going to do purge du + restruc du . But with your implementation this is not enough and I also should do restore __encoding . But (!) as a user of the headers I should not be aware of __encoding as it's not an interface symbol, i.e. it's not meant to be accessed by the user. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
05 Apr 2013, 23:08 |
|
|
Tomasz Grysztar 05 Apr 2013, 23:29
You have no reason to know that all it does is redefining du - it affects all the other Win32 macros and how it does it is not stated. To switch encoding again you need to include another encoding file. You should know how are you going to encode the part of text that follows, of course.
|
|||
|
05 Apr 2013, 23:29 |
|
|
l_inc 06 Apr 2013, 00:02
Tomasz Grysztar
Quote: how it does it is not stated Seems like an artificial introduction of lack of feature.  "It is there, but don't use it".
Quote: You should know how are you going to encode the part of text that follows, of course. Which is kinda problem in some situations, because in most cases I'd like to cleanup after myself, rather than to define a new environment. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
06 Apr 2013, 00:02 |
|
|
Tomasz Grysztar 06 Apr 2013, 09:28
l_inc wrote: Tomasz Grysztar l_inc wrote:
|
|||
|
06 Apr 2013, 09:28 |
|
|
l_inc 06 Apr 2013, 13:44
Tomasz Grysztar
I completely agree with all you say. Except probably the following statement: Quote: The "TCHAR" or resource macros could work in a different way and not use "du" at all. TCHAR does not belong to the interface of the encoding files. Thus it either uses the only public interface du, or implements it's own translation, which would be a really bad idea, as it would highly reduce usefulness of the encoding headers. Same is true for the resource headers. The overall point is that I just don't understand why you prefer Code: rept 1 { local ..encoding __encoding equ ..encoding } more than Code: rept 1 { local ..encoding ;here the [i]virtual[/i] block and the [i]du[/i] redefinition macro } In the latter case you can avoid declaration of an additional symbolic constant. Furthermore this constant can potentially correlate with symbols from other (e.g. user defined) headers. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
06 Apr 2013, 13:44 |
|
|
Tomasz Grysztar 06 Apr 2013, 15:45
l_inc wrote: TCHAR does not belong to the interface of the encoding files. l_inc wrote: In the latter case you can avoid declaration of an additional symbolic constant. Furthermore this constant can potentially correlate with symbols from other (e.g. user defined) headers. |
|||
|
06 Apr 2013, 15:45 |
|
|
l_inc 06 Apr 2013, 16:08
Tomasz Grysztar
Quote: I had not intention to make them a separate and independent being. That's OK. But this does not necessarily prevent you from applying generally appreciated concepts such as modularization and intermodular interface simplicity and clarity. Quote: It is not a new thing for my macros to keep some settings in a global symbolic variable Yes. And I hoped, you'll find it worth to reconsider this approach in favor of minimization of side effects. Quote: like prologue@proc prologue@proc is a different thing, because it's a part of the customization interface of the procedure macros. Quote: but I like it this way Unbeatable argumentation. But nevertheless it's a valid argument._________________ Faith is a superposition of knowledge and fallacy |
|||
|
06 Apr 2013, 16:08 |
|
|
hopcode 07 Apr 2013, 14:08
and last but not least, the fact that up to 0x10000 - 1 converts simply to 2-byte scalar value doesnt offer any useful opportunity
but planning mess. one should work always on the input string considering eventually the output as "at-the-last-stage". virtual,virtual,virtual prerpocessing, then the last stage, presumably the assembling one, you may think to output what you like: scalar/utf-16/utf-8 etc. but fasm should be aware of that scalarizing virtual system. yet better if that system could be embedded in fasm. you are not able at the moment even to change encoding in the case you work on an already encoded evaluated stream, and yet more problems arises obviously when the scalar goes beyond plane 0, when touching the output of one of those macro, as i showed above. neither renaming "utf8.inc" to "input_utf8_to_scalar" would be designedly-speaking correct. solution is to keep du-output always virtual. tchar doesent matter. it may be an envelop to du follows that those "encodings" should not be designed as "for Windows", as Tomasz said above "heck, two digits are enough.. It's not as if anyone is gonna care" said Grace Hopper when planning the Y2K bug. sorry cannot resist  , i must post the photo of the bug ..ehhm of the Admiral... with goood intentions ehh,
Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
07 Apr 2013, 14:08 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|