Hi,
Currently, printf(1) fails for integer larger than INTMAX_MAX as:
$ printf '%d\n' 0xc000
printf: 0xc000: Result too large or too small
9223372036854775807
With this patch,
http://www.netbsd.org/~rin/printf_20201024.patch
it becomes w
Date:Sat, 24 Oct 2020 21:40:44 +0900
From:Rin Okuyama
Message-ID:
| However, this result apparently depends on width of intmax_t. Is this
| behavior acceptable by POSIX?
Two things:
This from POSIX (actually from a draft that will, perhaps modified, become
the
I propose to drop the support for MKCATPAGES=yes. catpages are
preformatted .txt files that happen to contain manual pages and are
cat(1)able.
Over the past more than 5 years, I was the only person reporting any
fallout and fixing the regressions in the MKCATPAGES=yes build failures.
I'm going to
On Sun, Oct 25, 2020 at 02:13:47AM +0200, Kamil Rytarowski wrote:
>
> I recall catpages to used in 80286 UNIX (Coherent) and the catpages are
> probably just applicable for such constrained environments that cannot
> host any text formatters.
The issue was the speed of the text formatters. I viv
On 25.10.2020 02:35, Thor Lancelot Simon wrote:
> On Sun, Oct 25, 2020 at 02:13:47AM +0200, Kamil Rytarowski wrote:
>>
>> I recall catpages to used in 80286 UNIX (Coherent) and the catpages are
>> probably just applicable for such constrained environments that cannot
>> host any text formatters.
>
On Sun, Oct 25, 2020 at 02:03:43AM +0100, Kamil Rytarowski wrote:
> I bet that cat(1) is always faster, but I consider myself as the only
> regular (at all?) user of these pages at least since since 6.x and
> nobody caring.
Also, if we do have a platform where it's too slow and anyone actually
In article ,
Valery Ushakov wrote:
>Alistair Crooks wrote:
>
>> If it comes back, it needs to be modified to use curses - the hardcoded
>> terminal escapes for a bunch of 1970s terminals is kinda cute in a retro
>> way; it's also kinda embarassing.
>
>From a very quick look half of window sources
