#32 32-bit int display without QUAD_SUPPORT

[Matt Weber]

See attached for fix.

[Robert McMahon]

I'm confused. I thought the PRIdMAX would resolve to a 32bit specifier on 32bit systems and 64bit specifier on 64bit systems negating the need for the QUAD_SUPPORT tests. Is the QUAD_SUPPORT test acting as a proxy for the PRIdMAX macro, i.e. all systems don't support these?

Bob

[Matt Weber]

the issue is not with the inttypes macros, but rather with the assumptions
around the definition of max_size_t. Perhaps this patch bandages a
problem, but on our ARM cortex A7 platform, printf is expecting 64-bit
integers and max_size_t is 32-bit integer type. For the sake of my
development the formatting change was more innocuous than fixing the
typedef.

On Dec 7, 2017 3:55 AM, "Robert McMahon" rjmcmahon@users.sf.net wrote:

I'm confused. I thought the PRIdMAX would resolve to a 32bit specifier on
32bit systems and 64bit specifier on 64bit systems negating the need for
the QUAD_SUPPORT tests. Is the QUAD_SUPPORT test acting as a proxy for the
PRIdMAX macro, i.e. all systems don't support these?

Bob

• [tickets:#32] https://sourceforge.net/p/iperf2/tickets/32/ 32-bit int
  display without QUAD_SUPPORT*

Status: accepted
Milestone: 2.0
Created: Wed Dec 06, 2017 01:40 PM UTC by Matt Weber
Last Updated: Wed Dec 06, 2017 11:43 PM UTC
Owner: nobody
Attachments:

• 0001-Resolve-32-bit-int-display-without-QUAD_SUPPORT.patch
  https://sourceforge.net/p/iperf2/tickets/32/attachment/0001-Resolve-32-bit-int-display-without-QUAD_SUPPORT.patch
  (2.6 kB; text/x-patch)

See attached for proposed fix.

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/iperf2/tickets/32/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Robert McMahon]

The definition of the stats are max_size_t sot if that's resolving to 32b then the formatter specifier should also be 32b. I still don't see how this patch fixes the issue

From include/Reporter.h

typedef struct Transfer_Info {
    void *reserved_delay;
    int transferID;
    int groupID;
    max_size_t cntError;
    max_size_t cntOutofOrder;
    max_size_t cntDatagrams;
    max_size_t IPGcnt;
    int socket;
    TransitStat

Bob

[Maury Anderson]

Hi Bob,

I'm wondering if intmax_t and uintmax_t from stdint.h could be used here. According to comments in inttypes.h PRIdMAX is written around those. Then stdint.h is doing the heavy lifting for platform portability. Or is the intent to work prior to C99?

This worked in the ARM environment...

diff --git a/include/headers.h b/include/headers.h
index 7e43b44..666df8b 100644
--- a/include/headers.h
+++ b/include/headers.h
@@ -211,13 +211,8 @@ typedef long long max_size_t;
 typedef unsigned long long umax_size_t;
 #endif // 64
 #else
-#ifdef HAVE_INT32_T
-typedef int32_t max_size_t;
-typedef u_int32_t umax_size_t;
-#else
-typedef long max_size_t;
-typedef unsigned long umax_size_t;
-#endif // 32
+typedef intmax_t max_size_t;
+typedef uintmax_t umax_size_t;
 #endif
 /* in case the OS doesn't have these, we provide our own implementations */
 #include "gettimeofday.h"

Thanks,
Maury

[Robert McMahon]

Hi Maury,

I don't know of a reason to stick with C99. We need a compatible solutions and stdint.h seems fine to me. Let me compile on the various platforms and see what happens.

Also, The PRIdMax probably needs to go to PRId64 so the server's final report sent to the client withing the UDP fin ack, is specified properly by the client's reporter.

Thanks,
Bob

[Matt Weber]

Updated patch against latest codebase.

[Robert McMahon]

FYI, here's the fix we chose for this that should be the most conservative.

Bob