cpet/openbsd-ports
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fa7d0f0b1e
openbsd-ports/audio/faad/patches/patch-frontend_main_c

85 lines
2.5 KiB
Plaintext
Raw Normal View History

problem: libfaad uses data types with machine dependent bit width in prototypes in its public headers, but in the corresponding library code, machine independent exact width data types are used. solution: change libfaad headers to use the same machine independent exact width data types in the prototypes as in the library. since the prototypes in the library headers are changed, users of libfaad likely need to be modified to use exact width data types as well. also: - bump libfaad major version number - update plugin code to use exact width data types for libfaad interaction, as per new prototypes - bump package version - sync patches with update-patches problem discovered by, solution discussed with, reviewed, tested and OK naddy@
2007-06-29 02:01:42 -04:00
$OpenBSD: patch-frontend_main_c,v 1.5 2007/06/29 06:01:42 jakemsr Exp $
--- frontend/main.c.orig Tue Jan 6 03:59:47 2004
+++ frontend/main.c Thu May 31 18:00:02 2007
@@ -37,6 +37,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
+#include <string.h>
#include <faad.h>
#include <mp4ff.h>
@@ -52,10 +53,10 @@
/* FAAD file buffering routines */
typedef struct {
- long bytes_into_buffer;
- long bytes_consumed;
- long file_offset;
- unsigned char *buffer;
+ uint32_t bytes_into_buffer;
+ uint32_t bytes_consumed;
+ uint32_t file_offset;
+ uint8_t *buffer;
int at_eof;
FILE *infile;
} aac_buffer;
@@ -377,8 +378,8 @@ int decodeAACfile(char *aacfile, char *sndfile, char *
float *song_length)
{
int tagsize;
- unsigned long samplerate;
- unsigned char channels;
+ uint32_t samplerate;
+ uint8_t channels;
void *sample_buffer;
audio_file *aufile;
@@ -687,8 +688,8 @@ int decodeMP4file(char *mp4file, char *sndfile, char *
int infoOnly, int adts_out, float *song_length)
{
int track;
- unsigned long samplerate;
- unsigned char channels;
+ uint32_t samplerate;
+ uint8_t channels;
void *sample_buffer;
mp4ff_t *infile;
@@ -1080,7 +1081,7 @@ int main(int argc, char *argv[])
update to 2.0
2004-04-27 21:30:00 -04:00
if (optarg)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
char dr[10];
- if (sscanf(optarg, "%s", dr) < 1) {
+ if (sscanf(optarg, "%9s", dr) < 1) {
def_srate = 0;
} else {
def_srate = atoi(dr);
problem: libfaad uses data types with machine dependent bit width in prototypes in its public headers, but in the corresponding library code, machine independent exact width data types are used. solution: change libfaad headers to use the same machine independent exact width data types in the prototypes as in the library. since the prototypes in the library headers are changed, users of libfaad likely need to be modified to use exact width data types as well. also: - bump libfaad major version number - update plugin code to use exact width data types for libfaad interaction, as per new prototypes - bump package version - sync patches with update-patches problem discovered by, solution discussed with, reviewed, tested and OK naddy@
2007-06-29 02:01:42 -04:00
@@ -1091,7 +1092,7 @@ int main(int argc, char *argv[])
update to 2.0
2004-04-27 21:30:00 -04:00
if (optarg)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
char dr[10];
update to 2.0
2004-04-27 21:30:00 -04:00
- if (sscanf(optarg, "%s", dr) < 1)
+ if (sscanf(optarg, "%9s", dr) < 1)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
format = 1;
} else {
problem: libfaad uses data types with machine dependent bit width in prototypes in its public headers, but in the corresponding library code, machine independent exact width data types are used. solution: change libfaad headers to use the same machine independent exact width data types in the prototypes as in the library. since the prototypes in the library headers are changed, users of libfaad likely need to be modified to use exact width data types as well. also: - bump libfaad major version number - update plugin code to use exact width data types for libfaad interaction, as per new prototypes - bump package version - sync patches with update-patches problem discovered by, solution discussed with, reviewed, tested and OK naddy@
2007-06-29 02:01:42 -04:00
@@ -1105,7 +1106,7 @@ int main(int argc, char *argv[])
update to 2.0
2004-04-27 21:30:00 -04:00
if (optarg)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
char dr[10];
update to 2.0
2004-04-27 21:30:00 -04:00
- if (sscanf(optarg, "%s", dr) < 1)
+ if (sscanf(optarg, "%9s", dr) < 1)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
outputFormat = FAAD_FMT_16BIT; /* just use default */
} else {
problem: libfaad uses data types with machine dependent bit width in prototypes in its public headers, but in the corresponding library code, machine independent exact width data types are used. solution: change libfaad headers to use the same machine independent exact width data types in the prototypes as in the library. since the prototypes in the library headers are changed, users of libfaad likely need to be modified to use exact width data types as well. also: - bump libfaad major version number - update plugin code to use exact width data types for libfaad interaction, as per new prototypes - bump package version - sync patches with update-patches problem discovered by, solution discussed with, reviewed, tested and OK naddy@
2007-06-29 02:01:42 -04:00
@@ -1119,7 +1120,7 @@ int main(int argc, char *argv[])
update to 2.0
2004-04-27 21:30:00 -04:00
if (optarg)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
char dr[10];
update to 2.0
2004-04-27 21:30:00 -04:00
- if (sscanf(optarg, "%s", dr) < 1)
+ if (sscanf(optarg, "%9s", dr) < 1)
{
plug some unbounded sscanf in getopt processing
2003-04-26 16:42:00 -04:00
object_type = LC; /* default */
} else {
Reference in New Issue Copy Permalink