Re: Expose 'array_length()' macro in or

[[ CC += libc-co...@sourceware.org CC += gcc@gcc.gnu.org CC += libstd...@gcc.gnu.org ]] Hi Florian, On 2020-09-21 10:38, Florian Weimer wrote: > * Alejandro Colomar via Libc-alpha: > >> I'd like to propose exposing the macro 'array_length()' as defined in >> 'include/array_length.h' to the user.

Re: Expose 'array_length()' macro in or

[[ CC += libc-coord at lists.openwall.com ]] On 2020-09-21 12:33, Florian Weimer wrote: * Alejandro Colomar: [[ CC += libc-coord at sourceware.org CC += gcc at gcc.gnu.org CC += libstdc++ at gcc.gnu.org ]] Hi Florian, On 2020-09-21 10:38, Florian Weimer wrote: * Alejandro Colomar via Libc-a

Re: Expose 'array_length()' macro in

I have developed this draft code, the C++ part being based on what you wrote. I am a C programmer, and my C++ is very basic, and I tend to write C-compatible code when I need C++, so I can't really write the C++ part. I tested the code with all C versions (--std= {c89, c99, c11, c18, c2x}),

Re: Expose 'array_length()' macro in

[[ CC += LKML ]] Thanks for all your input. I learned some C++ :) The following code works for all C and C++ standards: g++ --std={c++98, c++03, c++11, c++14, c++17, c++20} gcc --std={c89, c99, c11, c18, c2x} With `-Wall -Wextra -Werror -pedantic -Wno-vla -Wno-sizeof-pointer-div`. It doesn't co

Re: Expose 'array_length()' macro in

Thanks again for your improvements. I think this might be ready for a patch already. Any more thoughts? Thanks, Alex #if defined(__cplusplus) # include # if __cplusplus >= 201103L template constexpr inline std::size_t __array_length(const _Tp(&)[_Len]) __THROW {

[RFC] : Add nitems() and snitems() macros

'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfield - In C++: The template requires an array 'snitems()'

[PATCH v2] : Add nitems() and snitems() macros

'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfield - In C++: The template requires an array 'snitems()'

Re: [PATCH v2] : Add nitems() and snitems() macros

On 2020-09-25 15:20, Alejandro Colomar wrote: > 'nitems()' calculates the length of an array in number of items. > It is safe: if a pointer is passed to the macro (or function, in C++), > the compilation is broken due to: > - In >= C11: _Static_assert() > - In C89, C99: Negative anonymous b

Re: [PATCH v2] : Add nitems() and snitems() macros

Hello Jonathan, On 2020-09-25 16:48, Jonathan Wakely wrote: > Do you really need to provide snitems? > > Users can use (ptrdiff_t)nitems if needed, can't they? They can, but that adds casts in the code, which makes longer lines that are somewhat harder to read. To avoid that, users may sometimes

Re: [PATCH v2] : Add nitems() and snitems() macros

On 2020-09-25 19:39, Jonathan Wakely wrote: > Yes, I'm aware of all the rationale. I already said that it makes > sense in C++ where you have generic code. I am not convinced that it's > necessary to add to when all it does is a cast from > size_t to ptrdiff_t. > While I would prefer a signed

[PATCH v3] : Add nitems()

'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfield - In C++: The template requires an array Some BSDs a

[PATCH v4] : Add nitems()

'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfield - In C++: The template requires an array Some BSDs a

[PATCH 0/8] Add some types

Hi Michael, I started with types. I joined them by groups: intN_t instead of having an entry for each int8_t, int16_t, ... I think that way I could better explain the types, common things, differences, and exceptions. I'll wait until you review them to write about the remaining types: [u]int_le

[PATCH v2 0/8] Add some types

Hi Michael, I made a mistake when sending the emails, and I only CCd linux-man (and other lists) in PATCH 0/8. The rest were only sent to you. Actually, I was playing with the --cc option in git format-patch. I'm resending all of them as v2. I fixed a typo in 5/8, while the rest are all identic

[PATCH v2 2/8] intmax_t.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/intmax_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/intmax_t.3 diff --git a/man3/intmax_t.3 b/man3/intmax_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/intmax_t.3 @@ -0,0 +1 @@ +.so man7/system_data_ty

