-2

I want to convert the sint 64 bit data to uint 32 bit data, but C operators shall not be used for 64bit data (cast, arithmetic operators and comparison operators). This used in autosar EFX library function.

Tejas
  • 55
  • 8
  • Just cast it then? – Fredrik Dec 13 '18 at 06:23
  • It doesnt matter if you try to do it some other fancy way, you will always lose data when going from a 64 bit data type to a 32 one. – Fredrik Dec 13 '18 at 06:43
  • Thanks,,but as per rule it said cast , arithmetic and comparison operator should not be use to 64bit data.So I dont think cast can be used. – Tejas Dec 13 '18 at 07:01
  • What is the "it" which said that, and what did "it" say exactly, in context? – rici Dec 13 '18 at 07:03
  • Are you quoting a document for the statement "shall not be used" if so which one .., please update the question with this information. – Shafik Yaghmour Dec 13 '18 at 07:07
  • it refered as Autosar Specification of Extended Fixed Point Routines . I am looking for 64bit function in that. – Tejas Dec 13 '18 at 07:07
  • I am going to implement the math library as per Autosar Specification of Extended Fixed Point Routines. In which I face the problem for 64bit function for casting of 32bit data to 64bit data. I think question is clear now? – Tejas Dec 13 '18 at 07:13
  • @Fredrik we cant use arithmetic operation , so doing Anding is same ? – Tejas Dec 13 '18 at 07:16
  • Do a plain `memcpy` of the first or last 4 bytes, depending on endianness. – Matteo Italia Dec 13 '18 at 07:18
  • 5
    Why didn't you post the rule SWS_Efx_00416 from [AUTOSAR](https://www.autosar.org/fileadmin/user_upload/standards/classic/4-2/AUTOSAR_SWS_EFXLibrary.pdf) that said that? Why don't you use the `Efx_Cast_s64_u32`? There's a whole section 8.5.24.2 on casting 64 bit numbers to 32 and operators for 64bit datatypes. Cast to 32, then devide by 2^32 then cast to 32 again and you have low and high bytes of a 64 bit number. – KamilCuk Dec 13 '18 at 07:22
  • Also post the relevant code as an example. – Lundin Dec 13 '18 at 07:28

2 Answers2

3

I've never used AUTOSAR Specification of Extended Fixed Point Routines, but deducing from the documentation, it's just:

sint64 var = 5;
uint32 low, high;
low = Efx_Cast_s64_u32(var);
var = Efx_Div_s64u32_s64(var, UINT32_MAX);
high = Efx_Cast_s64_u32(var);

The Efx_Div_s64u32_s64(..., UINT32_MAX) serves as bit shift of 32 bits to the right, to fetch the higher 32 bits. The casts are done using proper functions.

The standard does say [SWS_Efx_00415] ⌈ C operators shall not be used for 64bit data (cast, arithmetic operators and comparison operators) ⌋ ( ), but it gives below all the functions needed to do the casting, arithmetic operations and comparisons operations. From the portability point of view, this is great, allows easy integration to platform without native 64bit datatype. From the programmer point of view - you have to use dedicated functions to access 64bit datatypes.

KamilCuk
  • 120,984
  • 8
  • 59
  • 111
  • I think, that the EFX SWS is written here in a confusing way. The 8.5.23.1 General Requirements is could be understood as requirements to users of EFX, but also as requirements of EFX itself. – kesselhaus Dec 30 '18 at 23:40
1

If you cannot touch the value using C operators in any way (why? are you sure you didn't misunderstand the requirements?), the only thing that remains is to copy the raw bytes.

If your platform is little-endian you can do a brutal memcpy of the first 4 bytes from the 64 bit integer to the 32 bit integer, or of the last 4 bytes if your platform is big endian. If it's mixed-endian (extremely rare) or if the 64 bit data has differing endianness (e.g. it is in "network order", differing from the native endianness of your machine) you'll have to copy in a different order, but it's nothing complex, you just have to figure out the byte ordering.

Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
  • 1
    …however, I suspect that this pointer juggling will _also_ be against the rules. –  Dec 13 '18 at 07:29
  • At least with a "conforming" implementation in would violate [C11 Standard - §6.5 Expressions (p6,7)](http://port70.net/~nsz/c/c11/n1570.html#6.5p6) (at least in intent, you could always go though and intervening `char *` or `unsigned char*` and mask the strict aliasing violation) – David C. Rankin Dec 13 '18 at 07:45
  • @DavidC.Rankin: there should be no strict aliasing violation, `memcpy` internally copies characters (at least conceptually) going through `unsigned char` pointers. See the intro to the "String function conventions" (C99 §7.21.1) and the `memcpy` function description (C99 §7.21.2.1). Indeed `memcpy` is quoted throughout the standard as an example mean to copy the underlying representation of values. – Matteo Italia Dec 13 '18 at 08:03
  • Yes, that is the purpose of the (at least in intent....). I haven't heard of AUTOSAR, so it may be some complete separate implementation defined package. There is no problem with byte-shift and OR, but the concern with violating the intent was the cast requirement in the question. Strange bird. – David C. Rankin Dec 13 '18 at 08:26
  • @Kamil Cuk Thanks Kamil, your suggestion really help,but if I use &(0xffffffff) it will also do casting. Can I do this. – Tejas Dec 14 '18 at 05:34