I'm trying to put together C code from some decompiled assembly code and have a question. I see the following:
SUB_L10195A01:
...
call SUB_L1019CB90
db CCh; 'Œ'
SUB_L10026990:
push FFFFFFFFh
push L101EA0C5
What is the
db CCh; 'Œ'
for? Normally there is a
retn
before
SUB_L10026990:
db is commonly used by assemblers to specify arbitrary bytes added in the middle of "regular" assembly, and disassemblers insert it as a "tool of last resort" when they start seeing sequences that make no sense at all; here I don't know why your disassembler inserted the cc byte in a db, as cc is the usual int 3 opcode (which is commonly used to break into the debugger).
Compilers often emit them around "regular" functions for padding/alignment/debugging purposes; int 3 has the advantage of being easy to spot when looking at both disassembly and hex memory view, and breaking into the debugger if it's accidentally executed. The fact that you find it after a call means that that call is meant never to be returned from (think exit(1) or abort() or something like that); alternatively (but less probably), it may have been added purposely by the programmer (e.g. in form of the __debugbreak intrinsic in Visual C++).
It is 'for' nothing. The compiler assumes that the called function will never return.
Also, your disassembler is aware of this. The code 0CCh decodes as int 3, which will usually halt your program and display an error. Since the code before it will never return (or so it is assumed), the opcode is not part of the listing and so it is written as db 0CCh rather than "the instruction int 3".
The code itself has nothing to do with the routine above it. The compiler inserted this byte to ensure that (1) if a program runs out of bounds, it'll come across this command and then halt, and (2) to align the first byte of the next function to (most likely) a multiple of 4, so there is a small - but real - gain in execution speed.
