Remove jpeg_std_message_table[] extern sym comment
jpeg_std_message_table[] was never a documented part of the libjpeg API,
nor was it exposed in jpegint.h or the Windows libjpeg API DLL. Thus,
it was never a good idea (nor was it even remotely necessary) for
applications to use it. However, referring to #763 and #767, one
application (RawTherapee) did use it.
34c055851ecb66a2d9bee1a3318c55cd9acd6586 hid the symbol, which broke the
Un*x builds of RawTherapee. (RawTherapee already did the right thing on
Windows, because jpeg_std_message_table[] was not exposed in the
Windows libjpeg API DLL. Referring to
https://github.com/Beep6581/RawTherapee/issues/7074, RawTherapee now
does the right thing on Un*x platforms as well.)
The comment in jerror.c indicated that Tom Lane intended the symbol to
be external "just in case any applications want to refer to it
directly." However, with respect to libjpeg-turbo, the comment was
effectively already a lie on Windows. My choices at this point are:
1. Revert 34c055851ecb66a2d9bee1a3318c55cd9acd6586 and start exposing
the symbol on Windows, thus making the comment true again.
2. Remove the comment.
Option 1 would have created whiplash, since 3.0.3 has already been
released with the symbol hidden, and that option would have further
encouraged ill-advised behavior on the part of applications. Since the
issue has already been fixed in RawTherapee, and since it is known to
affect only that application, I chose Option 2.
In my professional opinion, a code comment does not rise to the level
of a contract between a library and a calling application. In other
words, the comment did not make the symbol part of the API, even though
the symbol was exposed on some platforms. Applications that use
internal symbols (even the symbols defined in jpegint.h) do so at their
own risk. There is no guarantee that those symbols will remain
unchanged from release to release, as it is sometimes necessary to
modify the internal (opaque) structures and methods in order to
implement new features or even fix bugs. Some implementations of the
libjpeg API (such as the one in Jpegli, for instance), do not provide
those internal symbols at all. Best practices are for applications that
use the internal libjpeg-turbo symbols to provide their own copy of
libjpeg-turbo (for instance, via static linking), so they can manage any
unexpected changes in those symbols. (In fact, that is how libjpeg was
originally used. Application developers built it from source with
compile-time options to exclude unneeded functionality. Thus, no two
builds of libjpeg were guaranteed to be API/ABI-compatible. The idea of
a libjpeg shared library that exposes a pseudo-standard ABI came later,
and that has always been an awkward fit for an API that was intended to
be modified at compile time to suit specific application needs.
libjpeg-turbo's colorspace extensions are but one example, among many,
of our attempts to reconcile that awkwardness while preserving backward
compatibility with the aforementioned pseudo-standard ABI.)
diff --git a/jerror.c b/jerror.c
index 3a75fec..2133244 100644
--- a/jerror.c
+++ b/jerror.c
@@ -40,8 +40,6 @@
* Create the message string table.
* We do this from the master message list in jerror.h by re-reading
* jerror.h with a suitable definition for macro JMESSAGE.
- * The message table is made an external symbol just in case any applications
- * want to refer to it directly.
*/
#define JMESSAGE(code, string) string,
