Bug 23168 - xdr_long and xdr_u_long should fail to encode when value is out of representable range
Summary: xdr_long and xdr_u_long should fail to encode when value is out of representa...
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.0
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-02 18:59 UTC by John Kohl
Modified: 2016-11-24 15:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-02 19:01:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program to show failure of xdr_u_long() on oversized value (2.70 KB, text/plain)
2001-01-02 19:00 UTC, John Kohl
no flags Details

Description John Kohl 2001-01-02 18:59:05 UTC
xdr_long and xdr_u_long should fail to encode values which
will not fit in 32-bit quantities.
They succeed currently (in glibc-2.2) but only encode the low-order
32 bits.

See the examples in the attached program.
(earlier versions of glibc, before 2.2, screwed up xdr_u_long on decode,
sign extending rather than zero-extending)

Comment 1 John Kohl 2001-01-02 19:00:02 UTC
Created attachment 6963 [details]
test program to show failure of xdr_u_long() on oversized value

Comment 2 John Kohl 2001-01-02 19:01:35 UTC
bug is likely present on all platforms where
'long' is a 64-bit integral type

Comment 3 Jakub Jelinek 2001-01-04 10:04:12 UTC
Thorsten Kukuk claims glibc is correct in doing so, see
http://sources.redhat.com/ml/libc-hacker/2001-01/msg00008.html

Comment 4 John Kohl 2001-01-04 14:02:59 UTC
I disagree with your characterization of this as not a bug.

DEC OSF/1 -> Digital UNIX -> Tru64 UNIX has always done this range
checking since 1993.  It provides a very useful and important program
portability check.

For sensible interoperability between platforms with 32- and 64-bit
'long' values, these routines should fail to encode 64-bit longs.

It is absolutely broken for the routines to decode an encoded value into
something other than what was encoded.  Since the types cannot possibly
fit into the range of a 32-bit value on the wire, the routines *must*
fail on encoding.




Note You need to log in before you can comment on or make changes to this bug.