kmx git

Commit	Date	Message
1a85fc49	2018-05-21T12:07:40	Additional code formatting tweaks ... detected with an improved version of our checkstyle script
b628d693	2018-04-08T12:49:05	Additional code formatting tweaks ... detected with an improved version of our checkstyle script
51f94cab	2018-03-31T10:36:06	Build: Use Colin Plumb's public domain MD5 code ... instead of the RSA code, the license for which contains an advertising clause. It is strongly believed that the RSA advertising clause is innocuous, because: - A clarification from RSA (http://www.ietf.org/ietf-ftp/IPR/RSA-MD-all), published in 2000, stated: "Implementations of these message-digest algorithms, including implementations derived from the reference C code in RFC-1319, RFC-1320, and RFC-1321, may be made, used, and sold without license from RSA for any purpose." Referring to the opinion from Fedora's legal team (https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F), this means that md5.c and md5.h, which were derived from the original RFC 1321 reference code (http://www.faqs.org/rfcs/rfc1321.html), can be used without the RSA license. - In the context of libjpeg-turbo, RSA's MD5 code was used only in the build/test system. It was not part of the libjpeg-turbo binary distribution, and thus the only "material mentioning or referencing" the MD5 code was the libjpeg-turbo source code, which-- by virtue of including RSA's original copyright headers-- properly attributed the code as required under the RSA license. However, in light of the open source community's tendency to have knee-jerk reactions to stuff like this, it would've been necessary to include the above explanation in our source tree in order to head off potential FUD, and a simple fix is always better than a complex explanation. This commit also assigns the 3-clause BSD license to my modifications of the MD5 code. This license is the same one used by md5cmp and other parts of the build system.
293263c3	2018-03-17T15:14:35	Format preprocessor macros more consistently Within the libjpeg API code, it seems to be more the convention than not to separate the macro name and value by two or more spaces, which improves general readability. Making this consistent across all of libjpeg-turbo is less about my individual preferences and more about making it easy to automatically detect variations from our chosen formatting convention. I intend to release the script I'm using to validate this stuff, once it matures and stabilizes a bit.
19c791cd	2018-03-08T10:55:20	Improve code formatting consistency With rare exceptions ... - Always separate line continuation characters by one space from preceding code. - Always use two-space indentation. Never use tabs. - Always use K&R-style conditional blocks. - Always surround operators with spaces, except in raw assembly code. - Always put a space after, but not before, a comma. - Never put a space between type casts and variables/function calls. - Never put a space between the function name and the argument list in function declarations and prototypes. - Always surround braces ('{' and '}') with spaces. - Always surround statements (if, for, else, catch, while, do, switch) with spaces. - Always attach pointer symbols ('' and '') to the variable or function name. - Always precede pointer symbols ('' and '**') by a space in type casts. - Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG API libraries (using min() from tjutil.h is still necessary for TJBench.) - Where it makes sense (particularly in the TurboJPEG code), put a blank line after variable declaration blocks. - Always separate statements in one-liners by two spaces. The purpose of this was to ease maintenance on my part and also to make it easier for contributors to figure out how to format patch submissions. This was admittedly confusing (even to me sometimes) when we had 3 or 4 different style conventions in the same source tree. The new convention is more consistent with the formatting of other OSS code bases. This commit corrects deviations from the chosen formatting style in the libjpeg API code and reformats the TurboJPEG API code such that it conforms to the same standard. NOTES: - Although it is no longer necessary for the function name in function declarations to begin in Column 1 (this was historically necessary because of the ansi2knr utility, which allowed libjpeg to be built with non-ANSI compilers), we retain that formatting for the libjpeg code because it improves readability when using libjpeg's function attribute macros (GLOBAL(), etc.) - This reformatting project was accomplished with the help of AStyle and Uncrustify, although neither was completely up to the task, and thus a great deal of manual tweaking was required. Note to developers of code formatting utilities: the libjpeg-turbo code base is an excellent test bed, because AFAICT, it breaks every single one of the utilities that are currently available. - The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been formatted to match the SSE2 code (refer to ff5685d5344273df321eb63a005eaae19d2496e3.) I hadn't intended to bother with this, but the Loongson MMI implementation demonstrated that there is still academic value to the MMX implementation, as an algorithmic model for other 64-bit vector implementations. Thus, it is desirable to improve its readability in the same manner as that of the SSE2 implementation.
aa745905	2017-11-16T18:09:07	TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.
8a9b042b	2016-12-10T09:35:30	Merge branch 'master' into dev
82bf7f58	2016-12-01T18:23:32	Fix md5cmp on AmigaOS 4 (PowerPC big-endian) + Document AmigaOS support in the change log. Based on: https://github.com/chris-y/libjpeg-turbo/commit/b4f3b757970cd9dd448af9d2713b6bcdd9929147 Closes #119
6abd3916	2016-11-15T08:47:43	Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
123f7258	2016-05-24T10:23:56	Format copyright headers more consistently The IJG convention is to format copyright notices as: Copyright (C) YYYY, Owner. We try to maintain this convention for any code that is part of the libjpeg API library (with the exception of preserving the copyright notices from Cendio's code verbatim, since those predate libjpeg-turbo.) Note that the phrase "All Rights Reserved" is no longer necessary, since all Buenos Aires Convention signatories signed onto the Berne Convention in 2000. However, our convention is to retain this phrase for any files that have a self-contained copyright header but to leave it off of any files that refer to another file for conditions of distribution and use. For instance, all of the non-SIMD files in the libjpeg API library refer to README.ijg, and the copyright message in that file contains "All Rights Reserved", so it is unnecessary to add it to the individual files. The TurboJPEG code retains my preferred formatting convention for copyright notices, which is based on that of VirtualGL (where the TurboJPEG API originated.)
f9134384	2016-02-06T14:09:20	Win: Enable testing cross-compiled builds When cross-compiling, CMakeLists.txt now generates the CTest script using relative paths, so that CTest can more easily be executed on a different machine from the build machine. Furthermore, Windows builds are now tested using md5cmp, just like on Linux, rather than a CMake script. This prevents issues with differing CMake locations between the build and test machines. This also removes some trailing spaces from the md5cmp code and improves the readability of the test code in CMakeLists.txt.
339589f3	2014-08-30T13:55:08	Fix build on OS X PowerPC platforms git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1397 632fc199-4ca6-4c93-a231-07263d6284db
7eced19f	2013-03-30T20:54:15	Remove unneeded headers (cdef.h isn't available on all platforms) and change u_int32_t to unsigned int, since u_int32_t isn't available on all platforms. This fixes build issues on Solaris. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@942 632fc199-4ca6-4c93-a231-07263d6284db
292fb842	2013-02-06T23:55:59	Fix 'make dist' git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@927 632fc199-4ca6-4c93-a231-07263d6284db
0bf58f21	2013-02-06T23:51:08	Include a C version of md5cmp rather than depending on an external md5sum binary, since md5sum is not available on all platforms (specifically, it doesn't exist on FreeBSD, and it has to be installed via MacPorts on OS X.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@926 632fc199-4ca6-4c93-a231-07263d6284db

1a85fc49

2018-05-21T12:07:40

Additional code formatting tweaks ... detected with an improved version of our checkstyle script

b628d693

2018-04-08T12:49:05

Additional code formatting tweaks ... detected with an improved version of our checkstyle script

51f94cab

2018-03-31T10:36:06

Build: Use Colin Plumb's public domain MD5 code ... instead of the RSA code, the license for which contains an advertising clause. It is strongly believed that the RSA advertising clause is innocuous, because: - A clarification from RSA (http://www.ietf.org/ietf-ftp/IPR/RSA-MD-all), published in 2000, stated: "Implementations of these message-digest algorithms, including implementations derived from the reference C code in RFC-1319, RFC-1320, and RFC-1321, may be made, used, and sold without license from RSA for any purpose." Referring to the opinion from Fedora's legal team (https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F), this means that md5.c and md5.h, which were derived from the original RFC 1321 reference code (http://www.faqs.org/rfcs/rfc1321.html), can be used without the RSA license. - In the context of libjpeg-turbo, RSA's MD5 code was used only in the build/test system. It was not part of the libjpeg-turbo binary distribution, and thus the only "material mentioning or referencing" the MD5 code was the libjpeg-turbo source code, which-- by virtue of including RSA's original copyright headers-- properly attributed the code as required under the RSA license. However, in light of the open source community's tendency to have knee-jerk reactions to stuff like this, it would've been necessary to include the above explanation in our source tree in order to head off potential FUD, and a simple fix is always better than a complex explanation. This commit also assigns the 3-clause BSD license to my modifications of the MD5 code. This license is the same one used by md5cmp and other parts of the build system.

293263c3

2018-03-17T15:14:35

Format preprocessor macros more consistently Within the libjpeg API code, it seems to be more the convention than not to separate the macro name and value by two or more spaces, which improves general readability. Making this consistent across all of libjpeg-turbo is less about my individual preferences and more about making it easy to automatically detect variations from our chosen formatting convention. I intend to release the script I'm using to validate this stuff, once it matures and stabilizes a bit.

19c791cd

2018-03-08T10:55:20

Improve code formatting consistency With rare exceptions ... - Always separate line continuation characters by one space from preceding code. - Always use two-space indentation. Never use tabs. - Always use K&R-style conditional blocks. - Always surround operators with spaces, except in raw assembly code. - Always put a space after, but not before, a comma. - Never put a space between type casts and variables/function calls. - Never put a space between the function name and the argument list in function declarations and prototypes. - Always surround braces ('{' and '}') with spaces. - Always surround statements (if, for, else, catch, while, do, switch) with spaces. - Always attach pointer symbols ('*' and '**') to the variable or function name. - Always precede pointer symbols ('*' and '**') by a space in type casts. - Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG API libraries (using min() from tjutil.h is still necessary for TJBench.) - Where it makes sense (particularly in the TurboJPEG code), put a blank line after variable declaration blocks. - Always separate statements in one-liners by two spaces. The purpose of this was to ease maintenance on my part and also to make it easier for contributors to figure out how to format patch submissions. This was admittedly confusing (even to me sometimes) when we had 3 or 4 different style conventions in the same source tree. The new convention is more consistent with the formatting of other OSS code bases. This commit corrects deviations from the chosen formatting style in the libjpeg API code and reformats the TurboJPEG API code such that it conforms to the same standard. NOTES: - Although it is no longer necessary for the function name in function declarations to begin in Column 1 (this was historically necessary because of the ansi2knr utility, which allowed libjpeg to be built with non-ANSI compilers), we retain that formatting for the libjpeg code because it improves readability when using libjpeg's function attribute macros (GLOBAL(), etc.) - This reformatting project was accomplished with the help of AStyle and Uncrustify, although neither was completely up to the task, and thus a great deal of manual tweaking was required. Note to developers of code formatting utilities: the libjpeg-turbo code base is an excellent test bed, because AFAICT, it breaks every single one of the utilities that are currently available. - The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been formatted to match the SSE2 code (refer to ff5685d5344273df321eb63a005eaae19d2496e3.) I hadn't intended to bother with this, but the Loongson MMI implementation demonstrated that there is still academic value to the MMX implementation, as an algorithmic model for other 64-bit vector implementations. Thus, it is desirable to improve its readability in the same manner as that of the SSE2 implementation.

aa745905

2017-11-16T18:09:07

TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.

8a9b042b

2016-12-10T09:35:30

Merge branch 'master' into dev

82bf7f58

2016-12-01T18:23:32

Fix md5cmp on AmigaOS 4 (PowerPC big-endian) + Document AmigaOS support in the change log. Based on: https://github.com/chris-y/libjpeg-turbo/commit/b4f3b757970cd9dd448af9d2713b6bcdd9929147 Closes #119

6abd3916

2016-11-15T08:47:43

Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/

123f7258

2016-05-24T10:23:56

Format copyright headers more consistently The IJG convention is to format copyright notices as: Copyright (C) YYYY, Owner. We try to maintain this convention for any code that is part of the libjpeg API library (with the exception of preserving the copyright notices from Cendio's code verbatim, since those predate libjpeg-turbo.) Note that the phrase "All Rights Reserved" is no longer necessary, since all Buenos Aires Convention signatories signed onto the Berne Convention in 2000. However, our convention is to retain this phrase for any files that have a self-contained copyright header but to leave it off of any files that refer to another file for conditions of distribution and use. For instance, all of the non-SIMD files in the libjpeg API library refer to README.ijg, and the copyright message in that file contains "All Rights Reserved", so it is unnecessary to add it to the individual files. The TurboJPEG code retains my preferred formatting convention for copyright notices, which is based on that of VirtualGL (where the TurboJPEG API originated.)

f9134384

2016-02-06T14:09:20

Win: Enable testing cross-compiled builds When cross-compiling, CMakeLists.txt now generates the CTest script using relative paths, so that CTest can more easily be executed on a different machine from the build machine. Furthermore, Windows builds are now tested using md5cmp, just like on Linux, rather than a CMake script. This prevents issues with differing CMake locations between the build and test machines. This also removes some trailing spaces from the md5cmp code and improves the readability of the test code in CMakeLists.txt.

339589f3

2014-08-30T13:55:08

Fix build on OS X PowerPC platforms git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1397 632fc199-4ca6-4c93-a231-07263d6284db

7eced19f

2013-03-30T20:54:15

Remove unneeded headers (cdef.h isn't available on all platforms) and change u_int32_t to unsigned int, since u_int32_t isn't available on all platforms. This fixes build issues on Solaris. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@942 632fc199-4ca6-4c93-a231-07263d6284db

292fb842

2013-02-06T23:55:59

Fix 'make dist' git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@927 632fc199-4ca6-4c93-a231-07263d6284db

0bf58f21

2013-02-06T23:51:08

Include a C version of md5cmp rather than depending on an external md5sum binary, since md5sum is not available on all platforms (specifically, it doesn't exist on FreeBSD, and it has to be installed via MacPorts on OS X.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@926 632fc199-4ca6-4c93-a231-07263d6284db

kc3-lang/libjpeg-turbo/md5

md5

Log