Looks like the right thing to do, Frank.  Do you intend to revise the RFC in some way to take account of this (in case the previously mentioned payload bridge developers refer to that for a reference with regard to the preferred getter / setter methods)?

 

Nigel

 

---

Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Frank Quinn
Sent: Wednesday, February 15, 2017 7:54 PM
To: openmama-dev
Subject: [Openmama-dev] Extended MAMA DateTime Further Modifications

 

Hi Folks,

I tried running the recent extended MAMA Date Time unit tests on windows after some of my suggested changes were made (https://github.com/OpenMAMA/OpenMAMA/pull/245) and got some suspicious errors.

On closer inspection it looks like there is an issue with our original assessment specifically on windows. The RFC revolved around the assumption that windows uses the posix definition of timeval where tv_sec was a time_t and tv_usec was a long, but it turns out that windows has a subtly different definition of timeval where both struct members are in fact long ints... which on windows (both 32 and 64 bit) is in fact 4 bytes. Linux is fine though as are the internal data structures so it's mostly OK but it means the existing timeval based functions will be insufficient for extended ranges on windows.

With that in mind I am going to suggest that a new interface is made available in addition to those in the existing implementation

mama_status

mamaDateTime_setFromStructTimeSpec(const mamaDateTime dateTime,

                                   struct timespec*   inputTimeVal);

mama_status

mamaDateTime_getStructTimeSpec(const mamaDateTime dateTime,

                               struct timespec*   result);

They're pretty much identical to the existing timeval based functions but with timespec instead and their implementation should very very straightforward based on what's already there so in terms of code it's a small change.

An explicit definition of timespec can then be defined in port.h for versions of MSVC which don't define it. It'll also mean that we effectively add support in the interface for nanosecond support in case anyone wants to support that too.

Raising it with the list to make everyone aware because these new functions should be the preferred methods for payload bridge developers to use if they want to support extended ranges properly on both windows and linux.

Cheers,

Frank

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev