File: mozilla.diff

package info (click to toggle)
firefox 147.0-1
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 4,683,324 kB
  • sloc: cpp: 7,607,156; javascript: 6,532,492; ansic: 3,775,158; python: 1,415,368; xml: 634,556; asm: 438,949; java: 186,241; sh: 62,751; makefile: 18,079; objc: 13,092; perl: 12,808; yacc: 4,583; cs: 3,846; pascal: 3,448; lex: 1,720; ruby: 1,003; php: 436; lisp: 258; awk: 247; sql: 66; sed: 54; csh: 10; exp: 6
file content (79 lines) | stat: -rw-r--r-- 3,434 bytes parent folder | download | duplicates (11)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
diff --git a/media/libjpeg/jmorecfg.h b/media/libjpeg/jmorecfg.h
--- a/media/libjpeg/jmorecfg.h
+++ b/media/libjpeg/jmorecfg.h
@@ -9,16 +9,17 @@
  * For conditions of distribution and use, see the accompanying README.ijg
  * file.
  *
  * This file contains additional configuration options that customize the
  * JPEG software for special applications or support machine-dependent
  * optimizations.  Most users will not need to touch this file.
  */
 
+#include <stdint.h>
 
 /*
  * Maximum number of components (color channels) allowed in JPEG image.
  * To meet the letter of Rec. ITU-T T.81 | ISO/IEC 10918-1, set this to 255.
  * However, darn few applications need more than 4 channels (maybe 5 for CMYK +
  * alpha mask).  We recommend 10 as a reasonable compromise; use 4 if you are
  * really short on memory.  (Each allowed component costs a hundred or so
  * bytes of storage, whether actually used in an image or not.)
@@ -91,27 +92,25 @@ typedef unsigned char JOCTET;
  * They must be at least as wide as specified; but making them too big
  * won't cost a huge amount of memory, so we don't provide special
  * extraction code like we did for JSAMPLE.  (In other words, these
  * typedefs live at a different point on the speed/space tradeoff curve.)
  */
 
 /* UINT8 must hold at least the values 0..255. */
 
-typedef unsigned char UINT8;
+typedef uint8_t UINT8;
 
 /* UINT16 must hold at least the values 0..65535. */
 
-typedef unsigned short UINT16;
+typedef uint16_t UINT16;
 
 /* INT16 must hold at least the values -32768..32767. */
 
-#ifndef XMD_H                   /* X11/xmd.h correctly defines INT16 */
-typedef short INT16;
-#endif
+typedef int16_t INT16;
 
 /* INT32 must hold at least signed 32-bit values.
  *
  * NOTE: The INT32 typedef dates back to libjpeg v5 (1994.)  Integers were
  * sometimes 16-bit back then (MS-DOS), which is why INT32 is typedef'd to
  * long.  It also wasn't common (or at least as common) in 1994 for INT32 to be
  * defined by platform headers.  Since then, however, INT32 is defined in
  * several other common places:
@@ -128,25 +127,17 @@ typedef short INT16;
  * This is a recipe for conflict, since "long" and "int" aren't always
  * compatible types.  Since the definition of INT32 has technically been part
  * of the libjpeg API for more than 20 years, we can't remove it, but we do not
  * use it internally any longer.  We instead define a separate type (JLONG)
  * for internal use, which ensures that internal behavior will always be the
  * same regardless of any external headers that may be included.
  */
 
-#ifndef XMD_H                   /* X11/xmd.h correctly defines INT32 */
-#ifndef _BASETSD_H_             /* Microsoft defines it in basetsd.h */
-#ifndef _BASETSD_H              /* MinGW is slightly different */
-#ifndef QGLOBAL_H               /* Qt defines it in qglobal.h */
-typedef long INT32;
-#endif
-#endif
-#endif
-#endif
+typedef int32_t INT32;
 
 /* Datatype used for image dimensions.  The JPEG standard only supports
  * images up to 64K*64K due to 16-bit fields in SOF markers.  Therefore
  * "unsigned int" is sufficient on all machines.  However, if you need to
  * handle larger images and you don't mind deviating from the spec, you
  * can change this datatype.  (Note that changing this datatype will
  * potentially require modifying the SIMD code.  The x86-64 SIMD extensions,
  * in particular, assume a 32-bit JDIMENSION.)