We help IT Professionals succeed at work.

$X+

dryzone
dryzone asked
on
Medium Priority
273 Views
Last Modified: 2010-04-16
Does anybody know or have any experience about whether
extended syntax {$X+} is "Dangerous" in BP6/7.

I have a program which presents serious problems.
My suspicion is that extended syntax might be the culprit since allows you to do the following.

As a result of the use of this directive, the programmer used Functions throughout even as procedures, thereby completely eliminating the need for procedures as per the following example.

Example of using a function as a procedure without allocating the
returned value to a fixed variable, but leaving it on the stack and allowing it to compile with "Exstended Syntax".

FUNCTION f(x:integer;y:integer,z) :bolean;
begin
f:=TRUE;
end;

begin
f;
end;


The program is a mission-crytical program and needs to run forever until hardware breaks - well it does not.
Unfortunately the program outputs garbage after a while. This happens on different hardware too.
The program receives and displays the correct data received, but outputs trash compared to the expected converted value through a lookup table.

The winner to this question will be the first person to deliver proof (preferably with reference to article or any publication or program example), that this directive can e.g. make the stack grow into variable space and cause this behaviour.

Otherwise prove that it is a flawless directive.

The program is compiled with BP7 on DRDos.

 I will allocate the points but will withdraw after some time if no conclusive evidence for or against can be given.

Thank You.
Comment
Watch Question

dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.
CERTIFIED EXPERT

Commented:
From the Turbo Pascal manual

The $X compiler directive enables or disables Turbo Pascal's extended syntax.  In the {$X+} mode, function calls can be uses as statements; that is, the results of a function call can be discarded.  Generally, the computations performed by a function are represented by it's results, so discarding the result makes little sense.  However, in certain cases a function can carry out multiple operations based on its parameters, and some of those cases may not produce a sensible result-in such cases, the {$X+} extensions allow the function to be treated as a procedure.


Now why did the programmer use this syntax? I would take him or her  out the back and use a good baseball bat.

 I'll also bet he/her turned off range checking and stack overlfow checking as well.  These are the R and S switches.  If you suspect stack overlfow happening then recompile with the stack overlfow checking set.  This is

$S+

and that should answer your question.



Quid, Me Anxius Sum?  Illegitimi non carborundum.
CERTIFIED EXPERT
Commented:
And did they use recursion in the program?  Or fix the stack at a low leve?

Author

Commented:
Thanks, dbrunton. I will evaluate once I have a couple of answers. The fact is the program does all strange things. Rediculously strange. I know that if you use $X+ then the function is allowed to evaluate as above, but that the return value is still left in the accumulattor AX and DX registers. I just wondered if there isnt a way that by using $X+ and thereby leaving results in accumulator, that you may influence subsequent instructions using AX and DX, eg pointers which uses DX. That will bve a mess but I need proof. According to standard Pascal this is sloppy programming as far as I am concerned.  

Commented:
Well, I haven't programmed TP/BP itself, but I believe to have vast knowledge of the code generated. Also, I have the source code of the TP6 compiler just in case.

The compiler does not do any register optimizations as far as accumulators are concerned (there are some pointers which are kept stored in ES:DI when using the WITH clause, but that's another topic). None of the four ?X registers are reserved for compiler or internal use.

As you already know, functions return their values in AL, AX or DX:AX (depending on their size); no difference is made on the stack. The code generated for a procedure call terminates after the CALL statement (in difference to function calls where the return value is stored or used in computations). Since we know that the compiler does not assume anything for the register content when compiling the next line of code we can be sure that calling a function as procedure does not influence the computation later-on.

I rather think that you have some array or index over-/underruns, invalid pointers, overwritten memory, false computations, stack corruption or some other problems. I have intensively use the extended syntax for many years and I never ran into problems when using it, and I believe that looking for a problem related to this is wasting your time.
where did you get the source of tp6 ???? (btw:hello again...)

Commented:
I stubled across it on the net once... ;-)
My name is MudSystems Engineer

Commented:
>>Now why did the programmer use this syntax?
>>I'll also bet he/her turned off range checking and stack overlfow checking as well.

You don't... actually you do it, after debug and ready for action, to reduce disk space... But what's the worry on a homework???

Author

Commented:
This is not homework......
This is used by one of the most foremost programmers in the
US.
This is used in a mission crytical situation. Please view it as such.
dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.
CERTIFIED EXPERT

Commented:
Unless a programmer is 100% certain the code won't crash for any conceiveabe or inconceiveable chance he/she should never turn off the checking.  Just in case.

The problem is to prove that he /she has covered all conceiveable/inconceiveable chances.

Author

Commented:
I agree with dbrunton.
My problem is that the code has a long cycle of operation when used. So bugs sometimes surfaces after a month, but is clearly proven to be software. The problem is that it costs about $5000 to fly out to the site every time the code presents problems, furthermore the customer loses $40 000 every time the program slips up and boy does it slip up. As an example it plots the correct values on it's own GUI, but then it should just do a basic lookup and display the looked up values. The values caculated and displayed by the program is horrendously wrong and does not correspond to the lookup. Programmer says it is "hardware or bios". I dont agree it fails on different hardware etc. My take on it is that since the programmer do not care about using functions when procedures should be used in such a crytical program makes me wonder if the extended options were ever fully debugged. It was introduced in BP6 and 7. Several of the other Pascal dialects calls it "Dangerous".
I was hoping that someone had absolute proof for or against the dangers of using extended options, as I do not see any other possible culprit.

Commented:
Extended options are not dangerous in a technical matter, but rather in the fact that they loosen up the strong rules of standard pascal to some extent and thus allow the programmer to do things (maybe unintentionally) which would not have been accepted by the compiler otherwise.
My name is MudSystems Engineer

Commented:
I don't care what you say... hey I even turn off my PC and still got my programs to work... :P

Author

Commented:
Were not getting anywhere, so I will part with the points.
The information I gathered was that Extended options are not standard pascal and is viewed as dangerous by e.g. gnu.
Michael Tischer also prescribes its use as to introduce C-routines normally not present in pascal.
It is therefore in the Pascal-sense a dangerous venture.

Anyway I give the points to dbrunton although my question was not really answered with an example.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.