Delphi $IFDEF WIN32 falls through to $ELSE

Question

A project I'm working on has a unit, xprocs.pas that has an {$IFDEF}/{$ELSE} block that's acting up. It was building fine and ran without issue yesterday... This morning however, it's throwing an exception with a range check error. The block of code where the error is thrown is proceeded by {$IFDEF WIN32}, but isn't acting as expected.

If I comment the {$IFDEF} block and attempt to only run the line directly following it, it doesn't respect the comment, and runs it anyway. Also the IDE allows me to place a break point on the code that's commented out.

I've deleted the DCU file thinking it was using an old version, but with no effect.

Any suggestions?

const
  C1 = 52845;
  C2 = 22719;

function strEncrypt(const S: String; Key: Word): String;
var
  I: Integer;
begin
 {$IFDEF Win32}
  SetLength(Result,Length(S));
 {$ELSE}
   Result[0]:=Chr(Length(S));
 {$ENDIF}
  for I := 1 to Length(S) do begin
    Result[I] := Char(Ord(S[I]) xor (Key shr 8));
    Key := (Ord(Result[I]) + Key) * C1 + C2;
  end;
end;

You've got a different version of either the .pas or .dcu on your system, and the code you're seeing isn't what the compiler is seeing. Search your system for other copies (not just the one you know about). — Ken White, Mar 14 '17 at 16:24
@Ken There were a few other copies of the .dcu, which I deleted. The `xprocs.pas` file matched the one I have in source control (dated from 2010), except for the comments I added. I didn't have the file checked out so I replaced it with the copy from there. I then did Project > Build All Projects with no affect. http://imgur.com/vEKHOB8 — fourwhey, Mar 14 '17 at 16:40
Please don't post a screenshot of your code. Just paste your code. Stack Overflow does an excellent job of syntax highlighting. — Jerry Dodge, Mar 14 '17 at 16:43
@Jerry I wanted to highlight the breakpoint situation. I'll add the code too. — fourwhey, Mar 14 '17 at 16:44
Another option is that you copied/pasted some code from another file (a web page, for instance) that doesn't have a proper CR/LF line ending. Close the file in the IDE, open it in Notepad, make a minor change (add a blank line and then delete it, for instance) and save the file. Then reopen it in Delphi. Does the problem still exist? — Ken White, Mar 14 '17 at 16:47
@Jerry: In this case, the image was fine. Posting the code would not have shown the breakpoints still being valid on a commented pair of lines. — Ken White, Mar 14 '17 at 16:47
@Ken This file is quite old, and hasn't been modified in some time. I did as you suggested and added CR/LF to the end of it. It doesn't appear to have made a difference though. — fourwhey, Mar 14 '17 at 16:54
@David No, I don't. This is an old lib the project uses, dated from 1999. The IDE crashed this morning and I rebooted. Now this. — fourwhey, Mar 14 '17 at 16:56
It's as everyone says. Something else is being used. We can't really track it down from here. — David Heffernan, Mar 14 '17 at 17:03
@Ken I've deleted all instances of the dcu, and have only one pas file http://imgur.com/XpzFh92, which is why this has me stumped. I'm seeing errors in coreide70.bpl since this morning and again a moment ago. Could this possibly be linked to the issue? — fourwhey, Mar 14 '17 at 17:16
I see, although I understood the problem description without the screenshot. I didn't even realize that was the purpose of the screenshot. — Jerry Dodge, Mar 14 '17 at 18:50
"I'm seeing errors in coreide70.bpl since this morning " Did they persist across a reboot of your machine? — MartynA, Mar 14 '17 at 18:59
Well, if you can put a breakpoint on a line which is commented out in your file, clearly the compiler is ignoring your source file for some reason and thinks it does not need to include it when it does a compile or build. — MartynA, Mar 14 '17 at 19:11
The code you happily grabbed from the internets dated 31.07.96, LOL. — Free Consulting, Mar 14 '17 at 21:07
Try explicitly adding the file to your project. You may get an error which might clarify the problem. Or you'll be certain the file your viewing is the one you're using. — Disillusioned, Mar 15 '17 at 00:52
Possible duplicate: http://stackoverflow.com/q/6609898/224704 alternatively http://stackoverflow.com/q/2603077/224704 — Disillusioned, Mar 15 '17 at 00:56
Which Delphi version are we talking about here? The Win32 cond. define was introduced with Delphi 7 IIRC, so if yours is older than that that might explain it. — dummzeuch, Mar 15 '17 at 13:29
@dummzeuch This is Delphi 7, but I think the condition is from earlier than that. — fourwhey, Mar 15 '17 at 16:32
@FreeConsulting The code is quite old, but I didn't copy it. The project has been using it for years and working without issue. The method in question hasn't changed for as long as I've worked on it (several years) and it's worked fine. — fourwhey, Mar 15 '17 at 16:33
@dummzeuch, platform symbols always been there, particularly `WIN32` since D2, come on. — Free Consulting, Mar 15 '17 at 17:58
@FreeConsulting your memory apparently is much better than mine. — dummzeuch, Mar 16 '17 at 08:05

score 0 · Accepted Answer · answered Mar 17 '17 at 13:04

0

The issue ended up being a corrupt project file, "ProjectName.dof". I deleted it and copied over the compiler settings and search path from the old one manually.

answered Mar 17 '17 at 13:04

fourwhey

490
4
19

I venture to suggest that "corrupt" is not the correct word. More likely it loaded a different version of the file into the IDE to the one used for compilation. Comments on the question said as much, and there are a few duplicates on the site about this. – Disillusioned Mar 19 '17 at 08:02
@CraigYoung There were suggestions about duplicate dcu files or line end issues in the pas causing breakpoint offset. The main issue I was having was the range check error (which was deceptive imo b/c the string index wasn't out of range) when a var assignment overflowed the type. In the code above, `Key: Word` when its assignment >65535 it caused a range check. Replacing the dof file fixed it temporarily, but ultimately I explicitly cast the value `Key := Integer((Ord(Result[I]) + Key) * C1 + C2);` and it stopped. It's happened elsewhere too. Honestly, I'm not exactly sure why either. – fourwhey Mar 22 '17 at 15:38
The code in your question ***was not*** the code producing your range-check error. It's extremely obvious to someone very familiar with certain aspects of Delphi: _a break-point on a commented out line means compiled code and code in editor are out of synch_. This has to be resolved ***first*** before you can make any rational decision to progress on the range-check error. If you're still having a problem in that regard, a new question would be appropriate. – Disillusioned Mar 23 '17 at 02:07

Delphi $IFDEF WIN32 falls through to $ELSE

1 Answers1