[PATCH v2 1/8] system_data_types.7: Add 'intmax_t'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 56 1 file changed, 56 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index fe6e90afe..e718b3c30 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 3/8] system_data_types.7: Add 'uintmax_t'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 55 1 file changed, 55 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index e718b3c30..2e7aca7d2 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 5/8] system_data_types.7: Add intN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 79 1 file changed, 79 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 2e7aca7d2..9b8244649 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 4/8] uintmax_t.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uintmax_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/uintmax_t.3 diff --git a/man3/uintmax_t.3 b/man3/uintmax_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uintmax_t.3 @@ -0,0 +1 @@ +.so man7/system_da

[PATCH v2 6/8] int8_t.3, int16_t.3, int32_t.3, int64_t.3, intN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/int16_t.3 | 1 + man3/int32_t.3 | 1 + man3/int64_t.3 | 1 + man3/int8_t.3 | 1 + man3/intN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int16_t.3 create mode 100644 man3/int32_t.3 create mode 100644 man3/int64_t.3 create mode

[PATCH v2 7/8] system_data_types.7: Add uintN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 82 1 file changed, 82 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 9b8244649..2f21e6849 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 8/8] uint8_t.3, uint16_t.3, uint32_t.3, uint64_t.3, uintN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uint16_t.3 | 1 + man3/uint32_t.3 | 1 + man3/uint64_t.3 | 1 + man3/uint8_t.3 | 1 + man3/uintN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint16_t.3 create mode 100644 man3/uint32_t.3 create mode 100644 man3/uint64_t.3 cre

Re: [PATCH v2 0/8] Add some types

D'oh! Now I had a typo when CCing myself :(

Re: [PATCH 0/8] Add some types

Hi Michael, On 2020-09-29 13:50, Michael Kerrisk (man-pages) wrote: > Hi Alex > > On Tue, 29 Sep 2020 at 10:26, Alejandro Colomar wrote: >> >> Hi Michael, >> >> I started with types. > > Good. I wanted those the other day :-), but then I saw they weren't in > the page yet! They were complica

Re: Expose 'array_length()' macro in or

On 2020-09-30 17:58, Joseph Myers wrote: For some reason http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2529.pdf doesn't seem to have reached the agenda of a WG14 meeting yet, but adding a language feature like that to the standard would be another approach. Hi Joseph, Yes, that would be

[RFC] man7/system_data_types.7: Document [unsigned] __int128

Hi, I'm documenting the system data types in the man-pages, and I was writing now about these types. I'm showing below both the rendered output and the source I have right now. Would you add anything to it? And I have some questions: Is 'signed __int128' a valid thing, and if so is it complet

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

Hi Jonathan, On 2020-10-01 11:57, Jonathan Wakely wrote: > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc wrote: >> >> Hi, >> >> I'm documenting the system data types in the man-pages, >> and I was writing now about these types. >> >>

[PATCH 00/16] Fixes; Document remaining stdint.h types

Hi Michael, Here are a few fixes (including one removing .br), and then the remaining stdint types. Cheers, Alex Alejandro Colomar (16): malloc_get_state.3: ffix system_data_types.7: srcfix system_data_types.7: srcfix system_data_types.7: srcfix system_data_types.7: Add int_fastN_t fa

[PATCH 03/16] system_data_types.7: srcfix

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index a653a7b11..a099c0250 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @

[PATCH 01/16] malloc_get_state.3: ffix

Signed-off-by: Alejandro Colomar --- man3/malloc_get_state.3 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man3/malloc_get_state.3 b/man3/malloc_get_state.3 index f94efccf4..57781fd6b 100644 --- a/man3/malloc_get_state.3 +++ b/man3/malloc_get_state.3 @@ -29,7 +29,7 @@ malloc

[PATCH 02/16] system_data_types.7: srcfix

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 105 ++- 1 file changed, 70 insertions(+), 35 deletions(-) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 9cf67ee6f..a653a7b11 100644 --- a/man7/system_data_types.7 +++ b/m

[PATCH 04/16] system_data_types.7: srcfix

We used .br to force a simple line break (with no extra blank line) after the tag. Recently, we added .RS/.RS, and .RS comes just after the tag, and I realized by accident that .RS already forces a simple line break. Therefore, .br is completely redundant here, and can be removed. This way we ge

