[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 family of types
  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)
  system_data_types.7: Add uint_fastN_t family of types
  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)
  system_data_types.7: Add int_leastN_t family of types
  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)
  system_data_types.7: Add uint_leastN_t family of types
  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)
  system_data_types.7: Add 'intptr_t'
  intptr_t.3: New link to system_data_types(7)
  system_data_types.7: Add 'uintptr_t'
  uintptr_t.3: New link to system_data_types(7)

 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 +
 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 +
 man3/intptr_t.3          |   1 +
 man3/malloc_get_state.3  |   2 +-
 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 +
 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 +
 man3/uintptr_t.3         |   1 +
 man7/system_data_types.7 | 590 ++++++++++++++++++++++++++++++++++-----
 24 files changed, 540 insertions(+), 74 deletions(-)
 create mode 100644 man3/int_fast16_t.3
 create mode 100644 man3/int_fast32_t.3
 create mode 100644 man3/int_fast64_t.3
 create mode 100644 man3/int_fast8_t.3
 create mode 100644 man3/int_fastN_t.3
 create mode 100644 man3/int_least16_t.3
 create mode 100644 man3/int_least32_t.3
 create mode 100644 man3/int_least64_t.3
 create mode 100644 man3/int_least8_t.3
 create mode 100644 man3/int_leastN_t.3
 create mode 100644 man3/intptr_t.3
 create mode 100644 man3/uint_fast16_t.3
 create mode 100644 man3/uint_fast32_t.3
 create mode 100644 man3/uint_fast64_t.3
 create mode 100644 man3/uint_fast8_t.3
 create mode 100644 man3/uint_fastN_t.3
 create mode 100644 man3/uint_least16_t.3
 create mode 100644 man3/uint_least32_t.3
 create mode 100644 man3/uint_least64_t.3
 create mode 100644 man3/uint_least8_t.3
 create mode 100644 man3/uint_leastN_t.3
 create mode 100644 man3/uintptr_t.3
  

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 would have preferred 3 series like this:

1-4
5-12
13-16

One reason is that the multiple parallel reply threads that 
sometimes occur can sometimes be rather difficult to track.
(Your patches have started some quite useful conversations!)

For example, I suspect Jonathan's comments may trigger changes
for patches 5-12.

For now, I'm applying 1-4 and 13-16. It looks like some reworking is
going to be needed for the others. When you do resubmit them, please
start a new thread (rather than replying into this thread).

Thanks,

Michael

> 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 family of types
>   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)
>   system_data_types.7: Add uint_fastN_t family of types
>   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)
>   system_data_types.7: Add int_leastN_t family of types
>   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)
>   system_data_types.7: Add uint_leastN_t family of types
>   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)
>   system_data_types.7: Add 'intptr_t'
>   intptr_t.3: New link to system_data_types(7)
>   system_data_types.7: Add 'uintptr_t'
>   uintptr_t.3: New link to system_data_types(7)
> 
>  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 +
>  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 +
>  man3/intptr_t.3          |   1 +
>  man3/malloc_get_state.3  |   2 +-
>  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 +
>  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 +
>  man3/uintptr_t.3         |   1 +
>  man7/system_data_types.7 | 590 ++++++++++++++++++++++++++++++++++-----
>  24 files changed, 540 insertions(+), 74 deletions(-)
>  create mode 100644 man3/int_fast16_t.3
>  create mode 100644 man3/int_fast32_t.3
>  create mode 100644 man3/int_fast64_t.3
>  create mode 100644 man3/int_fast8_t.3
>  create mode 100644 man3/int_fastN_t.3
>  create mode 100644 man3/int_least16_t.3
>  create mode 100644 man3/int_least32_t.3
>  create mode 100644 man3/int_least64_t.3
>  create mode 100644 man3/int_least8_t.3
>  create mode 100644 man3/int_leastN_t.3
>  create mode 100644 man3/intptr_t.3
>  create mode 100644 man3/uint_fast16_t.3
>  create mode 100644 man3/uint_fast32_t.3
>  create mode 100644 man3/uint_fast64_t.3
>  create mode 100644 man3/uint_fast8_t.3
>  create mode 100644 man3/uint_fastN_t.3
>  create mode 100644 man3/uint_least16_t.3
>  create mode 100644 man3/uint_least32_t.3
>  create mode 100644 man3/uint_least64_t.3
>  create mode 100644 man3/uint_least8_t.3
>  create mode 100644 man3/uint_leastN_t.3
>  create mode 100644 man3/uintptr_t.3
> 
H
  

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, so I fix the
conflicts before you ever see them.

Don't you think?

