more progress on disabling float
diff --git a/inc/qcbor/qcbor_common.h b/inc/qcbor/qcbor_common.h
index aaea610..0500795 100644
--- a/inc/qcbor/qcbor_common.h
+++ b/inc/qcbor/qcbor_common.h
@@ -315,11 +315,15 @@
QCBOR_ERR_BAD_EXP_AND_MANTISSA = 23,
/** When decoding, a string's size is greater than size_t. In all but some
- very strange situations this is because of corrupt input CBOR and
- should be treated as such. The strange situation is a CPU with a very
- small size_t (e.g., a 16-bit CPU) and a large string (e.g., > 65KB).
+ very strange situations this is because of corrupt input CBOR and
+ should be treated as such. The strange situation is a CPU with a very
+ small size_t (e.g., a 16-bit CPU) and a large string (e.g., > 65KB).
*/
- QCBOR_ERR_STRING_TOO_LONG = 24
+ QCBOR_ERR_STRING_TOO_LONG = 24,
+
+ /** Decoding of floating-point epoch dates is unsupported and a
+ floating-point date was encountered by the decoder. */
+ QCBOR_ERR_FLOAT_DATE_UNSUPPORTED = 25,
/* This is stored in uint8_t in places; never add values > 255 */
} QCBORError;
diff --git a/inc/qcbor/qcbor_encode.h b/inc/qcbor/qcbor_encode.h
index 46fa578..8975f04 100644
--- a/inc/qcbor/qcbor_encode.h
+++ b/inc/qcbor/qcbor_encode.h
@@ -251,6 +251,178 @@
structure of tagged data not built-in (if there is any) has to be
implemented by the caller.
+
+TODO: -----
+ By default QCBOR fully supports IEEE 754 floating-point:
+ * Encode/decode of double, single and half-precision
+ * CBOR preferred serialization of floating-point
+ * Floating-point epoch dates
+
+ For the most part, the type double is used in the interface
+ for floating-point values. In the default configuration,
+ all decoded floating-point values are returned as a double.
+
+ With CBOR preferred
+ serialization, the encoder outputs the smallest representation
+ of the double or float that preserves precision. Zero,
+ NaN and infinity are always output as a half-precision, each taking
+ just 2 bytes. This reduces the number of bytes needed to
+ encode doubles and floats, especially if a zero, NaN and
+ infinity are frequently used.
+
+ To avoid use of preferred serialization when encoding, use
+ QCBOREncode_AddDoubleNoPreferred() or
+ QCBOREncode_AddFloatNoPreferred().
+
+ This implementation of preferred floating-point serialization
+ and half-precision does not depend on
+ the CPU having floating-point HW or the compiler
+ bringing a (sometimes large) library to compensate for
+ lack of CPU support. The implementation uses shifts
+ and masks rather than floating-point functions. It does however add object code.
+
+ To reduce object code #define QCBOR_DISABLE_PREFERRED_FLOAT.
+ This will elimante all support for preferred serialization and half-precision. An error will be
+ returned when attemping to decode half-precision. A float will
+ always be encoded and decoded as 32-bits and
+ a double will always be encoded and decoded as 64 bits.
+
+ On CPUs that have no floating-point hardware, QCBOR_DISABLE_FLOAT_HW_USE
+ should be defined in most cases. If it is not, then the compiler will
+ bring in possibly large software libraries to compensate or QCBOR will
+ not compile.
+
+ If QCBOR_DISABLE_FLOAT_HW_USE is defined and QCBOR_DISABLE_PREFERRED_FLOAT
+ is not defined, then the only functionality lost is the decoding of floating-point dates.
+ An error will be returned if they are encountered.
+
+ If both QCBOR_DISABLE_FLOAT_HW_USE and QCBOR_DISABLE_PREFERRED_FLOAT
+ are defined, then the only thing QCBOR can do is encode/decode a float as
+ 32-bits and a double as 64-bits. Floating-point epoch dates will not be
+ supported.
+
+
+
+
+TODO: get rid of this:
+ If preferred floating point serialization is disabled, then
+ floats and doubles may still be encoded, but they will
+ be encoded as their normal size and returned as a
+ float or double during decoding. There is no way to
+ encode half-precision and when
+ a half-precision data item is encountered during decoding, an
+ error will be returned.
+
+ QCBOR can always encode and decode floats and doubles
+ even if the CPU HW doesn't support them, even if
+ preferred serialization is disabled and doesn't need SW-based
+ floating-point to be brought in by the compiler.
+
+
+ In order to process floating-point epoch dates, QCBOR needs
+ floating point arithmetic. On CPUs that have no floating-point
+ hardware, QCBOR may be set up to not using floating-point
+ aritthmetic, in which case floating-point epoch date values
+ will be considered and error when encoding. QCBOR never
+ generates floating-point values when encoding dates.
+
+
+
+
+ . For environments with
+ no floating point HW, or to save some object code , some floating
+ point features may be disabled. In this limited mode float and double values may still be encoded
+ and decoded, but there will be no preferred encoding of them.
+ When decoding half-precison values and floating-point format
+ dates will be treated as an error. In this limited mode no
+ floating point operations like conversion in size or to integers
+ are used so in environments with no floating point HW, the
+ compiler will not have to add in support with SW.
+
+ -----
+ Default full float support
+
+ Disable: preferred float encoding / decoding. Savs 300 bytes during
+ decoding and 300 bytes during encodeing. Can still encode / decode
+ float and double values. This need not be disabled on devices
+ with no floating point HW because preferred encoding / decoding
+ is all done internally with shifts and masks.
+
+ QCBOR_DISABLE_FLOAT_HW_USE. Disable use of floating point HW. Saves a very small amount of
+ code on devices with no floating point HW and a lot of code on
+ devices without floating point HW. The compiler won't bring in
+ the floating point SW that emulates the HW. When this is done
+ floating point dates are not supported. When this is disabled,
+ the following is not available: handling of floating-point epoch dates.
+
+
+ QCBOR_DISABLE_FLOAT_PREFERRED_SERIALIZATION. This disables
+ preferred serialization of floating-point values. It also
+ disables all support for half-precision floating-point. The main
+ reason to disable this is to reduce object code in the decoder
+ by a few hundred bytes. It is not as necessary to
+ disable this to reduce size of the encoder, because avoiding
+ calls to the floating-point encode functions has the same effect.
+
+ Even when this is disabled, QCBOR
+ can encode and decode float and double values. What is
+ unavailable is the reduction in size of encoded floats and
+ the ability to decode half-precision.
+
+ Preferred serialization encoding and decoding
+ does not use floating-point HW, so it is not necessary to
+ disable this on CPUs without floating-point support. However,
+ if a CPU doesn't support floating point, then use of floating
+ point is usually very expensive and slow because the compiler
+ must bring in large SW libraries. For that reason some may
+ choose to disable floating-point preferred serialization because it is
+ unlikely to be needed.
+
+ QCBOR_DISABLE_FLOAT_HW_USE. This disables
+ all use of CPU floating-point HW and the
+ often large and slow SW libraries the compiler substitutes if
+ there is no floating-point HW.
+ The only effect on QCBOR features
+ is that floating-point epoch date formats will result in a decoding error. Disabling
+ this reduces QCBOR in size by very little, but reduces
+ the overall executable size a lot on CPUs with no floating-point
+ HW by avoiding the compiler-supplied SW libraries. Since
+ floaing-point dates are not a very necessary feature, it
+ is advisable to define this on CPUs with no floating-point HW.
+
+
+
+ If you are running on a CPU with no floating point HW and you
+ don't need floating point date support, definitely disable XXX. If
+ you don't the compiler is likely to bring in large SW libraries
+ to provide the functions the HW does not.
+
+ If you want to save object ocde by disabling preferred encoding
+ of floats turn off QCBOR_DISABLE_PREFERRED_FLOAT. Note that this doesn't use floating point
+ HW so it is OK to leave enabled on CPUs with no floating
+ point support if you don't mind the extra 300 bytes of object
+ code on the decode side. On the encode side the floating
+ point code will be dead-stripped if not used.
+
+ Float features
+ - preferred encoding, encode side
+ - preferred encoding, decode side
+ - floating-point dates
+
+
+ Two modes?
+
+ disable use of preferred encoding / decoding and half precision support? This still
+ needs no floating point HW or SW.
+
+
+
+
+ TODO: -------
+
+
+
+
Summary Limits of this implementation:
- The entire encoded CBOR must fit into contiguous memory.
- Max size of encoded / decoded CBOR data is @c UINT32_MAX (4GB).
@@ -475,6 +647,15 @@
static void QCBOREncode_AddDoubleToMapN(QCBOREncodeContext *pCtx, int64_t nLabel, double dNum);
+void QCBOREncode_AddFloat(QCBOREncodeContext *pCtx, float dNum);
+
+
+
+void QCBOREncode_AddDoubleNoPreferred(QCBOREncodeContext *pCtx, double dNum);
+
+void QCBOREncode_AddFloatNoPreferred(QCBOREncodeContext *pCtx, float dNum);
+
+
/**
@brief Add an optional tag.
@@ -1581,6 +1762,18 @@
QCBOREncode_AddDouble(pCtx, dNum);
}
+static inline void QCBOREncode_AddFloatToMap(QCBOREncodeContext *pCtx, const char *szLabel, float dNum)
+{
+ QCBOREncode_AddSZString(pCtx, szLabel);
+ QCBOREncode_AddFloat(pCtx, dNum);
+}
+
+static inline void QCBOREncode_AddFloatToMapN(QCBOREncodeContext *pCtx, int64_t nLabel, float fNum)
+{
+ QCBOREncode_AddInt64(pCtx, nLabel);
+ QCBOREncode_AddFloat(pCtx, fNum);
+}
+
static inline void QCBOREncode_AddDateEpoch(QCBOREncodeContext *pCtx, int64_t date)
{