[PATCH 07/16] system_data_types.7: Add uint_fastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 79 1 file changed, 79 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 07de6417f..e3ebc2270 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 06/16] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/int_fast16_t.3 | 1 + man3/int_fast32_t.3 | 1 + man3/int_fast64_t.3 | 1 + man3/int_fast8_t.3 | 1 + man3/int_fastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int_fast16_t.3 create mode 100644 man3/int_fast32_t.3 create mode

[PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 76 1 file changed, 76 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index a301c2309..07de6417f 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 08/16] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uint_fast16_t.3 | 1 + man3/uint_fast32_t.3 | 1 + man3/uint_fast64_t.3 | 1 + man3/uint_fast8_t.3 | 1 + man3/uint_fastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint_fast16_t.3 create mode 100644 man3/uint_fast32_t.3 crea

[PATCH 10/16] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/int_least16_t.3 | 1 + man3/int_least32_t.3 | 1 + man3/int_least64_t.3 | 1 + man3/int_least8_t.3 | 1 + man3/int_leastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int_least16_t.3 create mode 100644 man3/int_least32_t.3 crea

[PATCH 09/16] system_data_types.7: Add int_leastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 72 1 file changed, 72 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index e3ebc2270..0b8057087 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 11/16] system_data_types.7: Add uint_leastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 75 1 file changed, 75 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 0b8057087..f768e87ba 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 13/16] system_data_types.7: Add 'intptr_t'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 65 1 file changed, 65 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index f768e87ba..2632436ed 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 12/16] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uint_least16_t.3 | 1 + man3/uint_least32_t.3 | 1 + man3/uint_least64_t.3 | 1 + man3/uint_least8_t.3 | 1 + man3/uint_leastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint_least16_t.3 create mode 100644 man3/uint_least32_t.

[PATCH 14/16] intptr_t.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/intptr_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/intptr_t.3 diff --git a/man3/intptr_t.3 b/man3/intptr_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/intptr_t.3 @@ -0,0 +1 @@ +.so man7/system_data_ty

[PATCH 15/16] system_data_types.7: Add 'uintptr_t'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 68 1 file changed, 68 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 2632436ed..8884d3e18 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH 16/16] uintptr_t.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uintptr_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/uintptr_t.3 diff --git a/man3/uintptr_t.3 b/man3/uintptr_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uintptr_t.3 @@ -0,0 +1 @@ +.so man7/system_da

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

On 2020-10-01 13:07, Jonathan Wakely wrote: [...] +Notes: +Some of these types may be optimized for size +instead of raw performance. I'm not sure what this tells me as a programmer. What does "raw performance" means exactly? The text above says it's "the fastest", but then it says "may be o

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

Hi Jonathan, On 2020-10-01 12:50, Jonathan Wakely wrote: Ok, I thought that GCC is part of the GNU project, but I don't know how much... I'll use "When using GCC," :) It is, but the GNU project is a large organisation, and has nothing to say about non-standard types defined by GCC. Just becau

Re: [PATCH 00/16] Fixes; Document remaining stdint.h types

Hi Michael, I did it this way because then you have a clearly ordered list of the commits, and in which order they go, so I thought it might be easier for you (creating less conflicts). And also, I can hold any more recent patches, such as __int128, for when you finish applying the previous set,

Re: [PATCH 00/16] Fixes; Document remaining stdint.h types

Okay then :) Thanks, Alex On 2020-10-01 13:50, Michael Kerrisk (man-pages) wrote: Hi Alex, On 10/1/20 1:41 PM, Alejandro Colomar wrote: Hi Michael, I did it this way because then you have a clearly ordered list of the commits, and in which order they go, so I thought it might be easier for

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

On 2020-10-01 14:54, Szabolcs Nagy wrote: The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote: Here is the rendered intmax_t: intmax_t Include: . Alternatively, . A signed integer type capable of representing any value of any signed integer type supported by the

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

On 2020-10-01 13:27, Jonathan Wakely wrote: How would you word that? I gave a suggestion above. Oops, I missed that. Thanks, Alex

[PATCH v2 0/4] Document [u]int_fastN_t

