| 1 | /* Offset types for GDB. |
| 2 | |
| 3 | Copyright (C) 2017-2021 Free Software Foundation, Inc. |
| 4 | |
| 5 | This file is part of GDB. |
| 6 | |
| 7 | This program is free software; you can redistribute it and/or modify |
| 8 | it under the terms of the GNU General Public License as published by |
| 9 | the Free Software Foundation; either version 3 of the License, or |
| 10 | (at your option) any later version. |
| 11 | |
| 12 | This program is distributed in the hope that it will be useful, |
| 13 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 14 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 15 | GNU General Public License for more details. |
| 16 | |
| 17 | You should have received a copy of the GNU General Public License |
| 18 | along with this program. If not, see <http://www.gnu.org/licenses/>. */ |
| 19 | |
| 20 | /* Define an "offset" type. Offset types are distinct integer types |
| 21 | that are used to represent an offset into anything that is |
| 22 | addressable. For example, an offset into a DWARF debug section. |
| 23 | The idea is catch mixing unrelated offset types at compile time, in |
| 24 | code that needs to manipulate multiple different kinds of offsets |
| 25 | that are easily confused. They're safer to use than native |
| 26 | integers, because they have no implicit conversion to anything. |
| 27 | And also, since they're implemented as "enum class" strong |
| 28 | typedefs, they're still integers ABI-wise, making them a bit more |
| 29 | efficient than wrapper structs on some ABIs. |
| 30 | |
| 31 | Some properties of offset types, loosely modeled on pointers: |
| 32 | |
| 33 | - You can compare offsets of the same type for equality and order. |
| 34 | You can't compare an offset with an unrelated type. |
| 35 | |
| 36 | - You can add/substract an integer to/from an offset, which gives |
| 37 | you back a shifted offset. |
| 38 | |
| 39 | - You can subtract two offsets of the same type, which gives you |
| 40 | back the delta as an integer (of the enum class's underlying |
| 41 | type), not as an offset type. |
| 42 | |
| 43 | - You can't add two offsets of the same type, as that would not |
| 44 | make sense. |
| 45 | |
| 46 | However, unlike pointers, you can't deference offset types. */ |
| 47 | |
| 48 | #ifndef COMMON_OFFSET_TYPE_H |
| 49 | #define COMMON_OFFSET_TYPE_H |
| 50 | |
| 51 | /* Declare TYPE as being an offset type. This declares the type and |
| 52 | enables the operators defined below. */ |
| 53 | #define DEFINE_OFFSET_TYPE(TYPE, UNDERLYING) \ |
| 54 | enum class TYPE : UNDERLYING {}; \ |
| 55 | void is_offset_type (TYPE) |
| 56 | |
| 57 | /* The macro macro is all you need to know use offset types. The rest |
| 58 | below is all implementation detail. */ |
| 59 | |
| 60 | /* For each enum class type that you want to support arithmetic |
| 61 | operators, declare an "is_offset_type" overload that has exactly |
| 62 | one parameter, of type that enum class. E.g.,: |
| 63 | |
| 64 | void is_offset_type (sect_offset); |
| 65 | |
| 66 | The function does not need to be defined, only declared. |
| 67 | DEFINE_OFFSET_TYPE declares this. |
| 68 | |
| 69 | A function declaration is preferred over a traits type, because the |
| 70 | former allows calling the DEFINE_OFFSET_TYPE macro inside a |
| 71 | namespace to define the corresponding offset type in that |
| 72 | namespace. The compiler finds the corresponding is_offset_type |
| 73 | function via ADL. |
| 74 | */ |
| 75 | |
| 76 | /* Adding or subtracting an integer to an offset type shifts the |
| 77 | offset. This is like "PTR = PTR + INT" and "PTR += INT". */ |
| 78 | |
| 79 | #define DEFINE_OFFSET_ARITHM_OP(OP) \ |
| 80 | template<typename E, \ |
| 81 | typename = decltype (is_offset_type (std::declval<E> ()))> \ |
| 82 | constexpr E \ |
| 83 | operator OP (E lhs, typename std::underlying_type<E>::type rhs) \ |
| 84 | { \ |
| 85 | using underlying = typename std::underlying_type<E>::type; \ |
| 86 | return (E) (static_cast<underlying> (lhs) OP rhs); \ |
| 87 | } \ |
| 88 | \ |
| 89 | template<typename E, \ |
| 90 | typename = decltype (is_offset_type (std::declval<E> ()))> \ |
| 91 | constexpr E \ |
| 92 | operator OP (typename std::underlying_type<E>::type lhs, E rhs) \ |
| 93 | { \ |
| 94 | using underlying = typename std::underlying_type<E>::type; \ |
| 95 | return (E) (lhs OP static_cast<underlying> (rhs)); \ |
| 96 | } \ |
| 97 | \ |
| 98 | template<typename E, \ |
| 99 | typename = decltype (is_offset_type (std::declval<E> ()))> \ |
| 100 | E & \ |
| 101 | operator OP ## = (E &lhs, typename std::underlying_type<E>::type rhs) \ |
| 102 | { \ |
| 103 | using underlying = typename std::underlying_type<E>::type; \ |
| 104 | lhs = (E) (static_cast<underlying> (lhs) OP rhs); \ |
| 105 | return lhs; \ |
| 106 | } |
| 107 | |
| 108 | DEFINE_OFFSET_ARITHM_OP(+) |
| 109 | DEFINE_OFFSET_ARITHM_OP(-) |
| 110 | |
| 111 | /* Adding two offset types doesn't make sense, just like "PTR + PTR" |
| 112 | doesn't make sense. This is defined as a deleted function so that |
| 113 | a compile error easily brings you to this comment. */ |
| 114 | |
| 115 | template<typename E, |
| 116 | typename = decltype (is_offset_type (std::declval<E> ()))> |
| 117 | constexpr typename std::underlying_type<E>::type |
| 118 | operator+ (E lhs, E rhs) = delete; |
| 119 | |
| 120 | /* Subtracting two offset types, however, gives you back the |
| 121 | difference between the offsets, as an underlying type. Similar to |
| 122 | how "PTR2 - PTR1" returns a ptrdiff_t. */ |
| 123 | |
| 124 | template<typename E, |
| 125 | typename = decltype (is_offset_type (std::declval<E> ()))> |
| 126 | constexpr typename std::underlying_type<E>::type |
| 127 | operator- (E lhs, E rhs) |
| 128 | { |
| 129 | using underlying = typename std::underlying_type<E>::type; |
| 130 | return static_cast<underlying> (lhs) - static_cast<underlying> (rhs); |
| 131 | } |
| 132 | |
| 133 | #endif /* COMMON_OFFSET_TYPE_H */ |