Hi folks,
I was just thinking that it would be nice if a we had a simple naming rule for 16 bit functions:
"A function is 16 bit if and only if it's name ends in 16."
This way, we can have more reliable tools for detecting 32-16 bit cross calls (unfortunately, winapi_check fails in many instances for this check).
Most 16 bit functions already adhere to this naming convention, but there are still a few that don't. Alexandre, would renaming such functions be acceptable? If so, I can add yet another janitorial task...
"Dimitrie O. Paun" dpaun@rogers.com writes:
Most 16 bit functions already adhere to this naming convention, but there are still a few that don't. Alexandre, would renaming such functions be acceptable? If so, I can add yet another janitorial task...
I don't know, I guess that depends how many need to be changed. Do you have a list? In any case, note that we don't have to rely on winapi_check for that; 16-bit functions should be split to separate files so that we can have --disable-win16 do the right thing, and then cross calls will be found by the linker.
On March 14, 2003 11:26 am, Alexandre Julliard wrote:
I don't know, I guess that depends how many need to be changed. Do you have a list?
No, I'm afraid I don't. In particular, I noticed that the functions in loader/ne/*.c don't have the 16 prefix, even if most/all of them are 16 bit functions, AFAICS.
16-bit functions should be split to separate files so that we can have --disable-win16 do the right thing, and then cross calls will be found by the linker.
Right -- but how do we make sure we've split all 16-bit functions to their own files? Once they are in the 16-bit only files (do we have a consistent naming convention for those, so we know they are 16-bit?), there's not that much benefit in renaming them, I agree.
I guess what I'm saying is that if we had these rules: Function names end in 16 IFF they are 16bit functions File names end in 16 IFF they get compiled out by --disable-win16 It makes it so much easier to spot problems by just scanning the code, not to speak of the simplicity that it brings to any analysis tool.
"Dimitrie O. Paun" dpaun@rogers.com writes:
No, I'm afraid I don't. In particular, I noticed that the functions in loader/ne/*.c don't have the 16 prefix, even if most/all of them are 16 bit functions, AFAICS.
Ah, so you want to change internal functions too? I don't think I agree with that.
I guess what I'm saying is that if we had these rules: Function names end in 16 IFF they are 16bit functions File names end in 16 IFF they get compiled out by --disable-win16 It makes it so much easier to spot problems by just scanning the code, not to speak of the simplicity that it brings to any analysis tool.
I don't think uglifying the function names just to make the tool easier is a good trade-off. There are ways of doing the analysis by using the linker, and that's much better than an approach based on function names.