This patches are the v2 of the patches 5 to 8 of a previous patchset: https://lore.kernel.org/linux-man/886f5647-2911-951a-b62a-4f9b1ed88...@gmail.com/T/#t Alejandro Colomar (4): system_data_types.7: Add int_fastN_t family of types int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,

[PATCH v2 1/4] system_data_types.7: Add int_fastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 77 1 file changed, 77 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 4645ed5f4..c5d0b700d 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 3/4] system_data_types.7: Add uint_fastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 80 1 file changed, 80 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index c5d0b700d..c130b7256 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 2/4] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/int_fast16_t.3 | 1 + man3/int_fast32_t.3 | 1 + man3/int_fast64_t.3 | 1 + man3/int_fast8_t.3 | 1 + man3/int_fastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int_fast16_t.3 create mode 100644 man3/int_fast32_t.3 create mode

[PATCH v2 4/4] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uint_fast16_t.3 | 1 + man3/uint_fast32_t.3 | 1 + man3/uint_fast64_t.3 | 1 + man3/uint_fast8_t.3 | 1 + man3/uint_fastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint_fast16_t.3 create mode 100644 man3/uint_fast32_t.3 crea

[PATCH v2 2/4] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/int_least16_t.3 | 1 + man3/int_least32_t.3 | 1 + man3/int_least64_t.3 | 1 + man3/int_least8_t.3 | 1 + man3/int_leastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int_least16_t.3 create mode 100644 man3/int_least32_t.3 crea

[PATCH v2 0/4] Document [u]int_leastN_t

This patches are the v2 of the patches 9 to 12 of a previous patchset: https://lore.kernel.org/linux-man/886f5647-2911-951a-b62a-4f9b1ed88...@gmail.com/T/#t Alejandro Colomar (4): system_data_types.7: Add int_leastN_t family of types int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least6

[PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 72 1 file changed, 72 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index c130b7256..3336de463 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 3/4] system_data_types.7: Add uint_leastN_t family of types

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 75 1 file changed, 75 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 3336de463..e42cf2557 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_t

[PATCH v2 4/4] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/uint_least16_t.3 | 1 + man3/uint_least32_t.3 | 1 + man3/uint_least64_t.3 | 1 + man3/uint_least8_t.3 | 1 + man3/uint_leastN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint_least16_t.3 create mode 100644 man3/uint_least32_t.

[PATCH 0/2] Document void *

Hello Michael, This type is very special, so I will probably have missed some details about it. Also, do you like the link name? For anyone reading this, please comment :) Cheers, Alex Alejandro Colomar (2): system_data_types.7: Add 'void *' void-*.3: New link to system_data_types(7) ma

[PATCH 1/2] system_data_types.7: Add 'void *'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 42 ++-- 1 file changed, 40 insertions(+), 2 deletions(-) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index e42cf2557..f10f12754 100644 --- a/man7/system_data_types.7 +++ b/ma

[PATCH 2/2] void-*.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/void-*.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/void-*.3 diff --git a/man3/void-*.3 b/man3/void-*.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/void-*.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 --

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

On 2020-10-01 13:07, Jonathan Wakely wrote: I don't see anything in this man page saying that the types are all typedefs, rather than new types that are distinct from the standard integer types. That seems like useful information. Hello Jonathan, I almost missed this. We (Michael and I

Re: [PATCH 0/2] Document void *

Hi Michael, On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote: Hello Alex, On 10/1/20 5:06 PM, Alejandro Colomar wrote: Hello Michael, This type is very special, so I will probably have missed some details about it. I do wonder if we actually need this in page at all, and given: I t

[PATCH v2 1/2] system_data_types.7: Add 'void *'

Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 47 ++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index e42cf2557..e545aa1a0 100644 --- a/man7/system_data_types.7 +++ b/ma

[PATCH v2 2/2] void.3: New link to system_data_types(7)

Signed-off-by: Alejandro Colomar --- man3/void.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/void.3 diff --git a/man3/void.3 b/man3/void.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/void.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 -- 2.28.0

[PATCH v2 0/2] Document 'void *'

I added a paragraph about not being able to dereference a void *, and changed the link page, which was very weird. Alejandro Colomar (2): system_data_types.7: Add 'void *' void.3: New link to system_data_types(7) man3/void.3 | 1 + man7/system_data_types.7 | 47

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote: Hi Alex, +According to the C language standard, +a pointer to any object type may be converted to a pointer to +.I void +and back. +POSIX further requires that any pointer, +including pointers to functions, +may be converted to a pointe

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

