Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
6 лет назад
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542
  1. /* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
  2. * All rights reserved.
  3. *
  4. * This package is an SSL implementation written
  5. * by Eric Young (eay@cryptsoft.com).
  6. * The implementation was written so as to conform with Netscapes SSL.
  7. *
  8. * This library is free for commercial and non-commercial use as long as
  9. * the following conditions are aheared to. The following conditions
  10. * apply to all code found in this distribution, be it the RC4, RSA,
  11. * lhash, DES, etc., code; not just the SSL code. The SSL documentation
  12. * included with this distribution is covered by the same copyright terms
  13. * except that the holder is Tim Hudson (tjh@cryptsoft.com).
  14. *
  15. * Copyright remains Eric Young's, and as such any Copyright notices in
  16. * the code are not to be removed.
  17. * If this package is used in a product, Eric Young should be given attribution
  18. * as the author of the parts of the library used.
  19. * This can be in the form of a textual message at program startup or
  20. * in documentation (online or textual) provided with the package.
  21. *
  22. * Redistribution and use in source and binary forms, with or without
  23. * modification, are permitted provided that the following conditions
  24. * are met:
  25. * 1. Redistributions of source code must retain the copyright
  26. * notice, this list of conditions and the following disclaimer.
  27. * 2. Redistributions in binary form must reproduce the above copyright
  28. * notice, this list of conditions and the following disclaimer in the
  29. * documentation and/or other materials provided with the distribution.
  30. * 3. All advertising materials mentioning features or use of this software
  31. * must display the following acknowledgement:
  32. * "This product includes cryptographic software written by
  33. * Eric Young (eay@cryptsoft.com)"
  34. * The word 'cryptographic' can be left out if the rouines from the library
  35. * being used are not cryptographic related :-).
  36. * 4. If you include any Windows specific code (or a derivative thereof) from
  37. * the apps directory (application code) you must include an acknowledgement:
  38. * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
  39. *
  40. * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
  41. * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  42. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  43. * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  44. * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  45. * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  46. * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  47. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  48. * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  49. * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  50. * SUCH DAMAGE.
  51. *
  52. * The licence and distribution terms for any publically available version or
  53. * derivative of this code cannot be changed. i.e. this code cannot simply be
  54. * copied and put under another distribution licence
  55. * [including the GNU Public Licence.] */
  56. #ifndef OPENSSL_HEADER_STACK_H
  57. #define OPENSSL_HEADER_STACK_H
  58. #include <openssl/base.h>
  59. #include <openssl/type_check.h>
  60. #if defined(__cplusplus)
  61. extern "C" {
  62. #endif
  63. // A stack, in OpenSSL, is an array of pointers. They are the most commonly
  64. // used collection object.
  65. //
  66. // This file defines macros for type safe use of the stack functions. A stack
  67. // of a specific type of object has type |STACK_OF(type)|. This can be defined
  68. // (once) with |DEFINE_STACK_OF(type)| and declared where needed with
  69. // |DECLARE_STACK_OF(type)|. For example:
  70. //
  71. // typedef struct foo_st {
  72. // int bar;
  73. // } FOO;
  74. //
  75. // DEFINE_STACK_OF(FOO);
  76. //
  77. // Although note that the stack will contain /pointers/ to |FOO|.
  78. //
  79. // A macro will be defined for each of the sk_* functions below. For
  80. // STACK_OF(FOO), the macros would be sk_FOO_new, sk_FOO_pop etc.
  81. // stack_free_func is a function that frees an element in a stack. Note its
  82. // actual type is void (*)(T *) for some T. Low-level |sk_*| functions will be
  83. // passed a type-specific wrapper to call it correctly.
  84. typedef void (*stack_free_func)(void *ptr);
  85. // stack_copy_func is a function that copies an element in a stack. Note its
  86. // actual type is T *(*)(T *) for some T. Low-level |sk_*| functions will be
  87. // passed a type-specific wrapper to call it correctly.
  88. typedef void *(*stack_copy_func)(void *ptr);
  89. // stack_cmp_func is a comparison function that returns a value < 0, 0 or > 0
  90. // if |*a| is less than, equal to or greater than |*b|, respectively. Note the
  91. // extra indirection - the function is given a pointer to a pointer to the
  92. // element. This differs from the usual qsort/bsearch comparison function.
  93. //
  94. // Note its actual type is int (*)(const T **, const T **). Low-level |sk_*|
  95. // functions will be passed a type-specific wrapper to call it correctly.
  96. typedef int (*stack_cmp_func)(const void **a, const void **b);
  97. // stack_st contains an array of pointers. It is not designed to be used
  98. // directly, rather the wrapper macros should be used.
  99. typedef struct stack_st {
  100. // num contains the number of valid pointers in |data|.
  101. size_t num;
  102. void **data;
  103. // sorted is non-zero if the values pointed to by |data| are in ascending
  104. // order, based on |comp|.
  105. int sorted;
  106. // num_alloc contains the number of pointers allocated in the buffer pointed
  107. // to by |data|, which may be larger than |num|.
  108. size_t num_alloc;
  109. // comp is an optional comparison function.
  110. stack_cmp_func comp;
  111. } _STACK;
  112. #define STACK_OF(type) struct stack_st_##type
  113. #define DECLARE_STACK_OF(type) STACK_OF(type);
  114. // These are the raw stack functions, you shouldn't be using them. Rather you
  115. // should be using the type stack macros implemented above.
  116. // sk_new creates a new, empty stack with the given comparison function, which
  117. // may be zero. It returns the new stack or NULL on allocation failure.
  118. OPENSSL_EXPORT _STACK *sk_new(stack_cmp_func comp);
  119. // sk_new_null creates a new, empty stack. It returns the new stack or NULL on
  120. // allocation failure.
  121. OPENSSL_EXPORT _STACK *sk_new_null(void);
  122. // sk_num returns the number of elements in |s|.
  123. OPENSSL_EXPORT size_t sk_num(const _STACK *sk);
  124. // sk_zero resets |sk| to the empty state but does nothing to free the
  125. // individual elements themselves.
  126. OPENSSL_EXPORT void sk_zero(_STACK *sk);
  127. // sk_value returns the |i|th pointer in |sk|, or NULL if |i| is out of
  128. // range.
  129. OPENSSL_EXPORT void *sk_value(const _STACK *sk, size_t i);
  130. // sk_set sets the |i|th pointer in |sk| to |p| and returns |p|. If |i| is out
  131. // of range, it returns NULL.
  132. OPENSSL_EXPORT void *sk_set(_STACK *sk, size_t i, void *p);
  133. // sk_free frees the given stack and array of pointers, but does nothing to
  134. // free the individual elements. Also see |sk_pop_free_ex|.
  135. OPENSSL_EXPORT void sk_free(_STACK *sk);
  136. // sk_pop_free_ex calls |free_func| on each element in the stack and then frees
  137. // the stack itself. Note this corresponds to |sk_FOO_pop_free|. It is named
  138. // |sk_pop_free_ex| as a workaround for existing code calling an older version
  139. // of |sk_pop_free|.
  140. OPENSSL_EXPORT void sk_pop_free_ex(_STACK *sk,
  141. void (*call_free_func)(stack_free_func,
  142. void *),
  143. stack_free_func free_func);
  144. // sk_insert inserts |p| into the stack at index |where|, moving existing
  145. // elements if needed. It returns the length of the new stack, or zero on
  146. // error.
  147. OPENSSL_EXPORT size_t sk_insert(_STACK *sk, void *p, size_t where);
  148. // sk_delete removes the pointer at index |where|, moving other elements down
  149. // if needed. It returns the removed pointer, or NULL if |where| is out of
  150. // range.
  151. OPENSSL_EXPORT void *sk_delete(_STACK *sk, size_t where);
  152. // sk_delete_ptr removes, at most, one instance of |p| from the stack based on
  153. // pointer equality. If an instance of |p| is found then |p| is returned,
  154. // otherwise it returns NULL.
  155. OPENSSL_EXPORT void *sk_delete_ptr(_STACK *sk, const void *p);
  156. // sk_find returns the first value in the stack equal to |p|. If a comparison
  157. // function has been set on the stack, equality is defined by it, otherwise
  158. // pointer equality is used. If the stack is sorted, then a binary search is
  159. // used, otherwise a linear search is performed. If a matching element is found,
  160. // its index is written to
  161. // |*out_index| (if |out_index| is not NULL) and one is returned. Otherwise zero
  162. // is returned.
  163. //
  164. // Note this differs from OpenSSL. The type signature is slightly different, and
  165. // OpenSSL's sk_find will implicitly sort |sk| if it has a comparison function
  166. // defined.
  167. OPENSSL_EXPORT int sk_find(const _STACK *sk, size_t *out_index, const void *p,
  168. int (*call_cmp_func)(stack_cmp_func, const void **,
  169. const void **));
  170. // sk_shift removes and returns the first element in the stack, or returns NULL
  171. // if the stack is empty.
  172. OPENSSL_EXPORT void *sk_shift(_STACK *sk);
  173. // sk_push appends |p| to the stack and returns the length of the new stack, or
  174. // 0 on allocation failure.
  175. OPENSSL_EXPORT size_t sk_push(_STACK *sk, void *p);
  176. // sk_pop returns and removes the last element on the stack, or NULL if the
  177. // stack is empty.
  178. OPENSSL_EXPORT void *sk_pop(_STACK *sk);
  179. // sk_dup performs a shallow copy of a stack and returns the new stack, or NULL
  180. // on error.
  181. OPENSSL_EXPORT _STACK *sk_dup(const _STACK *sk);
  182. // sk_sort sorts the elements of |sk| into ascending order based on the
  183. // comparison function. The stack maintains a |sorted| flag and sorting an
  184. // already sorted stack is a no-op.
  185. OPENSSL_EXPORT void sk_sort(_STACK *sk);
  186. // sk_is_sorted returns one if |sk| is known to be sorted and zero
  187. // otherwise.
  188. OPENSSL_EXPORT int sk_is_sorted(const _STACK *sk);
  189. // sk_set_cmp_func sets the comparison function to be used by |sk| and returns
  190. // the previous one.
  191. OPENSSL_EXPORT stack_cmp_func sk_set_cmp_func(_STACK *sk, stack_cmp_func comp);
  192. // sk_deep_copy performs a copy of |sk| and of each of the non-NULL elements in
  193. // |sk| by using |copy_func|. If an error occurs, |free_func| is used to free
  194. // any copies already made and NULL is returned.
  195. OPENSSL_EXPORT _STACK *sk_deep_copy(
  196. const _STACK *sk, void *(*call_copy_func)(stack_copy_func, void *),
  197. stack_copy_func copy_func, void (*call_free_func)(stack_free_func, void *),
  198. stack_free_func free_func);
  199. // Deprecated functions.
  200. // sk_pop_free behaves like |sk_pop_free_ex| but performs an invalid function
  201. // pointer cast. It exists because some existing callers called |sk_pop_free|
  202. // directly.
  203. //
  204. // TODO(davidben): Migrate callers to bssl::UniquePtr and remove this.
  205. OPENSSL_EXPORT void sk_pop_free(_STACK *sk, stack_free_func free_func);
  206. // Defining stack types.
  207. //
  208. // This set of macros is used to emit the typed functions that act on a
  209. // |STACK_OF(T)|.
  210. #if !defined(BORINGSSL_NO_CXX)
  211. extern "C++" {
  212. BSSL_NAMESPACE_BEGIN
  213. namespace internal {
  214. template <typename T>
  215. struct StackTraits {};
  216. }
  217. BSSL_NAMESPACE_END
  218. }
  219. #define BORINGSSL_DEFINE_STACK_TRAITS(name, type, is_const) \
  220. extern "C++" { \
  221. BSSL_NAMESPACE_BEGIN \
  222. namespace internal { \
  223. template <> \
  224. struct StackTraits<STACK_OF(name)> { \
  225. static constexpr bool kIsStack = true; \
  226. using Type = type; \
  227. static constexpr bool kIsConst = is_const; \
  228. }; \
  229. } \
  230. BSSL_NAMESPACE_END \
  231. }
  232. #else
  233. #define BORINGSSL_DEFINE_STACK_TRAITS(name, type, is_const)
  234. #endif
  235. #define BORINGSSL_DEFINE_STACK_OF_IMPL(name, ptrtype, constptrtype) \
  236. DECLARE_STACK_OF(name) \
  237. \
  238. typedef void (*stack_##name##_free_func)(ptrtype); \
  239. typedef ptrtype (*stack_##name##_copy_func)(ptrtype); \
  240. typedef int (*stack_##name##_cmp_func)(constptrtype *a, constptrtype *b); \
  241. \
  242. OPENSSL_INLINE void sk_##name##_call_free_func(stack_free_func free_func, \
  243. void *ptr) { \
  244. ((stack_##name##_free_func)free_func)((ptrtype)ptr); \
  245. } \
  246. \
  247. OPENSSL_INLINE void *sk_##name##_call_copy_func(stack_copy_func copy_func, \
  248. void *ptr) { \
  249. return (void *)((stack_##name##_copy_func)copy_func)((ptrtype)ptr); \
  250. } \
  251. \
  252. OPENSSL_INLINE int sk_##name##_call_cmp_func( \
  253. stack_cmp_func cmp_func, const void **a, const void **b) { \
  254. constptrtype a_ptr = (constptrtype)*a; \
  255. constptrtype b_ptr = (constptrtype)*b; \
  256. return ((stack_##name##_cmp_func)cmp_func)(&a_ptr, &b_ptr); \
  257. } \
  258. \
  259. OPENSSL_INLINE STACK_OF(name) * \
  260. sk_##name##_new(stack_##name##_cmp_func comp) { \
  261. return (STACK_OF(name) *)sk_new((stack_cmp_func)comp); \
  262. } \
  263. \
  264. OPENSSL_INLINE STACK_OF(name) *sk_##name##_new_null(void) { \
  265. return (STACK_OF(name) *)sk_new_null(); \
  266. } \
  267. \
  268. OPENSSL_INLINE size_t sk_##name##_num(const STACK_OF(name) *sk) { \
  269. return sk_num((const _STACK *)sk); \
  270. } \
  271. \
  272. OPENSSL_INLINE void sk_##name##_zero(STACK_OF(name) *sk) { \
  273. sk_zero((_STACK *)sk); \
  274. } \
  275. \
  276. OPENSSL_INLINE ptrtype sk_##name##_value(const STACK_OF(name) *sk, \
  277. size_t i) { \
  278. return (ptrtype)sk_value((const _STACK *)sk, i); \
  279. } \
  280. \
  281. OPENSSL_INLINE ptrtype sk_##name##_set(STACK_OF(name) *sk, size_t i, \
  282. ptrtype p) { \
  283. return (ptrtype)sk_set((_STACK *)sk, i, (void *)p); \
  284. } \
  285. \
  286. OPENSSL_INLINE void sk_##name##_free(STACK_OF(name) * sk) { \
  287. sk_free((_STACK *)sk); \
  288. } \
  289. \
  290. OPENSSL_INLINE void sk_##name##_pop_free( \
  291. STACK_OF(name) * sk, stack_##name##_free_func free_func) { \
  292. sk_pop_free_ex((_STACK *)sk, sk_##name##_call_free_func, \
  293. (stack_free_func)free_func); \
  294. } \
  295. \
  296. OPENSSL_INLINE size_t sk_##name##_insert(STACK_OF(name) *sk, ptrtype p, \
  297. size_t where) { \
  298. return sk_insert((_STACK *)sk, (void *)p, where); \
  299. } \
  300. \
  301. OPENSSL_INLINE ptrtype sk_##name##_delete(STACK_OF(name) *sk, \
  302. size_t where) { \
  303. return (ptrtype)sk_delete((_STACK *)sk, where); \
  304. } \
  305. \
  306. OPENSSL_INLINE ptrtype sk_##name##_delete_ptr(STACK_OF(name) *sk, \
  307. constptrtype p) { \
  308. return (ptrtype)sk_delete_ptr((_STACK *)sk, (const void *)p); \
  309. } \
  310. \
  311. OPENSSL_INLINE int sk_##name##_find(const STACK_OF(name) *sk, \
  312. size_t * out_index, constptrtype p) { \
  313. return sk_find((const _STACK *)sk, out_index, (const void *)p, \
  314. sk_##name##_call_cmp_func); \
  315. } \
  316. \
  317. OPENSSL_INLINE ptrtype sk_##name##_shift(STACK_OF(name) *sk) { \
  318. return (ptrtype)sk_shift((_STACK *)sk); \
  319. } \
  320. \
  321. OPENSSL_INLINE size_t sk_##name##_push(STACK_OF(name) *sk, ptrtype p) { \
  322. return sk_push((_STACK *)sk, (void *)p); \
  323. } \
  324. \
  325. OPENSSL_INLINE ptrtype sk_##name##_pop(STACK_OF(name) *sk) { \
  326. return (ptrtype)sk_pop((_STACK *)sk); \
  327. } \
  328. \
  329. OPENSSL_INLINE STACK_OF(name) * sk_##name##_dup(const STACK_OF(name) *sk) { \
  330. return (STACK_OF(name) *)sk_dup((const _STACK *)sk); \
  331. } \
  332. \
  333. OPENSSL_INLINE void sk_##name##_sort(STACK_OF(name) *sk) { \
  334. sk_sort((_STACK *)sk); \
  335. } \
  336. \
  337. OPENSSL_INLINE int sk_##name##_is_sorted(const STACK_OF(name) *sk) { \
  338. return sk_is_sorted((const _STACK *)sk); \
  339. } \
  340. \
  341. OPENSSL_INLINE stack_##name##_cmp_func sk_##name##_set_cmp_func( \
  342. STACK_OF(name) *sk, stack_##name##_cmp_func comp) { \
  343. return (stack_##name##_cmp_func)sk_set_cmp_func((_STACK *)sk, \
  344. (stack_cmp_func)comp); \
  345. } \
  346. \
  347. OPENSSL_INLINE STACK_OF(name) * \
  348. sk_##name##_deep_copy(const STACK_OF(name) *sk, \
  349. ptrtype(*copy_func)(ptrtype), \
  350. void (*free_func)(ptrtype)) { \
  351. return (STACK_OF(name) *)sk_deep_copy( \
  352. (const _STACK *)sk, sk_##name##_call_copy_func, \
  353. (stack_copy_func)copy_func, sk_##name##_call_free_func, \
  354. (stack_free_func)free_func); \
  355. }
  356. // DEFINE_NAMED_STACK_OF defines |STACK_OF(name)| to be a stack whose elements
  357. // are |type| *.
  358. #define DEFINE_NAMED_STACK_OF(name, type) \
  359. BORINGSSL_DEFINE_STACK_OF_IMPL(name, type *, const type *) \
  360. BORINGSSL_DEFINE_STACK_TRAITS(name, type, false)
  361. // DEFINE_STACK_OF defines |STACK_OF(type)| to be a stack whose elements are
  362. // |type| *.
  363. #define DEFINE_STACK_OF(type) DEFINE_NAMED_STACK_OF(type, type)
  364. // DEFINE_CONST_STACK_OF defines |STACK_OF(type)| to be a stack whose elements
  365. // are const |type| *.
  366. #define DEFINE_CONST_STACK_OF(type) \
  367. BORINGSSL_DEFINE_STACK_OF_IMPL(type, const type *, const type *) \
  368. BORINGSSL_DEFINE_STACK_TRAITS(type, const type, true)
  369. // DEFINE_SPECIAL_STACK_OF defines |STACK_OF(type)| to be a stack whose elements
  370. // are |type|, where |type| must be a typedef for a pointer.
  371. #define DEFINE_SPECIAL_STACK_OF(type) \
  372. OPENSSL_STATIC_ASSERT(sizeof(type) == sizeof(void *), \
  373. #type " is not a pointer"); \
  374. BORINGSSL_DEFINE_STACK_OF_IMPL(type, type, const type)
  375. typedef char *OPENSSL_STRING;
  376. DEFINE_STACK_OF(void)
  377. DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING)
  378. #if defined(__cplusplus)
  379. } // extern C
  380. #endif
  381. #if !defined(BORINGSSL_NO_CXX)
  382. extern "C++" {
  383. #include <type_traits>
  384. BSSL_NAMESPACE_BEGIN
  385. namespace internal {
  386. // Stacks defined with |DEFINE_CONST_STACK_OF| are freed with |sk_free|.
  387. template <typename Stack>
  388. struct DeleterImpl<
  389. Stack, typename std::enable_if<StackTraits<Stack>::kIsConst>::type> {
  390. static void Free(Stack *sk) { sk_free(reinterpret_cast<_STACK *>(sk)); }
  391. };
  392. // Stacks defined with |DEFINE_STACK_OF| are freed with |sk_pop_free| and the
  393. // corresponding type's deleter.
  394. template <typename Stack>
  395. struct DeleterImpl<
  396. Stack, typename std::enable_if<!StackTraits<Stack>::kIsConst>::type> {
  397. static void Free(Stack *sk) {
  398. // sk_FOO_pop_free is defined by macros and bound by name, so we cannot
  399. // access it from C++ here.
  400. using Type = typename StackTraits<Stack>::Type;
  401. sk_pop_free_ex(reinterpret_cast<_STACK *>(sk),
  402. [](stack_free_func /* unused */, void *ptr) {
  403. DeleterImpl<Type>::Free(reinterpret_cast<Type *>(ptr));
  404. },
  405. nullptr);
  406. }
  407. };
  408. template <typename Stack>
  409. class StackIteratorImpl {
  410. public:
  411. using Type = typename StackTraits<Stack>::Type;
  412. // Iterators must be default-constructable.
  413. StackIteratorImpl() : sk_(nullptr), idx_(0) {}
  414. StackIteratorImpl(const Stack *sk, size_t idx) : sk_(sk), idx_(idx) {}
  415. bool operator==(StackIteratorImpl other) const {
  416. return sk_ == other.sk_ && idx_ == other.idx_;
  417. }
  418. bool operator!=(StackIteratorImpl other) const {
  419. return !(*this == other);
  420. }
  421. Type *operator*() const {
  422. return reinterpret_cast<Type *>(
  423. sk_value(reinterpret_cast<const _STACK *>(sk_), idx_));
  424. }
  425. StackIteratorImpl &operator++(/* prefix */) {
  426. idx_++;
  427. return *this;
  428. }
  429. StackIteratorImpl operator++(int /* postfix */) {
  430. StackIteratorImpl copy(*this);
  431. ++(*this);
  432. return copy;
  433. }
  434. private:
  435. const Stack *sk_;
  436. size_t idx_;
  437. };
  438. template <typename Stack>
  439. using StackIterator = typename std::enable_if<StackTraits<Stack>::kIsStack,
  440. StackIteratorImpl<Stack>>::type;
  441. } // namespace internal
  442. // PushToStack pushes |elem| to |sk|. It returns true on success and false on
  443. // allocation failure.
  444. template <typename Stack>
  445. inline
  446. typename std::enable_if<!internal::StackTraits<Stack>::kIsConst, bool>::type
  447. PushToStack(Stack *sk,
  448. UniquePtr<typename internal::StackTraits<Stack>::Type> elem) {
  449. if (!sk_push(reinterpret_cast<_STACK *>(sk), elem.get())) {
  450. return false;
  451. }
  452. // sk_push takes ownership on success.
  453. elem.release();
  454. return true;
  455. }
  456. BSSL_NAMESPACE_END
  457. // Define begin() and end() for stack types so C++ range for loops work.
  458. template <typename Stack>
  459. inline bssl::internal::StackIterator<Stack> begin(const Stack *sk) {
  460. return bssl::internal::StackIterator<Stack>(sk, 0);
  461. }
  462. template <typename Stack>
  463. inline bssl::internal::StackIterator<Stack> end(const Stack *sk) {
  464. return bssl::internal::StackIterator<Stack>(
  465. sk, sk_num(reinterpret_cast<const _STACK *>(sk)));
  466. }
  467. } // extern C++
  468. #endif
  469. #endif // OPENSSL_HEADER_STACK_H