call & ret

[sinsi]

Yes, but the stack is only your property above esp, as far as the locals and parameters go. Maybe I am paranoid, thinking about DOS and interrupts  :bdg
With stdcall, a proc kills off the parameters when it returns, but a C proc leaves them there, which could possibly screw something up if the caller expects the parameters it pushed to be unmodified.

[Astro]

Hi,

So sub esp,4 to add space on the stack is ill-advised, or is it that you must not assume things?

Best regards,
Robin.

[donkey]

PS: Don't write ANYTHING to the memory pointed to by ESP or it may come back to bite you.

Are you suggesting that nobody should use the PUSH instruction ? Or just not use things like mov DWORD PTR [esp],4, both of which are essential to assembly language programming, one allows the calling of procedures and the other the use of LOCAL data. Whether you allow the assembler to do it or do it yourself the resulting code is the same. I think you should qualify that statement with "unless you know what you're doing" but that can be said about anything in programming.

Edgar

[Slugsnack]

PS: Don't write ANYTHING to the memory pointed to by ESP or it may come back to bite you.

Are you suggesting that nobody should use the PUSH instruction ? Or just not use things like mov DWORD PTR [esp],4, both of which are essential to assembly language programming, one allows the calling of procedures and the other the use of LOCAL data. Whether you allow the assembler to do it or do it yourself the resulting code is the same. I think you should qualify that statement with "unless you know what you're doing" but that can be said about anything in programming.

Edgar

I assume he means at the start of a procedure in which case you'd be overwriting the return address.

[donkey]

I assume he means at the start of a procedure in which case you'd be overwriting the return address.

Hence the "unless you know what you're doing".

[Astro]

I think the problem is when you assume that you can just write somewhere without checking what is actually there first. Obviously you can't, at any time.

Something that seems to be fairly common is people losing sight of what they're trying to do, and where they're trying to do it.

Does anyone *design* software anymore? It seems to me a lot of problems can be avoided if just a little bit more care was taken at the start.

Best regards,
Robin.

[Slugsnack]

I think the problem is when you assume that you can just write somewhere without checking what is actually there first. Obviously you can't, at any time.

Something that seems to be fairly common is people losing sight of what they're trying to do, and where they're trying to do it.

Does anyone *design* software anymore? It seems to me a lot of problems can be avoided if just a little bit more care was taken at the start.

Best regards,
Robin.

You know you shouldn't really categorise careless mistakes based on a lack of knowledge and understanding with software 'design'. I doubt much of the software you have developed has ever been 'designed' as such if you're looking at it from a professional software dev POV. Taking a simple case, how many design patterns have you intentionally planned for and used in the past during development ?

[donkey]

Does anyone *design* software anymore? It seems to me a lot of problems can be avoided if just a little bit more care was taken at the start.

I usually have an idea, most of which is only vaguely formed, and then start coding it. A lot of what I originally wanted is normally impossible or beyond my capabilities so compromises are made and the final product barely resembles the original idea but a lot of the time it turns out much better. Not being a professional programmer and having no educational background in computers I have no idea how to do a flow chart and when I start a project have very little knowledge of the algorithms I will need. So no, I have never really *designed* any software.

[Astro]

You know you shouldn't really categorise careless mistakes based on a lack of knowledge and understanding with software 'design'.

I'm not, but it does seem to me that a good many software bugs could be mitigated if someone spent 5 minutes making a few notes.

The PRNG flaw in Debian is an example of where an ill-considered code change was made in critical code that broke the back of the security of it. Had someone made some notes regarding that section of code, the change wouldn't have been made.

http://digitaloffense.net/tools/debian-openssl/

Best regards,
Robin.

[hutch--]

I would have to agree with Robin here, its a classic case of "can't see the woods for the trees". While over time I have seen many projects of different sizes built in many different ways, the ones that rarely ever make a mistake are those that have a clear overview of what they are doing and if code is delegated over a wide number of people you can get this compartmentalisation that does not know what the rest are supposed to be doing. At least with something like Debian they can react and fix it quickly enough.

Its a bit to do with how certain projects are done, top down designs get the overview and the framework done early in the scene where bottom up techniques often get excellent detail with a lousy overview. Small developers usually win on the overview where large collections usually win in terms of detail.