[PATCH v2 4/5] termios: _SPEED_MAX and _BAUD_MAX constants

[Adhemerval Zanella Netto]

On 11/07/25 01:15, H. Peter Anvin wrote:
> On July 10, 2025 7:54:23 PM PDT, Collin Funk <collin.funk1@gmail.com> wrote:
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>>> Add constants indicating the maximum values of speed_t and baud_t.
>>> Hopefully if and when the baud_t interface is standardized then
>>> _BAUD_MAX will be included in the standardization from the start.
>>>
>>> Historically, the __MAX_BAUD symbol has indicated the maximum speed_t
>>> value on at least some platforms (including glibc).  However, this
>>> name would be problematic for future standardization, because it
>>> would imply a reference to baud_t, not speed_t, and it is inconsistent
>>> with other limit symbols, which are all of the form *_MAX
>>> (e.g. SIZE_MAX for size_t), but add an underscore to the front to
>>> avoid stomping on the application namespace.
>>>
>>> Furthermore, move __MAX_BAUD under __USE_MISC as it is not a
>>> standardized symbol.
>>
>> If the goal is to standardized baud_t and _BAUD_MAX, wouldn't it make
>> sense to just add BAUD_MAX now under __USE_MISC/__USE_GNU?
>>
>> I doubt the name with the leading underscore would ever be standardized.
>> And it looks much nicer without, in my opinion.
>>
>> Collin
> 
> The only issue with that is that I *think* it is a namespace violation. Other than that I have no objection.

For __USE_MISC it should not, and conform tests also do not trigger
any failure because it only check conformance for:

 #if !defined ISO && !defined ISO99 && !defined ISO11 && !defined ISO23

And I agree with Collin here, if the idea is to standardized it would be
better to keep __MAX_BAUD for !_USE_MISC (since removing it might broke
or miscompile things), and add MAX_BAUD/SPEED_MAX as GNU extension.