Dmitry Stogov
4a2e40bb86
Use ZSTR_ API to access zend_string elements (this is just renaming without semantick changes).
2015-06-30 04:05:24 +03:00
Xinchen Hui
fc33f52d8c
bump year
2015-01-15 23:27:30 +08:00
Anatol Belski
bdeb220f48
first shot remove TSRMLS_* things
2014-12-13 23:06:14 +01:00
Johannes Schlüter
d0cb715373
s/PHP 5/PHP 7/
2014-09-19 18:33:14 +02:00
Anatol Belski
3fa5064173
remove useless check
2014-09-19 00:06:32 +02:00
Anatol Belski
3234480827
first show to make 's' work with size_t
2014-08-27 20:49:31 +02:00
Anatol Belski
4d997f63d9
master renames phase 3
2014-08-25 20:22:49 +02:00
Anatol Belski
c3e3c98ec6
master renames phase 1
2014-08-25 19:24:55 +02:00
Anatol Belski
b7e7a89541
several fixes -
...
- param parsing Z_PARAM_STR vs Z_PARAM_STRING
- some functions for new params
- etc
2014-08-16 12:55:13 +02:00
Xinchen Hui
93428dc6b9
Refactor base64 to returning zend_string
2014-02-24 18:48:22 +08:00
Dmitry Stogov
f4cfaf36e2
Use better data structures (incomplete)
2014-02-10 10:04:30 +04:00
Xinchen Hui
c081ce628f
Bump year
2014-01-03 11:08:10 +08:00
Xinchen Hui
a666285bc2
Happy New Year
2013-01-01 16:37:09 +08:00
Nikita Popov
5b3f4d25ea
Fix memory allocation checks for base64 encode
...
base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.
There was a size check in place, but it was off by a factor of two as it
didn't account for the signedness of the integer type.
The unsafe allocation is not exploitable, but still causes funny behavior
when the sized overflows into a negative number.
To fix the issue the *4 factor is moved into the size argument (where it is
known to be safe), so safe_emalloc can carry out the multiplication.
The size check is removed as it doesn't really make sense once safe_emalloc
works correctly. (Would only cause base64_encode to silently return false
instead of throwing an error. Also could cause problems with other uses of
the base64 encoding API, which all don't check for a NULL return value.)
Furthermore the (length + 2) < 0 check is replaced with just length < 0.
Allowing lengths -2 and -1 doesn't make sense semantically and also is not
honored in the following code (negative length would access unallocated
memory.)
Actually the length < 0 check doesn't make sense altogether, but I left it
there just to be safe.
2012-06-24 23:32:50 +02:00
Felipe Pena
e4ca0ed09f
- Year++
2012-01-01 13:15:04 +00:00
Ilia Alshanetsky
2ef05a8fa4
Fixed bug #55273 (base64_decode() with strict rejects whitespace after pad)
2011-09-12 17:20:24 +00:00
Felipe Pena
927bf09c29
- Year++
2011-01-01 02:19:59 +00:00
Ilia Alshanetsky
3239a25e53
Missing bit from previous commit
2010-11-26 21:00:03 +00:00
Sebastian Bergmann
9ba1e81665
sed -i "s#1997-2009#1997-2010#g" **/*.c **/*.h **/*.php
2010-01-03 09:23:27 +00:00
Ilia Alshanetsky
4eb69eadc6
Improved fix for bug #47174 & added a test
2009-01-25 18:27:12 +00:00
Ilia Alshanetsky
bd9ad75f41
Fixed bug #47174 (base64_decode() interprets pad char in mid string as
...
terminator)
2009-01-21 15:38:37 +00:00
Sebastian Bergmann
08659c2dcd
MFH: Bump copyright year, 3 of 3.
2008-12-31 11:15:49 +00:00
Nuno Lopes
8a77e55566
clean some dead code (with static analysis help)
2008-09-23 15:18:26 +00:00
Sebastian Bergmann
d1dded8751
MFH: Bump copyright year, 2 of 2.
2007-12-31 07:17:19 +00:00
Jani Taskinen
44c7a7378f
MFH
2007-11-05 12:07:37 +00:00
Jani Taskinen
a22a6711ad
MFH: Fixed compile warnings
2007-07-21 01:24:26 +00:00
Sebastian Bergmann
4223aa4d5e
MFH: Bump year.
2007-01-01 09:36:18 +00:00
Ilia Alshanetsky
7e8409de8c
Fixed bug #37244 (Added strict flag to base64_decode() that enforces
...
RFC3548 compliance).
2006-05-06 22:47:14 +00:00
foobar
5bd93221a8
bump year and license version
2006-01-01 12:51:34 +00:00
Ilia Alshanetsky
980b9be4b4
Fixed bug #34214 (base64_decode() does not properly ignore whitespace)
2005-08-26 03:32:31 +00:00
foobar
23e671a51e
- Bumber up year
2005-08-03 14:08:58 +00:00
Ilia Alshanetsky
72a3bb18d1
Fixed bug #27460 (base64_decode() does not handle extra padding).
2004-03-06 19:06:04 +00:00
Andi Gutmans
dbeb4158d2
- A belated happy holidays and PHP 5
2004-01-08 08:18:22 +00:00
Ilia Alshanetsky
c8ecf7ec3e
Fixed bug #24312 (base64_decode() does not skip 0xF0-0xFF characters)
...
Patch by: gereon.steffens[at]onvista.de
2003-06-24 15:23:17 +00:00
James Cox
f68c7ff249
updating license information in the headers.
2003-06-10 20:04:29 +00:00
Moriyoshi Koizumi
12ecc6ca1e
Fixed base64_encode() integer overflow issue pointed out in TODO_SEGFAULTS
2003-06-04 14:41:45 +00:00
Frank M. Kromann
4da2e804e0
Allow base64 functions to be called from an extension buils as .so/.dll (iconv)
2003-01-01 18:11:18 +00:00
Sebastian Bergmann
b506f5c8f8
Bump year.
2002-12-31 16:08:15 +00:00
Marcus Boerger
49a99a98f4
-php_error -> php_error_docref
...
-removed some cases where emalloc result was tested
2002-12-05 20:59:49 +00:00
Moriyoshi Koizumi
aeb6a6c458
Fixed possible buffer overflow in php_base64_decode();
...
# This bug doesn't appear to be harmful for now,
# so I won't merge it into branches...
2002-12-01 02:44:50 +00:00
foobar
ff5ed789bc
style fix
2002-08-22 01:20:50 +00:00
Wez Furlong
a9ba30cd89
fix vim modeline
2002-08-20 20:43:45 +00:00
Derick Rethans
8fe3c0c5d4
- Fix String is not zero-terminated error in base64_decode
2002-05-01 20:11:09 +00:00
Marcus Boerger
4407312d4f
thread safe
2002-04-11 08:07:22 +00:00
Sebastian Bergmann
90613d2282
Maintain headers.
2002-02-28 08:29:35 +00:00
Sebastian Bergmann
38933514e1
Update headers.
2001-12-11 15:32:16 +00:00
Andrei Zmievski
b3d49ab0e4
Convert to use new parameter parsing API.
2001-10-26 14:50:58 +00:00
Derick Rethans
78747bd2df
- Don't wrap lines... this is annoying while coding.
2001-09-09 13:29:31 +00:00
Zeev Suraski
c0404f4631
Whitespace
2001-08-11 17:03:37 +00:00
Zeev Suraski
1159c84ab7
- TSRMLS_FETCH work
...
- whitespace fixes
2001-08-05 01:43:02 +00:00
