than-stellar algorithms?
I don't think it's up to POSIX to specify either the efficiency of
implementations or, even, which algorithm is used inside the library
function (providing it meets the interface requirements).
--
Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44
created with more than 2**32 bytes. The behavior is undefined
> if you subtract two pointers into a same object and the resulting
> value does not fit into ptrdiff_t. See section 6.5.6 of the standard.
True. My bad.
--
Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:
SIZE_MAX
fit that schema but mean something different is, um, unfortunate.
--
Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44 20 8495 6138
Internet Expert | Home: <[EMAIL PROTECTED]> | Fax:+44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc||
Nick Stoughton said:
> As to the original question ... can a system that implements ssize_t
> with a SSIZE_MAX of 56k conform to POSIX?
No: SSIZE_MAX is the maximum value of ssize_t; since this is an integer
type, its maximum value must be one less than a power of 2.
--
Clive D.W. F
n the implementation just has to work around it.
> Was there ever any pressure from implementers for introducing ssize_t in
> lieu of ptrdiff_t?
I don't recall.
--
Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44 20 8495 6138
Internet Expert | Home: <[EMAIL PROTECTED]> | Fax:+44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc||
can't fit in ssize_t.
However, because size_t and ssize_t are a signed/unsigned pair, they have
useful properties (for example, when dealing with varargs lists).
--
Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44 20 8495 6138
Internet Expert | Home: <[EMAIL PR
