# Should compilers follow the defined language standard?

Why do some compilers violate the defined language standard?

I don't understand, in ISO/IEC 10206:1990 Extended Pascal standard on 6.8.3.2 Arithmetic operators section, Page 86.

It says that,

A term of the form i mod j shall be an error if j is zero or negative ; otherwise, the value of i mod j shall be that value of (i-(k*j)) for integral k such that 0 < = i mod j < j.

But, when I try in free pascal compiler 3.0,

``````writeln(-5 mod 3);
``````

It produces a negative number "-2" instead of "1", and

``````writeln(5 mod -3);
``````

Should be error according to the standard,
but what I found is not.

For example, if there is a question

"In C++, why does the -5 % 3 produce -2 instead of 1, isn't it modulo operator?"

That's because in C++14 standard on Page 124, 5.6 Multiplicative operators, no. 4
It says that "(a/b)*b + a%b is equal to a"
Therefore, it is not a modulo operator, it is a remainder operator

But If there is a question,

"In Pascal, why does the -5 mod 3 produce -2 instead of 1, isn't it modulo operator?"

Should the answer be like this?

In general, it depends on the compilers that you are using, because according to the ISO/IEC 10206:1990 Extended Pascal standard, it should be 1, while on a modern compilers like fpc or gpc,
it produces -2

What would be the most appropriate answer to the modulo operator question above?

• Look at microsoft and JAVA, similar to the Borland comment below. If you intentionally deviate, and you get folks hooked on it, then they can only use your product. Unfortunately Microsoft lost in the end, but it was painfully obvious what they were up to the moment they jumped on the JAVA bandwagon. They won for quite a while though, was probably a win overall. Standards bodies have one motive, implementers another, no reason one has to conform to another, not limited to software, quite often standards are not adhered to, for many reasons. Commented Jul 29, 2016 at 18:20
• Quite often it is because the folks behind the standard are not necessarily working in the interest of the industry using that standard, but instead making a standard for standards sake. Or they are working (see the original floating point spec) to intentionally block out competition or to lock in one vendor. it is like saying websters or the oed are the authority on the english language when in reality they are slaves to it. Commented Jul 29, 2016 at 18:22
• In addition to the already mentioned possibility that compiler builders are a devious lot I would like to suggest another: Hanlon's razor. en.wikipedia.org/wiki/Hanlon%27s_razor Commented Jul 22, 2019 at 11:25
• A lot of standards committee work by essentially documenting existing implementations. Compilers don't wait for the standard to be written before they implemented a feature, but rather standard authors wait until a specific implementation(s) have a track record of being the best solution, and then the standard authors codified that so that all the other implementors can follow and to resolve conflicts when there are already multiple pre-standard implementations (pre-standard implementations often copy each other's works to improve portability, so differences are usually just minor details). Commented Jul 23, 2019 at 3:36
• Standard Pascal is a pain to use. Commented Dec 14, 2020 at 19:14

The point is : what does "error" means in that particular standard. It might be explained in some introduction or glossary. Perhaps it is close to undefined behavior (and the implementation can do whatever is simpler for it). The standard that you are mentioning says:

3.2 Error

A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected.

(the italics emphasis is mine, so the behavior you are observing is conformant to the specification)

Some programming languages specifications mention undefined behavior or unspecified behavior. The (conforming) implementation is then allowed to do whatever is suitable (for undefined behavior it can be really bad things, read Lattner's blog What every C programmer should know about undefined behavior)

Should the compilers follow the the defined language standard?

Some compilers explicitly have (and document) extensions to the languages they are implementing. GCC has useful extensions to C, notably labels as values (with computed `goto`s) and statements exprs, and both are also supported by Clang/LLVM.

(I guess that the reasons why such commonly provided extensions have not been pushed into the standards is for social or economical reasons, not technical ones; contributing to a standard is quite expensive)

• Okay, thank you for your response, `A term of the form i mod j shall be an error **if j is zero or negative**`. I think that this error mentioned by the definition only appropriate if the compiler implement their own ways to handle the error of J value. But, what about I and the Result value, the standard doesn't defined if I and the Result value to be negative, does it also violates? Please correct me if I wrong Commented Jul 26, 2016 at 10:33

Pascal has a long history of non-compliant implementations. This is probably because the peak of the language's popularity occurred between the first standardized version (ANSI Pascal, 1983) and the more recent 'extended' pascal you site (1990) -- during this time period Borland Turbo Pascal was created and became the de facto standard for most Pascal implementations. Borland never really bothered with compliance with the earlier standard; if they felt there was a better way of doing something, they went ahead and did it. Therefore, there is a long list of deviations between Turbo Pascal and the ANSI standard.

The Extended Pascal standard was based on the ANSI standard, but a large proportion of modern Pascal implementations (including Free Pascal) are explicitly designed to be compatible with Turbo Pascal, so deviate from the standard in similar ways.

If you're looking for a more standard compliant compiler, I believe the GNU Pascal Compiler is closer to the standard behaviour (or at least it was when I used it in the mid-90s).

• One shouldn't forget that the TP compiler was in assembler at the time, to get a whole IDE +compiler in a few hundred kb and perform at some speed. That made its implementation somewhat adhoc at times. Note that Free Pascal nowadays does support quite a lot of the '83-'85 standard in ISO mode. Commented Mar 13, 2019 at 17:05
• Turbo Pascal deliberately made some things like string handling much, much easier to use. There was a reason people liked the language (speed alone would not have been enough) Commented Dec 14, 2020 at 21:39

Extended Pascal is hardly implemented by anybody, and is newer than the defacto standards (read: Turbo Pascal) actually implement.

Those compilers chose compatibility with the implementation dialects they implemented (Turbo Pascal 1983) before the standard was formed(1985, 1990 extended pascal). Admittedly, Turbo Pascal, and Delphi are quite often just implementations retrodeclared as compatibility standard.

Partially also because there was no real driving force to adapt the standards, and the standards were not very pragmatic somewhat removed from the major every day dialects used in production. (e.g. why not adopt the Turbo Pascal unitsystem syntax instead of using the more M2 like "module") syntax?

Turbo Pascal was one of the major compilers of the dos era, and the standards ignoring that fact didn't help.

C/C++ is an exception there, because Unix API and software being implemented in it (though even there non Unix C/C++ compilers like BCB and MSVC and embedded C compilers were notoriously slow in adopting the newer standards like e.g. C99. Moreover, Unix apps were much more likely to be distributed in source than in other markets) In reality, few languages have a large number of compilers competing in the same market. And it is exactly that what the C/C++ standards tried to harmonize.