I don't mind fixing for example patch 5,
and then rebasing the rest (and also the patches I didn't send yet),
and resending them as an answer to v1 00/16.

But if you still prefer smaller sets, I'll send you smaller sets.

It's just that these patches are usually very dependent of the
previous ones, and therefore prone to conflicts if you
don't apply them in the same exact order.

Your thoughts?

Thanks,

Alex

On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:
> 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 would have preferred 3 series like this:
> 
> 1-4
> 5-12
> 13-16
> 
> One reason is that the multiple parallel reply threads that
> sometimes occur can sometimes be rather difficult to track.
> (Your patches have started some quite useful conversations!)
> 
> For example, I suspect Jonathan's comments may trigger changes
> for patches 5-12.
> 
> For now, I'm applying 1-4 and 13-16. It looks like some reworking is
> going to be needed for the others. When you do resubmit them, please
> start a new thread (rather than replying into this thread).
> 
> Thanks,
> 
> Michael
> 
>> 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 family of types
>>    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)
>>    system_data_types.7: Add uint_fastN_t family of types
>>    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)
>>    system_data_types.7: Add int_leastN_t family of types
>>    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)
>>    system_data_types.7: Add uint_leastN_t family of types
>>    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)
>>    system_data_types.7: Add 'intptr_t'
>>    intptr_t.3: New link to system_data_types(7)
>>    system_data_types.7: Add 'uintptr_t'
>>    uintptr_t.3: New link to system_data_types(7)
>>
>>   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 +
>>   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 +
>>   man3/intptr_t.3          |   1 +
>>   man3/malloc_get_state.3  |   2 +-
>>   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 +
>>   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 +
>>   man3/uintptr_t.3         |   1 +
>>   man7/system_data_types.7 | 590 ++++++++++++++++++++++++++++++++++-----
>>   24 files changed, 540 insertions(+), 74 deletions(-)
>>   create mode 100644 man3/int_fast16_t.3
>>   create mode 100644 man3/int_fast32_t.3
>>   create mode 100644 man3/int_fast64_t.3
>>   create mode 100644 man3/int_fast8_t.3
>>   create mode 100644 man3/int_fastN_t.3
>>   create mode 100644 man3/int_least16_t.3
>>   create mode 100644 man3/int_least32_t.3
>>   create mode 100644 man3/int_least64_t.3
>>   create mode 100644 man3/int_least8_t.3
>>   create mode 100644 man3/int_leastN_t.3
>>   create mode 100644 man3/intptr_t.3
>>   create mode 100644 man3/uint_fast16_t.3
>>   create mode 100644 man3/uint_fast32_t.3
>>   create mode 100644 man3/uint_fast64_t.3
>>   create mode 100644 man3/uint_fast8_t.3
>>   create mode 100644 man3/uint_fastN_t.3
>>   create mode 100644 man3/uint_least16_t.3
>>   create mode 100644 man3/uint_least32_t.3
>>   create mode 100644 man3/uint_least64_t.3
>>   create mode 100644 man3/uint_least8_t.3
>>   create mode 100644 man3/uint_leastN_t.3
>>   create mode 100644 man3/uintptr_t.3
>>
> H
>
  

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 get a series of
loosely related patches in a series of 20, and multiple
conversations start about independent topics, I'm finding
it quite some effort to keep track.

