Is it possible to write a strictly conforming C program that outputs to the display?

Question

According to ISO/IEC 9899:2017:

A strictly conforming program shall use only those features of the language and library specified in this document. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

However, a few pages later, it says:

The active position is that location on a display device where the next character output by the fputc function would appear. The intent of writing a printing character (as defined by the isprint function) to a display device is to display a graphic representation of that character at the active position and then advance the active position to the next position on the current line. The direction of writing is locale-specific. If the active position is at the final position of a line (if there is one), the behavior of the display device is unspecified.

Since there doesn't seem to be any way to tell if the active position is at the final position of a line, then there is no way to output to the display device without risking invoking unspecified behavior, and as such it's impossible to write a strictly conforming program. Is this a mistake or is there something I'm missing?

Answer 1

Since there doesn't seem to be any way to tell if the active position is at the final position of a line, then there is no way to output to the display device without risking invoking unspecified behavior

Agreed, but the requirement on a strictly-conforming program is not that it avoid all unspecified behavior, but rather that

It shall not produce output dependent on [unspecified behavior et. al]

The output produced is a function of the program. The behavior of a device to which that output is directed is a function of the device, separate from the output itself, and whether that behavior is specified or well defined is not relevant to whether the program conforms strictly.

Is it possible to write a strictly conforming C program that outputs to the display?

It is not possible for a strictly-conforming program to know or control whether any output it produces is directed to the (a) display. But when it is, that does not impact the program's conformance. In that sense, yes, it is possible to write a strictly conforming program that outputs to a display device. Doing so is not any harder than writing a strictly conforming program that outputs to a regular file.

Answer 2

Many aspects of the C Standard are rather "hand-wavy", and do not seriously attempt to unambiguously characterize every possible C program as being unambiguously strictly conforming or unambiguously not strictly conforming. Indeed, it's impossible to determine whether any particular source text is a strictly conforming C program based solely on the text.

Consider the program:

#include <stdio.h>
int main(void)
{
  printf("1") + printf("2");
  printf("\n");
  return 0;
}

the above could be:

1. A Strictly Conforming C Program to output an arbitrary multiple of 3.
2. A non-portable program to output an arbitrary multiple of 4.
3. A non-portable program to output an arbitrary multiple of 7.
4. A Strictly Conforming but buggy program to output an arbitrary multiple of 8.
5. A non-portable and buggy program to output an arbitrary multiple of 8.

If a program which is supposed to produce a particular image on on a display is specified as sending a certain sequence of characters to stdout, with whatever consequences result, then such a program could be strictly conforming even if the sequence of bytes was chosen because it will produce a particular image when run on a particular system. If the program which specified as producing that particular image outputs the same sequence of bytes, it would be a non-portable program to produce that particular image on a particular system.

A standard for things that are supposed to work together, such as plugs and sockets, would have separate specifications for plugs, sockets, plug testers, and socket testers, such that:

1. It would be impossible for any combination of plug and plug tester to exist, such that the plug would be rejected, unless either the plug or tester was unambiguously non-conforming.

2. It would be impossible for any combination of plug and plug tester to exist, such that the plug would be rejected, unless either the plug or tester was unambiguously non-conforming.

3. It would be impossible for any combination of plug, socket, plug tester, and socket tester to exist, such that the plug and socket pass their respective tests, but the plug wouldn't work with the socket, unless at least one of the testers was unambiguously non-conforming.

Note that there is no need to unambiguously partition the universe unambiguously into things that are conforming plugs and things that are not conforming plugs, nor likewise for sockets, plug testers, or socket testers. If there are some things that cannot be reliably classified as being conforming plugs or not being conforming plugs, but plug testers would unambiguously be required to accept them, the presence of ambiguity wouldn't pose a particular problem beyond increasing the cost of conformance. Good standard should seek to tolerate whatever level of ambiguity would be most practical, rather than trying to eliminate all ambiguity altogether.

The C Standard, unfortunately, tries to use one specification for everything, without either trying to eliminate ambiguity nor make any accommodations for it. Instead, the Standard falls back on a hand-waving reliance upon implementations to exercise common sense in deciding how to process constructs without regard for whether they are "technically" strictly conforming, thus avoiding any need for the Standard to unambiguously say whether they are or not.