i Alex,
On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote:
> Hi all,
>
> v2:
>
> [
> NOTES
>Unless you need the finer grained control that this system
>call provides, you probably want to use the GCC built-in
>function __builtin___clear_cache(), which pr
Hello Vincent,
On Thu, 8 Oct 2020 at 15:52, Vincent Lefevre wrote:
>
> On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote:
> > On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote:
> > > > +According to the C language standard,
> > > > +a pointer to any object type may be converted t
On 10/6/20 12:08 AM, Alejandro Colomar wrote:
> 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 b
Hi Jonathan!
On 10/2/20 3:19 PM, Jonathan Wakely wrote:
> On Thu, 1 Oct 2020 at 16:51, Alejandro Colomar via Gcc
> wrote:
>>
>> 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,
Hi Alex,
> >
> > The question of 'void *' is an interesting one. It is something
> > like a fundamental C type, and not something that comes from POSIX.
> > But, it does appear in POSIX APIs and often details of using
> > the type are not well understood. So, as a matter of practicality,
>
Hi Alex, et al.
On 10/2/20 3:51 PM, Alejandro Colomar wrote:
>
> Hi Jonathan,
>
> On 2020-10-02 15:27, Jonathan Wakely wrote:
>> On Fri, 2 Oct 2020 at 14:20, Alejandro Colomar
>> wrote:
>>>
>>>
>>>
>>> On 2020-10-02 15:06, Jonathan Wakely wrote:
>>> > On Fri, 2 Oct 2020 at 12:31, Michael Kerr
Hi Alex,
On 10/1/20 6:55 PM, Alejandro Colomar wrote:
>
>
> 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
Hi Alex,
On 10/2/20 10:48 AM, Alejandro Colomar wrote:
> 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.
On Fri, 2 Oct 2020 at 12:49, 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.
>
> Who is this for? Who is trying to learn C from man pages? S
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 pointer to
> +.I void
> +and back.
I know you are corr
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:
> Also, do you like the link name?
I really don't like it... I don't
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> 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
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> 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(
Thanks, Alex. Applied.
On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> 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(+)
>
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> 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(+)
> crea
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> 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(+)
>
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> 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
Thanks, Alex. Applied.
On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> 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
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 you (creating less conflicts).
Yes, I understand the rationale. But when I ge
Applied.
On 10/1/20 12:16 PM, Alejandro Colomar wrote:
> 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..db50c0
Hi ALex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 68
> 1 file changed, 68 insertions(+)
Thanks. Patch applied.
Cheers,
Michael
> diff --git a/man7/system_data_types.7 b/man7
Hi Alex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 65
> 1 file changed, 65 insertions(+)
Thanks. Patch applied.
Cheers,
Michael
> diff --git a/man7/system_data_types.7 b/man7/s
Applied.
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> 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
Hi Alex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> 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,
Hi Alex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
Yeah, this layout is my preferred form as well.
Applied.
Thanks,
Michael
> diff --git a/man7/
Hi Alex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar
I don't mind applying this patch (and I have done so),
but I think patches like this need a brief commit message
to explain why you are making the change.
Thanks,
Michael
> ---
> man7/system_data_types
Applied.
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> 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/m
Hi Alex,
On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Hi Michael,
>
> Here are a few fixes (including one removing .br),
> and then the remaining stdint types.
These very long patch series are a bit overwhelming for me.
I'd have preferred a few smaller patch series. For example,
I think I wo
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!
> I joined them by groups:
> intN_t instead of having an entry for each int8_t, int16_t, ...
> I think t
29 matches
Mail list logo
