With so many points, you really should have posted this as separate questions (maybe not four questions, but having radically different questions stuffed in one post is a bad idea)
Point 1:
See Pending approvals: allow for adding reasons to rejections
It is possible, but the reviewer doesn't have to. Your edit fitted a run-of-the-mill rejection reason, there was no need for anything special for it.
Point 2:
In both cases, you are adding a sizeable chunk of content to the post. Normally, you may not want to do that--a few fixes (small clarifications here and there, formatting, linking, grammar) are good- but adding a whole chunk of content is frowned upon.
Instead, you comment on the post and ask the user to incorporate a bit about XYZ into it--this is what comments are for.
I, personally, rarely make such edits to posts (even with editing privileges), unless I've interacted with the person well enough to know that s/he won't mind (and I let them know via a comment--though now, due to the new notification system, this isn't strictly necessary)
Edited by @AmitMittal:
@C.Evenhuis is largely correct
Unmanaged dlls can not be loaded through Assembly Resolve event (it will not be fired for unmanaged dlls). For this at start-up (or at-least before the point where you are sure that the application will not have tried to load the unmanaged dll) you need to write the unmanaged dll to a disk file.
Location of the dll should either be in the Environment PATH variable or the location from where your application is running.
Best way to look for the locations where OS tries to search the dll is using sysinternal's ProcMon by monitoring the file read/write activity of the application's process.
This obviously belongs as a comment. If your comment is becoming too long, you can use multiple comments or move to chat. Finally, the poster can edit the clarifications in (or you can ask him to approve your edit, one can approve edits to one's own post even without 5k rep)
In fact if all funtions are inlined paging activity can increase dramatically and hence decrease performance as opposed to increase it.
As part of jump to the function instructions, compiler also generates code so that any arguments required by the function can be passed to it (for this read on Calling conventions). Called function will have its own stack frame (placed on top of the calling functions stack frame in the processor's stack) to store its local variables. Once the called function returns this stack frame will be destroyed (i.e. called function's local variables will go out of scope).
This is a whole new bit of content, and not just a clarification. Again, it is better if you suggested the poster to add this (or asked for permission and added it yourself)
Point 3:
Generally, for closed questions, it is better to edit the question so that it is up to scratch and flag for reopening. There is nothing wrong about editing the answer, but fixing the question first is much more useful to the site. Usually, if someone has managed to answer a question that is hard to understand, that means that they have managed to interpret it. Usually, reading the answer helps you understand the question better, and you can fix this.
Unfortunately, the question you linked to probably was closed as "too broad", not "hard to understand"--since "compiler" is a generic term, and different compilers work differently. Again, there is no issue in improving the answer--but not much point doing so.
Point 4
Note that there is a larger faq here.
There are a lot of things that should be in the faq--we don't want it to be overwhelming. I personally think that a better idea would be this:
- Notify a user of a rejected edit (dunno if that happens already)
- The boilerplate rejection reasons should link to explanations on meta.
Unfortunately, for this particular issue, not everyone is in agreement on which edits should be rejected. So there is a bit of ambiguity here, and it is better to play it safe with edits of the form I mentioned in point 3 (small clarifications here and there, formatting, linking, grammar
)