s. On 2020-10-01 19:31, Joseph Myers wrote: On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote: Because 'intmax_t' has a bug (actually I know GCC rejected the bug report, but the problem is still there and users should be informed about this) which is related to __int128. __int1

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

Hi Paul, On 2020-10-01 19:32, Paul Eggert wrote: > If you're going to document this at all, I suggest documenting 'void' as > well as 'void *', and putting both sets of documentation into the same > man page. > All the types we're documenting are in the same page: system_data_types(7). And then

Re: [PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types

Hi Paul, On 2020-10-01 19:38, Paul Eggert wrote: > On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote: >> +The narrowest signed integer type >> +of a width of at least N bits, > > Motivation is missing here. Why is there an int_leastN_t type at all? Well, I'd say the motivation is for th

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

Hi Michael, On 2020-10-02 10:24, Alejandro Colomar wrote: On 2020-10-01 19:32, Paul Eggert wrote: > For 'void *' you should also mention that one cannot use arithmetic on > void * pointers, so they're special in that way too. Good suggestion! > Also, you should > warn that because one can

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

On 2020-10-02 15:06, Jonathan Wakely wrote: > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) > wrote: >> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: >>> >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: >>

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

9, Jonathan Wakely wrote: >>> >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: >>>> However, it might be good that someone starts a page called >>>> 'type_qualifiers(7)' or something like that. >>> >>> W

Re: Navigational corrections

ote: >>>> >>>> >>>> >>>> On 2020-10-02 15:06, Jonathan Wakely wrote: >>>>> On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) >>>>> wrote: >>>> >> >>>>>&g

Re: Navigational corrections

Hi Michael, On 2020-10-03 13:39, Michael Kerrisk (man-pages) wrote: Hi Alex, [...] off_t would be great. In case you are looking for some other candidates, some others that I would be interested to see go into the page would be fd_set clock_t clockid_t and probably dev_t Great! off_t is

Ping: Re: [PATCH v4] : Add nitems()

Ping. On 2020-09-28 21:12, Alejandro Colomar wrote: 'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfie

Ping(2): [PATCH v4] : Add nitems()

Ping On 2020-09-28 21:12, Alejandro Colomar wrote: 'nitems()' calculates the length of an array in number of items. It is safe: if a pointer is passed to the macro (or function, in C++), the compilation is broken due to: - In >= C11: _Static_assert() - In C89, C99: Negative anonymous bitfiel

Ping(3): [PATCH v4] : Add nitems()

Hi, Do you think the patch is ready, or is there anything else I should do before merging it? Thanks, Alex On 9/28/20 9:12 PM, Alejandro Colomar wrote: > 'nitems()' calculates the length of an array in number of items. > It is safe: if a pointer is passed to the macro (or function, in C++), > t

Re: Ping(3): [PATCH v4] : Add nitems()

Hi Joseph, On 11/17/20 11:44 PM, Joseph Myers wrote: > I've asked the WG14 reflector why N2529 (and N2530, though that one's not > relevant to this feature) doesn't seem to have made it onto a meeting > agenda yet, when there have been two WG14 meetings since that proposal was > made and a third o

Re: Ping(3): [PATCH v4] : Add nitems()

On 11/18/20 12:11 AM, Joseph Myers wrote: > On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote: > >> Nice! >> Please update me on any feedback you receive. > > Apparently the author is planning new versions of those papers so WG14 > discussion is waiting for those. > >> So glibc wil

[PATCH] [Bug 215844] scanf.3: Clarify ll and L modifiers

Relevant documents: POSIX: glibc: ISO C2x: Still,

[C2x] Disallow function attributes after function identifier

Hi, Joseph! I'd like to suggest a change in C2x regarding attributes. Right now, the draft allows function attributes to go right at the beginning of a function prototype, or just before the opening parenthesis: [[attr]] type f(params); type f [[attr]](params); I'd argue against the second o

Re: [C2x] Disallow function attributes after function identifier

[I reordered some of your answers, to better answer] Hi Jakub, On 6/10/22 23:16, Jakub Jelinek wrote: On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote: So, could you please drop that from C2x? No! [[attr0]] void foo (void), bar (void); appertains to both

