BlitzMax comments

Are comments compiled or not? If so, that would be a security problem. But im like 99% sure they are skipped on compilation. Or am i wrong?

Comments are not compiled.

Strings are compiled, comments are ignored.

Are unused/unreferenced strings compiled?

or are they given to cyber kittens to play with ;)

Yes. You could write 1000 functions and not call any of them, they still get compiled. The compiler/debugger has no clue about whether you are sane ;-)

Why would compiling comments present a security problem?

ImaginaryHuman: Optimising compilers would leave the unused functions out of the final binary ;)

Sanity has nothing to do with it; if you develop (or DL or purchase) a large general purpose library and only use 10% of it's functionality, you wouldn't want the unused functions left in to bloat your executable.

Unless the compiler by default creates .o and interfaces (like BlitzMax). This files can be linked across different binary files. In that case there's no way to know if a function will be used in another compiled file (there are a lot of modules that expose functions that are not used inside the modules).

Well that's the simplistic view. In effect, all the compiler would have to do is to track the usage of each function, and strip down unused functions at the final link stage. That's what some compilers/linkers actually do.

How would the compiler know your function is unused if you use function pointers which can change at runtime?

The idea of optimising DLLs by removing (apparently) unused code is pretty much compromised by reflection. Even if the code in that DLL does not use reflection, it may be loaded and used by something that does.

It is not a simplistic view, it is a realistic view. interfaces don't store internally used function calls so there's no way to determine wheter a function is used or not at link time. In the other hand, there's no way to determine where a .o file will be linked, so no way to do this optimization at compile time. Not to mention that this would break reflection when applied to classes.

ziggy: No way at all to determine? In this day and age? Sure, run-time decisions and functino pointers render this kind of optimisation an impossibility, but not every program uses these features.

It could be an option in the compiler (opt in rather than opt out, obviously).

It could be an option if the BM compiler worked in a very different way. Not with its current architecture, wich, in the other hand, has a lot of incredible well suited compilation optimizations

Quite obviously, from the moment you take the adress of a function and store it in a pointer, that function would be flagged as "used". Global optimization techniques could even go further and be smart enough (in certain limited cases) to figure if the pointer is not used itself (and thus not flag the functino as used), but that's quite demanding already.

I am assuming you're talking about BlitzMax specifically, in its current state. I was talking about the possibilities, not about what the current BlitzMax compiler actually does (hence the term "would").

However, you have a very valid point concerning methods and reflection, as by the time you support reflection you cannot tell statically which ones will be called. The argument still holds for plain functions, though.

Why not create a precompiler?

@Korilis, obvously, I was talking about BlitzMax. Other compilers work quite differently, and obviously if BM changed the way it handles compilation and linking, this could be done and it would be a very good improvement. I was not trying to correct you or the like, just explaining why IMHO this is just not feasible with the current BlitzMax techniques of compilation wich, in the other hand, I think are very well suited. So in general terms, I think we agree.


That's right for non module oriented programs.
Take in consideration that I can have a module wich exposes a function wich is not used in the module itself. This function would have to be compiled and exposed in the interface (becouse it is there to be used by any potentially calling programs).
So when you compile the calling program, the compiler could detect this function is not being called, but it could not delete the function from the already compiled object file, unless this file is somehow compiled again, so compile module then compile exe, then compile again the module, then link... obviously not to mention what could happen when the potentially removed function causes more functions to be unused so then compile module again and again...

I think it could be no-risk done at the first compile time for private functions, and for functions defined on non-module files.

Yes.

But you are assuming that removing a function from an already compiled file is absolutely not doable, which is wrong. The object file is basically the native code + relocation information + symbol information. If you organize the binary code to guarantee that for every function the function's code is contiguous (which is generally the logical thing to do, though not mandatory), and if you also track function length (in terms of bianry code), all you have to do to remove the function code is to shift from N byte all that is "behind", N being the said function's length. In the process, just use the relocation information to patch the moved code and make sure it is still valid. Or even simpler, patch the relocation information itself (just subtract N to every affected entry in the relaction table).
Looking at what I just described, it's quite obvious that the natural move is to just not bother about it. But it's doable, and I believ it is actually done by some compilers/linkers. But I can be mistaken. It's not such a killer feature anyway.

EDIT: found example for the Visual C++ linker:
http://msdn2.microsoft.com/en-us/library/bxwfs976.aspx

Never thought it this way... :D