> And also, I can hold any more recent patches, such as __int128,
> for when you finish applying the previous set, so I fix the
> conflicts before you ever see them.
> 
> Don't you think?
> 
> I don't mind fixing for example patch 5,
> and then rebasing the rest (and also the patches I didn't send yet),
> and resending them as an answer to v1 00/16.
> 
> But if you still prefer smaller sets, I'll send you smaller sets.

I do prefer smaller sets. And yes, occasionally things may
go wrong in terms of patch conflicts, but I think that may be 
a smaller than the problem I note above.

> It's just that these patches are usually very dependent of the
> previous ones, and therefore prone to conflicts if you
> don't apply them in the same exact order.
> 
> Your thoughts?

As you can see, there's no perfect solution here. In such
situations what I try to do (where possible) is order the
patches from least contentious to most contentious.
That way, the patches that are almost certainly going to 
be applied are loaded at the front and the chance of having
to rebasing later patches in a series is lower.

Thanks,

Michael



> On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:
>> 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 would have preferred 3 series like this:
>>
>> 1-4
>> 5-12
>> 13-16
>>
>> One reason is that the multiple parallel reply threads that
>> sometimes occur can sometimes be rather difficult to track.
>> (Your patches have started some quite useful conversations!)
>>
>> For example, I suspect Jonathan's comments may trigger changes
>> for patches 5-12.
>>
>> For now, I'm applying 1-4 and 13-16. It looks like some reworking is
>> going to be needed for the others. When you do resubmit them, please
>> start a new thread (rather than replying into this thread).
>>
>> Thanks,
>>
>> Michael
>>
>>> 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 family of types
>>>    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)
>>>    system_data_types.7: Add uint_fastN_t family of types
>>>    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)
>>>    system_data_types.7: Add int_leastN_t family of types
>>>    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)
>>>    system_data_types.7: Add uint_leastN_t family of types
>>>    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)
>>>    system_data_types.7: Add 'intptr_t'
>>>    intptr_t.3: New link to system_data_types(7)
>>>    system_data_types.7: Add 'uintptr_t'
>>>    uintptr_t.3: New link to system_data_types(7)
>>>
>>>   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 +
>>>   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 +
>>>   man3/intptr_t.3          |   1 +
>>>   man3/malloc_get_state.3  |   2 +-
>>>   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 +
>>>   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 +
>>>   man3/uintptr_t.3         |   1 +
>>>   man7/system_data_types.7 | 590 ++++++++++++++++++++++++++++++++++-----
>>>   24 files changed, 540 insertions(+), 74 deletions(-)
>>>   create mode 100644 man3/int_fast16_t.3
>>>   create mode 100644 man3/int_fast32_t.3
>>>   create mode 100644 man3/int_fast64_t.3
>>>   create mode 100644 man3/int_fast8_t.3
>>>   create mode 100644 man3/int_fastN_t.3
>>>   create mode 100644 man3/int_least16_t.3
>>>   create mode 100644 man3/int_least32_t.3
>>>   create mode 100644 man3/int_least64_t.3
>>>   create mode 100644 man3/int_least8_t.3
>>>   create mode 100644 man3/int_leastN_t.3
>>>   create mode 100644 man3/intptr_t.3
>>>   create mode 100644 man3/uint_fast16_t.3
>>>   create mode 100644 man3/uint_fast32_t.3
>>>   create mode 100644 man3/uint_fast64_t.3
>>>   create mode 100644 man3/uint_fast8_t.3
>>>   create mode 100644 man3/uint_fastN_t.3
>>>   create mode 100644 man3/uint_least16_t.3
>>>   create mode 100644 man3/uint_least32_t.3
>>>   create mode 100644 man3/uint_least64_t.3
>>>   create mode 100644 man3/uint_least8_t.3
>>>   create mode 100644 man3/uint_leastN_t.3
>>>   create mode 100644 man3/uintptr_t.3
>>>
>> H
>>
  

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 you (creating less conflicts).
> 
> Yes, I understand the rationale. But when I get a series of
> loosely related patches in a series of 20, and multiple
> conversations start about independent topics, I'm finding
> it quite some effort to keep track.
> 
>> And also, I can hold any more recent patches, such as __int128,
>> for when you finish applying the previous set, so I fix the
>> conflicts before you ever see them.
>>
>> Don't you think?
>>
>> I don't mind fixing for example patch 5,
>> and then rebasing the rest (and also the patches I didn't send yet),
>> and resending them as an answer to v1 00/16.
>>
>> But if you still prefer smaller sets, I'll send you smaller sets.
> 
> I do prefer smaller sets. And yes, occasionally things may
> go wrong in terms of patch conflicts, but I think that may be
> a smaller than the problem I note above.
> 
>> It's just that these patches are usually very dependent of the
>> previous ones, and therefore prone to conflicts if you
>> don't apply them in the same exact order.
>>
>> Your thoughts?
> 
> As you can see, there's no perfect solution here. In such
> situations what I try to do (where possible) is order the
> patches from least contentious to most contentious.
> That way, the patches that are almost certainly going to
> be applied are loaded at the front and the chance of having
> to rebasing later patches in a series is lower.
> 
> Thanks,
> 
> Michael
> 
> 
> 
>> On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:
>>> 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 would have preferred 3 series like this:
>>>
>>> 1-4
>>> 5-12
>>> 13-16
>>>
>>> One reason is that the multiple parallel reply threads that
>>> sometimes occur can sometimes be rather difficult to track.
>>> (Your patches have started some quite useful conversations!)
>>>
>>> For example, I suspect Jonathan's comments may trigger changes
>>> for patches 5-12.
>>>
>>> For now, I'm applying 1-4 and 13-16. It looks like some reworking is
>>> going to be needed for the others. When you do resubmit them, please
>>> start a new thread (rather than replying into this thread).
>>>
>>> Thanks,
>>>
>>> Michael