Re: [C2x] Disallow function attributes after function identifier

Hi Joseph, On 6/10/22 23:09, Joseph Myers wrote: P.S.: The latest draft that I know of is N2731. I guess there are newer ones. Could you please name the latest one? It's N2912 (June 8 version - the version originally published on June 7 had various problems; there are still some issues, espec

Re: [C2x] Disallow function attributes after function identifier

Hi Jonathan, On 6/11/22 00:47, Jonathan Wakely wrote: Well, I'd argue the same reasons to remove it from C++.  Don't know how useful that feature is for C++, though.  I bet not much, but am not an expert in the language. It's used in libstdc++ because I couldn't get an attribute to

Re: [C2x] Disallow function attributes after function identifier

On 6/11/22 14:08, Gabriel Ravier wrote: > Do we want to add a completely unnecessary feature, just for symmetry with C++, even if it poses a danger of breaking (both human and script) readability of function declarations/definitions, especially when hidden in macros? I actually don't get th

man-pages futex(2) example program using _Atomic

Hi, The man-pages example program for the futex(2) page uses atomic_compare_exchange_strong(), but it seems to use it incorrectly, according to clang-tidy(1) (see below). I've neved used _Atomic, and so I'm not confident in fixing the program. Would you mind having a look at it and possibly

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi JeanHeyd, Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters Date: Fri, 2 Sep 2022 16:56:00 -0400 From: JeanHeyd Meneide To: Alejandro Colomar CC: Ingo Schwarze , linux-...@vger.kernel.org Hi Alejandro and Ingo,   Just chiming i

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin, On 9/3/22 14:47, Martin Uecker wrote: [...] GCC will warn if the bound is specified inconsistently between declarations and also emit warnings if it can see that a buffer which is passed is too small: https://godbolt.org/z/PsjPG1nv7 That's very good news! BTW, it's nice to see th

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin, On 9/3/22 16:35, Martin Uecker wrote: Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar: Hi Martin, On 9/3/22 14:47, Martin Uecker wrote: [...] GCC will warn if the bound is specified inconsistently between declarations and also emit warnings if it can see that a b

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Ingo, On 9/3/22 15:29, Ingo Schwarze wrote: the only point i strongly care about is this one: Manual pages should not use * non-standard syntax * non-portable syntax * ambiguous syntax (i.e. syntax that might have different meanings with different compilers or in different contexts

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin, On 9/3/22 17:31, Martin Uecker wrote: [...] But the recent discussion about presenting nonnull pointers as [static 1] is horrible. But let's wait till the future hopefully fixes this. yes, [static 1] is problematic because then the number can not be used as a bound anymore. My ex

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin, On 9/3/22 22:02, Alejandro Colomar wrote: We thought about using this syntax int foo(char buf[.n], int n); BTW, it would be useful if this syntax was accepted for void * too, especially since GNU C allows pointer arithmetic on void *. void *memmove(void dest[.n], const void

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin, On 9/3/22 17:31, Martin Uecker wrote: My experience is that if one wants to see something fixed, one has to push for it. Standardization is meant to standardize existing practice, so if we want to see this improved, we can not wait for this. I fully agree with you. I've been rumin

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On 11/10/22 01:06, Alejandro Colomar wrote: Hi Martin, On 9/3/22 17:31, Martin Uecker wrote: My experience is that if one wants to see something fixed, one has to push for it.  Standardization is meant to standardize existing practice, so if we want to see this improved, we can not wait for t

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Joseph and Martin! On 11/10/22 07:21, Martin Uecker wrote: Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers: On Thu, 10 Nov 2022, Joseph Myers wrote: On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote: I've shown the three kinds of prototypes that have been ch

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Branden! On 11/10/22 10:40, G. Branden Robinson wrote: Hi Alex, At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote: Now, I've released man-pages-6.01 very recently (just a few weeks ago), and I don't plan to release again in a year or two, so there's time to do the implementation in GCC.

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Joseph, On 11/11/22 00:19, Joseph Myers wrote: On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote: One problem with WG14 papers is that people put in too much, because the overhead is so high and the standard is not updated very often. It would be better to build such feature more incrementa

  1   2   3   >