2

This is a bit of a follow-on question, related to an answer I saw on another question I was reading on stackoverflow. If I wish to disable overflow-checking for a specific function (per this question), will this code cause the overflow-checking to suddenly become enabled after running the function, even if it wasn't previously enabled in compiler options or code?

{$OVERFLOWCHECKS OFF}
// function here
{$OVERFLOWCHECKS ON}

Do I need to combine this with an IFOPT block (akin to this example perhaps?) to return the overflow-checking to the previous state (so as to not accidentally enable overflow checking on non-debug builds)? Or are the two different, and this be sufficient? Bonus: If I do need IFOPT, what would the specific syntax be for disabling overflow checking conditionally?

Community
  • 1
  • 1
Jessica Brown
  • 8,222
  • 7
  • 46
  • 82
  • Personally I think that code that is overflow-check specific should be unit tested, and hard-coded with {$OVERFLOWCHECKS On/Off} at the TOP of the unit, overriding the project settings explicitly, and then write and test your code so that no project settings will break your unit. – Warren P Jul 26 '12 at 20:04

1 Answers1

14

Yes, the snippet you posted will automatically enable overflow checking regardless of what it was before.

This should work. If you'd prefer, you can replace {$Q+} and {$Q-} with {$OVERFLOWCHECKS ON} and {$OVERFLOWCHECKS OFF} respectively.

{$IFOPT Q+}
  {$DEFINE OVERFLOW_ON}
  {$Q-}
{$ELSE}
  {$UNDEF OVERFLOW_ON}
{$ENDIF}
//
// Your code here
// 
{$IFDEF OVERFLOW_ON}
  {$Q+}
  {$UNDEF OVERFLOW_ON}
{$ENDIF}
Ken White
  • 123,280
  • 14
  • 225
  • 444
  • This looks too complex, since the scope of $Q is local, it looks like with not too large units you'll be OK if just disables/enables the directive, unless you're working on a really complex project with a really complex team. – jachguate Jul 26 '12 at 10:26
  • @jachguate, no, it's not. Turning it off and on affects the code between, but if you leave it on it remains on until something else changes it elsewhere. If you don't specifically turn it off somewhere else afterward, it affects everything else compiled (at least in that unit, and possibly more). Try it. As far as being complex, you can easily build a code template that does it all for you with a couple of keystrokes and a Ctrl+J (or tab or space, if you set up your template that way). – Ken White Jul 26 '12 at 10:57
  • The above technique works, but I don't recommend it to the OP. – Warren P Jul 26 '12 at 20:03
  • @WarrenP, OK. So why are you telling me, then? :-) Sometimes it is necessary to turn things on/off for a procedure (or even a few lines of code), and it's senseless to create a new unit just for that procedure. There's nothing wrong with doing it this way, as long as you're aware of what you're doing. (And I answered the question asked.) – Ken White Jul 26 '12 at 20:18
  • I have needed to do this on a number of occasions, mainly when I am making calls into a library (like LockBox3) that throws exceptions if Overflow and/or Range checking is on. I agree that the above technique is the correct way to do this; however, after you incorporate these directives it is critical that you **build** your code and not just **compile** it or the switching will mysteriously just not work! – Chris Bargh Jul 03 '14 at 07:13