On 22/01/2022 19:03, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
> [regarding various warning options and program style]
>
>> That one may not be, but there are some that are purely stylistic,
>> and different implementations enforce different styles.
>>
>> One big class is 'redundant' parentheses. Some implementations
>> consider some operations to have 'unnatural' precedence, and will
>> advise adding parentheses to make that explicit, while others will
>> warn that those parentheses aren't needed and are just redundant.
>
> Personally I would like to see a compiler option that warns
> in /all/ cases of redundant parentheses.
>

Do you think that would be much used? I can understand how some people
might find the warning interesting, but the prime purpose of warnings in
compilers is to help people spot possible errors in their code - code
that does not do what they think it does, or does not do what they
intended it to do.

There are other kinds of static checking systems that go beyond that to
purely stylistic matters - checking for spelling in identifiers, maximum
number of lines in a function, and whatever. This kind of check might
fit better at such a level. Both gcc and clang/llvm have frameworks for
extensions and checkers that would be suitable, allowing people to add
new checks in a high-level language (such as Python) without having to
go through the laborious process of changing the core compiler.

On 23/01/2022 11:28, David Brown wrote:
> On 22/01/2022 19:03, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>> [regarding various warning options and program style]
>>
>>> That one may not be, but there are some that are purely stylistic,
>>> and different implementations enforce different styles.
>>>
>>> One big class is 'redundant' parentheses. Some implementations
>>> consider some operations to have 'unnatural' precedence, and will
>>> advise adding parentheses to make that explicit, while others will
>>> warn that those parentheses aren't needed and are just redundant.
>>
>> Personally I would like to see a compiler option that warns
>> in /all/ cases of redundant parentheses.
>>
>
> Do you think that would be much used? I can understand how some people
> might find the warning interesting, but the prime purpose of warnings in
> compilers is to help people spot possible errors in their code - code
> that does not do what they think it does, or does not do what they
> intended it to do.

Tim thinks that everyone should know all the C precedence levels,
including those for ?: operators, so should they should never never to
use parentheses for clarity or avoid ambiguity.

This sounds like something that can be used to catch people out. So
detecting:

a << (b + c)

is a sign that someone is unsure about relevant precedences of << and +;
they should instead write:

a << b + c

While this ought to be perfectly clear without parentheses:

a ? b ? c : d ? e : f : g;

On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote:

> While this ought to be perfectly clear without parentheses:
>
>
a ? b ? c : d ? e : f : g;

It looks bad to read for me. Parentheses do not help to reason there.
Writing in more usual to human logic may help:

!a ? g : b ? c : d ? e : f;

Also adding newlines to emphasize what is value and what condition
may help:

!a ? g
: b ? c
: d ? e
: f;

But parentheses would make original to look even more garbage.

On 23/01/2022 16:36, Öö Tiib wrote:
> On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote:
>
>> While this ought to be perfectly clear without parentheses:
>>
>>
> a ? b ? c : d ? e : f : g;
>
> It looks bad to read for me. Parentheses do not help to reason there.
> Writing in more usual to human logic may help:
>
> !a ? g : b ? c : d ? e : f;
>
> Also adding newlines to emphasize what is value and what condition
> may help:
>
> !a ? g
> : b ? c
> : d ? e
> : f;
>
> But parentheses would make original to look even more garbage.
>

If pseudo-code, my example corresponds do:

if a then
if b then
c
else
if d then
e
else
f
end
end
else
g
end

(Transcribed from AST display of the C code.) That suggests the
parentheses would go here:

a ? (b ? c : (d ? e : f)) : g

You version is transformed, but presumably you had to already know what
it meant in order to do that.

A multi-line, indented layout would help, provided you were confident
that that was what it meant without the parentheses. But then you are
much better off using if-else. (Unfortunately in C if-else cannot return
a value.)

I only use such short-form constructs on one line.

Tiib <ootiib@hot.ee> writes:

> On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote:

[edited to reflect what I believe is correct attribution]

>> While this ought to be perfectly clear without parentheses:
>>
>> a ? b ? c : d ? e : f : g;
>
> It looks bad to read for me. Parentheses do not help to reason
> there. Writing in more usual to human logic may help:
>
> !a ? g : b ? c : d ? e : f;
>
> Also adding newlines to emphasize what is value and what condition
> may help:
>
> !a ? g
> : b ? c
> : d ? e
> : f;
>
> But parentheses would make original to look even more garbage.

I don't disagree with your comments. For me though the high
order bit is that this is a pointless and contrived example,
and not deserving of any other reaction. Just like so many
other of Bart's postings.

2022-01-22 at 16:46 +0100, David Brown wrote:
> The choice of whether or not you want a warning on extra padding on
> structs is a matter of style and the type of code you are writing.

Not really what you were saying earlier, but nice try.

> Yes, sometimes it matters if there is unexpected padding in your
> structs. Yes, sometimes it does /not/ matter. Neither situation
> /requires/ the warning, and neither requires that the warning is
> disabled.

In this line of thought I propose to simplify the argument to
"no warnings are required at all" and let's be done with it.

Mateusz

2022-01-22 at 12:04 -0800, Tim Rentsch wrote:
> To be explicit the above is not meant as an argument to convince
> you. I am however interested in whatever reactions you might
> have.

My reaction is simply that in real world, there's no one ring to rule
them all. Each of us has to choose the tools that suit him best, based
on many things: the exact need at hand, personal preferences, and
personal limitations to name only the few that come to mind immediately.

> I have looked through the list of changes between C90 and C99 and
> don't see anything else that looks objectionable. Can I ask you
> to provide a more comprehensive list? I really am at a loss to
> know what sorts of things you wouldn't like and also would be
> tempted to use.

It's not only about temptation, it also about using tools that are as
simple as possible. I like games with simple rules - one reason why I
prefer Go over chess. Some say it's because I lack brain power, and
they may be right. Now, C99 isn't *that* much of a complication that I
couldn't grasp it, but then where do I draw the line? C89 (or its gnu
dialect) works for me and allows me to do the jobs I need to do without
pain, so why bother.

Now, about features that I don't like in C99:
- VLAs (temptation argument again, that may lead to stack exhaustion)
- bool (don't see what added value this brings)
- complex & imaginary numbers (I admit those may be useful in some
niche usage, but *I* never had such need)

I also agree that C99 brings its share of improvements, which are part
of the set of features I had listed earlier. But so does the gnu89
dialect, with the extra layer of POSIX that I often rely on. Hence in
my very personal usage I consider gnu89 to be a pretty optimal tool.
And I do not expect other people to agree, because of the reasons
stated earlier.

Mateusz

On 24/01/2022 09:33, Mateusz Viste wrote:
> 2022-01-22 at 16:46 +0100, David Brown wrote:
>> The choice of whether or not you want a warning on extra padding on
>> structs is a matter of style and the type of code you are writing.
>
> Not really what you were saying earlier, but nice try.
>
>> Yes, sometimes it matters if there is unexpected padding in your
>> structs. Yes, sometimes it does /not/ matter. Neither situation
>> /requires/ the warning, and neither requires that the warning is
>> disabled.
>
> In this line of thought I propose to simplify the argument to
> "no warnings are required at all" and let's be done with it.
>

I'm not sure why you have decided this is some sort of battle rather
than sharing experiences and suggestions for how to get the most help
from your compiler, but I guess we are done with this thread.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> [...] I've seen some pretty long functions that are not easily
>>> amenable to factorization into smaller functions for structural
>>> or performance reasons.
>>
>> Can you post an example or two of those? Ideally one of each, one
>> where structure impedes refactoring and one where performance
>> impedes refactoring.
>
> Probably not without violating various non-disclosure or employment
> agreements.

Surely you can find some example that wouldn't go against your
existing agreements. Probably even one of the covered examples
would be okay if stripped of comments and had all the identifers
changed to randomly chosen names (and for good measure take out
all extra horizontal white space). The code doesn't have to
compile, just show the "shape" of the function; it's unlikely
that would be giving away any kind of trade secrets. And it
doesn't have to be one of the very longest functions; in fact
between 50 and 100 lines is probably easier than some super long
monster. (Having said that, I wouldn't mind a much longer
function if that's the best you can find.)

> One in particular is the code to handle page table walks in
> an ARM64 processor simulator. Another was handling the fork()
> system call in a unix-derived MPP operating system. Both in C++.

This is comp.lang.c. My question is about C code, not C++ code.
C++ is a completely different animal.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> [...] I've seen some pretty long functions that are not easily
>>>> amenable to factorization into smaller functions for structural
>>>> or performance reasons.
>>>
>>> Can you post an example or two of those? Ideally one of each, one
>>> where structure impedes refactoring and one where performance
>>> impedes refactoring.
>>
>> Probably not without violating various non-disclosure or employment
>> agreements.
>
>Surely you can find some example that wouldn't go against your
>existing agreements. Probably even one of the covered examples
>would be okay if stripped of comments and had all the identifers
>changed to randomly chosen names (and for good measure take out
>all extra horizontal white space). The code doesn't have to
>compile, just show the "shape" of the function; it's unlikely
>that would be giving away any kind of trade secrets. And it
>doesn't have to be one of the very longest functions; in fact
>between 50 and 100 lines is probably easier than some super long
>monster. (Having said that, I wouldn't mind a much longer
>function if that's the best you can find.)

I do tend to honor copyrights, which precludes much of this.

>
>> One in particular is the code to handle page table walks in
>> an ARM64 processor simulator. Another was handling the fork()
>> system call in a unix-derived MPP operating system. Both in C++.
>
>This is comp.lang.c. My question is about C code, not C++ code.
>C++ is a completely different animal.

No, it's just C with added capabilities.

And if I ever get some free time where I have nothing else to do,
and your request bubbles up to the top of the future-to-do list,
I'll spend the time to find an example and clear it for public
display.

scott@slp53.sl.home (Scott Lurndal) writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:

>>Surely you can find some example that wouldn't go against your
>>existing agreements.

Ok, a long C function:

/**
* Scaled down version of printf(3).
*
* Two additional formats:
*
* The format %b is supported to decode error registers.
* Its usage is:
*
* <tt>
* printf("reg=%b\n", regval, "\<base\>\<arg\>*");
* </tt>
*
* where \<base\> is the output base expressed as a control character, e.g.
* \\10 gives octal; \\20 gives hex. Each arg is a sequence of characters,
* the first of which gives the bit number to be inspected (origin 1), and
* the next characters (up to a control character, i.e. a character &lt;= 32),
* give the name of the register. Thus:
*
* <tt><pre>
* printf("reg=%b\n", 3, "\10\2BITTWO\1BITONE\n");
* </pre></tt>
*
* would produce output:
*
* <tt>
* reg=3&lt;BITTWO,BITONE&gt;
* </tt>
*
* XXX: %D -- Hexdump, takes pointer and separator string:
* ("%6D", ptr, ":") -&gt; XX:XX:XX:XX:XX:XX
* ("%*D", len, ptr, " " -&gt; XX XX XX XX ...
*
* @param fmt pointer to printf format string
* @param ap pointer to argument list
* @param buf pointer to buffer to receive formatted, zero terminated results
* @param limit number of chars buf can hold, INCLUDING zero termination
* @return the number of chars put into buf, does NOT include zero terminator
*/
size_t
format(const char *fmt, va_list ap, char *buf, size_t limit)
{

/* Reserve one byte for '\0', in buffer overflow case. */
#define PCHAR(c) {int cc=(c); if (retval < (limit - 1)) {*d++ = cc; retval++;} }

char nbuf[MAXNBUF];
char *d = buf;
const char *p, *percent, *q;
uint8 *up;
int ch, n;
uint64 num;
int base, lflag, qflag, tmp, width, ladjust, sharpflag, neg, sign, dot;
int cflag, hflag, jflag, tflag, zflag;
int dwidth;
char padc;
size_t retval = 0;

num = 0;

if (fmt == NULL)
fmt = "(fmt null)\n";

for (;;) {
padc = ' ';
width = 0;
while ((ch = (uint8)*fmt++) != '%') {
if (ch == '\0') {
*d++ = '\0';
retval++;
return (retval);
}
PCHAR(ch);
}
percent = fmt - 1;
qflag = 0; lflag = 0; ladjust = 0; sharpflag = 0; neg = 0;
sign = 0; dot = 0; dwidth = 0;
cflag = 0; hflag = 0; jflag = 0; tflag = 0; zflag = 0;
reswitch: switch (ch = (uint8)*fmt++) {
case '.':
dot = 1;
goto reswitch;
case '#':
sharpflag = 1;
goto reswitch;
case '+':
sign = 1;
goto reswitch;
case '-':
ladjust = 1;
goto reswitch;
case '%':
PCHAR(ch);
break;
case '*':
if (!dot) {
width = va_arg(ap, int);
if (width < 0) {
ladjust = !ladjust;
width = -width;
}
} else {
dwidth = va_arg(ap, int);
}
goto reswitch;
case '0':
if (!dot) {
padc = '0';
goto reswitch;
}
case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
for (n = 0;; ++fmt) {
n = n * 10 + ch - '0';
ch = *fmt;
if (ch < '0' || ch > '9')
break;
}
if (dot)
dwidth = n;
else
width = n;
goto reswitch;
case 'b':
num = (uint32)va_arg(ap, int);
p = va_arg(ap, char *);
for (q = ksprintn(nbuf, num, *p++, NULL); *q;)
PCHAR(*q--);

if (num == 0)
break;

for (tmp = 0; *p;) {
n = *p++;
if (num & (1 << (n - 1))) {
PCHAR(tmp ? ',' : '<');
for (; (n = *p) > ' '; ++p)
PCHAR(n);
tmp = 1;
} else
for (; *p > ' '; ++p)
continue;
}
if (tmp)
PCHAR('>');
break;
case 'c':
PCHAR(va_arg(ap, int));
break;
case 'D':
up = va_arg(ap, uint8 *);
p = va_arg(ap, char *);
if (!width)
width = 16;
while(width--) {
PCHAR(hex2ascii(*up >> 4));
PCHAR(hex2ascii(*up & 0x0f));
up++;
if (width)
for (q=p;*q;q++)
PCHAR(*q);
}
break;
case 'd':
case 'i':
base = 10;
sign = 1;
goto handle_sign;
case 'h':
if (hflag) {
hflag = 0;
cflag = 1;
} else
hflag = 1;
goto reswitch;
case 'j':
jflag = 1;
goto reswitch;
case 'l':
if (lflag) {
lflag = 0;
qflag = 1;
} else
lflag = 1;
goto reswitch;
case 'n':
if (jflag)
*(va_arg(ap, int64 *)) = retval;
else if (qflag)
*(va_arg(ap, int64 *)) = retval;
else if (lflag)
*(va_arg(ap, long *)) = retval;
else if (zflag)
*(va_arg(ap, size_t *)) = retval;
else if (hflag)
*(va_arg(ap, short *)) = retval;
else if (cflag)
*(va_arg(ap, char *)) = retval;
else
*(va_arg(ap, int *)) = retval;
break;
case 'o':
base = 8;
goto handle_nosign;
case 'p':
base = 16;
sharpflag = (width == 0);
sign = 0;
num = (uintptr_t)va_arg(ap, void *);
goto number;
case 'q':
qflag = 1;
goto reswitch;
case 's':
p = va_arg(ap, char *);
if (p == NULL)
p = "(null)";
if (!dot)
n = strlen (p);
else
for (n = 0; n < dwidth && p[n]; n++)
continue;

width -= n;

if (!ladjust && width > 0)
while (width--)
PCHAR(padc);
while (n--)
PCHAR(*p++);
if (ladjust && width > 0)
while (width--)
PCHAR(padc);
break;
case 't':
tflag = 1;
goto reswitch;
case 'u':
base = 10;
goto handle_nosign;
case 'x':
case 'X':
if (dot) {
padc = '0';
}
base = 16;
goto handle_nosign;
case 'y':
base = 16;
sign = 1;
goto handle_sign;
case 'z':
zflag = 1;
goto reswitch;
handle_nosign:
sign = 0;
if (jflag)
num = va_arg(ap, uint64);
else if (qflag)
num = va_arg(ap, uint64);
else if (tflag)
num = va_arg(ap, int64);
else if (lflag)
num = va_arg(ap, uint64);
else if (zflag)
num = va_arg(ap, size_t);
else if (hflag)
num = (uint16)va_arg(ap, int);
else if (cflag)
num = (uint8)va_arg(ap, int);
else
num = va_arg(ap, uint32);
goto number;
handle_sign:
if (jflag)
num = va_arg(ap, int64);
else if (qflag)
num = va_arg(ap, int64);
else if (tflag)
num = va_arg(ap, int64);
else if (lflag)
num = va_arg(ap, long);
else if (zflag)
num = va_arg(ap, size_t);
else if (hflag)
num = (short)va_arg(ap, int);
else if (cflag)
num = (char)va_arg(ap, int);
else
num = va_arg(ap, int);
number:
if (sign && (int64)num < 0) {
neg = 1;
num = -(int64)num;
}
p = ksprintn(nbuf, num, base, &tmp);
if (sharpflag && num != 0) {
if (base == 8)
tmp++;
else if (base == 16)
tmp += 2;
}
if (neg)
tmp++;

if (!ladjust && width && (width -= tmp) > 0)
while (width--)
PCHAR(padc);
if (neg)
PCHAR('-');
if (sharpflag && num != 0) {
if (base == 8) {
PCHAR('0');
} else if (base == 16) {
PCHAR('0');
PCHAR('x');
}
}

while (*p)
PCHAR(*p--);

if (ladjust && width && (width -= tmp) > 0)
while (width--)
PCHAR(padc);

break;
default:
while (percent < fmt)
PCHAR(*percent++);
break;
}
}
#undef PCHAR
}

scott@slp53.sl.home (Scott Lurndal) writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>> Surely you can find some example that wouldn't go against your
>>> existing agreements.
>
> Ok, a long C function: [...]

Good, thank you for tracking down what looks like a good
example.

Before I look any further, are there any particular aspects
you would say are important to pay attention to or that
contribute to difficulty in refactoring?

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>> Surely you can find some example that wouldn't go against your
>>>> existing agreements.
>>
>> Ok, a long C function: [...]
>
>Good, thank you for tracking down what looks like a good
>example.
>
>Before I look any further, are there any particular aspects
>you would say are important to pay attention to or that
>contribute to difficulty in refactoring?

Not really, other than that I believe this was derived
from BSD at one point.

Here's the helpers:

#define NBBY 8 /* number of bits in a byte */

/* Max number conversion buffer length: a uint64 in base 2, plus zero byte. */
#define MAXNBUF (sizeof(int64) * NBBY + 1)

char const hex2ascii_data[] = "0123456789abcdefghijklmnopqrstuvwxyz";

#define hex2ascii(hex) (hex2ascii_data[hex])

/**
* Put a NUL-terminated ASCII number (base <= 36) in a buffer in reverse
* order; return an optional length and a pointer to the last character
* written in the buffer (i.e., the first character of the string).
* The buffer pointed to by `nbuf' must have length >= MAXNBUF.
*
* @param nbuf buffer to hold the converted number.
* @param num The value to be converted.
* @param base The radix to be used in converting.
* @param lenp A pointer to where return the pointer to the last character
* written in the buffer. Specify NULL to not have this
* pointer returned.
* @returns A pointer to the start of the output buffer.
*/
static char *
ksprintn(char *nbuf, uint64 num, int base, int *lenp)
{ char *p;

p = nbuf;
*p = '\0';
do {
*++p = hex2ascii(num % base);
} while (num /= base);
if (lenp)
*lenp = p - nbuf;
return (p);
}

scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>> Surely you can find some example that wouldn't go against your
>>>>> existing agreements.
>>>
>>> Ok, a long C function: [...]
>>
>>Good, thank you for tracking down what looks like a good
>>example.
>>
>>Before I look any further, are there any particular aspects
>>you would say are important to pay attention to or that
>>contribute to difficulty in refactoring?
>
> Not really, other than that I believe this was derived
> from BSD at one point.
>
> Here's the helpers:
>
> #define NBBY 8 /* number of bits in a byte */

Why not just use CHAR_BIT?

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 1/24/22 11:24, Scott Lurndal wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
....
>> This is comp.lang.c. My question is about C code, not C++ code.
>> C++ is a completely different animal.

That's false, but so is the following:

> No, it's just C with added capabilities.

The C++ standard devotes 8 pages (C.5) to describing differences between
the way C and C++ handle a variety of issues, and another pair of pages
(C.6) that describe how the version of the C standard library that is
supported as part of the C++ standard library differs from the one
described by the C standard. That's not a lot out of a standard that
runs 1826 pages, but it not entirely negligible, either.

Note that those lists do not include the features that C++ has that C
doesn't - they're about differences in the way that features shared
between the two languages work.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>> Surely you can find some example that wouldn't go against your
>>>>>> existing agreements.
>>>>
>>>> Ok, a long C function: [...]
>>>
>>>Good, thank you for tracking down what looks like a good
>>>example.
>>>
>>>Before I look any further, are there any particular aspects
>>>you would say are important to pay attention to or that
>>>contribute to difficulty in refactoring?
>>
>> Not really, other than that I believe this was derived
>> from BSD at one point.
^^^
>>
>> Here's the helpers:
>>
>> #define NBBY 8 /* number of bits in a byte */
>
>Why not just use CHAR_BIT?

Was CHAR_BIT available in 1983?

On 1/25/2022 3:50 AM, James Kuyper wrote:
> On 1/24/22 11:24, Scott Lurndal wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> ...
>>> This is comp.lang.c. My question is about C code, not C++ code.
>>> C++ is a completely different animal.
>
> That's false, but so is the following:
>
>> No, it's just C with added capabilities.
>
> The C++ standard devotes 8 pages (C.5) to describing differences between
> the way C and C++ handle a variety of issues, and another pair of pages
> (C.6) that describe how the version of the C standard library that is
> supported as part of the C++ standard library differs from the one
> described by the C standard. That's not a lot out of a standard that
> runs 1826 pages, but it not entirely negligible, either.
>
> Note that those lists do not include the features that C++ has that C
> doesn't - they're about differences in the way that features shared
> between the two languages work.
>

All true; it may also be worth recalling that this subthread is about
justification of long functions, and that C++ was brought up in this
comment:

> ... In most cases, they were in bare-metal performance
> critical code (operating systems, hypervisors) in C and C++.
>
> One in particular is the code to handle page table walks in
> an ARM64 processor simulator. Another was handling the fork()
> system call in a unix-derived MPP operating system. Both in C++.

Now, it is one of the goals of C++ compared to C to be able to write
more efficient and thus more compact code. I don't think C++ has failed
in this respect - the criticism of those who favor C against C++ may be
about complexity of the language, or lack of expressiveness in terms of
clarity, but not being more verbose than C.

In particular, with reference to the example posted elsethread,
replacing long 'switch' blocks with more structured constructs is one
typical refactoring when porting to C++.

scott@slp53.sl.home (Scott Lurndal) writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>
>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>
>>>>>>> Surely you can find some example that wouldn't go against your
>>>>>>> existing agreements.
>>>>>
>>>>> Ok, a long C function: [...]
>>>>
>>>>Good, thank you for tracking down what looks like a good
>>>>example.
>>>>
>>>>Before I look any further, are there any particular aspects
>>>>you would say are important to pay attention to or that
>>>>contribute to difficulty in refactoring?
>>>
>>> Not really, other than that I believe this was derived
>>> from BSD at one point.
> ^^^
>>>
>>> Here's the helpers:
>>>
>>> #define NBBY 8 /* number of bits in a byte */
>>
>>Why not just use CHAR_BIT?
>
> Was CHAR_BIT available in 1983?

The code does not appear to date from 1983. You have 64-bit integers,
size_t, void, function prototypes, uintptr_t and doubtless other things
I've missed. In 1983 you could not even rely on what header to include
for strlen, malloc, varargs and so on, so for the original 1983-era code
you would not have been able to rely on anything in a header(!), but
clearly the code has been updated to use many post 1983 features.

--
Ben.

Manfred <invalid@invalid.add> writes:
>On 1/25/2022 3:50 AM, James Kuyper wrote:
>> On 1/24/22 11:24, Scott Lurndal wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> ...
>>>> This is comp.lang.c. My question is about C code, not C++ code.
>>>> C++ is a completely different animal.
>>
>> That's false, but so is the following:
>>
>>> No, it's just C with added capabilities.
>>
>> The C++ standard devotes 8 pages (C.5) to describing differences between
>> the way C and C++ handle a variety of issues, and another pair of pages
>> (C.6) that describe how the version of the C standard library that is
>> supported as part of the C++ standard library differs from the one
>> described by the C standard. That's not a lot out of a standard that
>> runs 1826 pages, but it not entirely negligible, either.
>>
>> Note that those lists do not include the features that C++ has that C
>> doesn't - they're about differences in the way that features shared
>> between the two languages work.
>>
>
>All true; it may also be worth recalling that this subthread is about
>justification of long functions, and that C++ was brought up in this
>comment:
>
>> ... In most cases, they were in bare-metal performance
>> critical code (operating systems, hypervisors) in C and C++.
>>
>> One in particular is the code to handle page table walks in
>> an ARM64 processor simulator. Another was handling the fork()
>> system call in a unix-derived MPP operating system. Both in C++.
>
>Now, it is one of the goals of C++ compared to C to be able to write
>more efficient and thus more compact code. I don't think C++ has failed
>in this respect - the criticism of those who favor C against C++ may be
>about complexity of the language, or lack of expressiveness in terms of
>clarity, but not being more verbose than C.
>
>In particular, with reference to the example posted elsethread,
>replacing long 'switch' blocks with more structured constructs is one
>typical refactoring when porting to C++.

Can you do that form of refactoring (specifically for a text
formatting function such as the implementation of printf posted
earlier) without sacrificing performance?

C++ basically sucks today if you use the output streams for
formatting instead of snprintf style format specifiers,
not to mention making maintenance (and L10N/I18N more complicated).

(note that the formatting example was used in a bare-metal
high-performance hypervisor on small supercomputer written
in C++. No libraries, no STL, no exceptions, no RTTI,
just C with classes - because every cycle wasted in the
hypervisor is not available to user code).

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>>
>>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>>
>>>>>>>> Surely you can find some example that wouldn't go against your
>>>>>>>> existing agreements.
>>>>>>
>>>>>> Ok, a long C function: [...]
>>>>>
>>>>>Good, thank you for tracking down what looks like a good
>>>>>example.
>>>>>
>>>>>Before I look any further, are there any particular aspects
>>>>>you would say are important to pay attention to or that
>>>>>contribute to difficulty in refactoring?
>>>>
>>>> Not really, other than that I believe this was derived
>>>> from BSD at one point.
>> ^^^
>>>>
>>>> Here's the helpers:
>>>>
>>>> #define NBBY 8 /* number of bits in a byte */
>>>
>>>Why not just use CHAR_BIT?
>>
>> Was CHAR_BIT available in 1983?
>
>The code does not appear to date from 1983. You have 64-bit integers,
>size_t, void, function prototypes, uintptr_t and doubtless other things
>I've missed. In 1983 you could not even rely on what header to include
>for strlen, malloc, varargs and so on, so for the original 1983-era code
>you would not have been able to rely on anything in a header(!), but
>clearly the code has been updated to use many post 1983 features.
>

The original for that came from BSD, probably 4.2ish. It was updated
to handle 64-bits when we ported it to the hypervisor 17 years ago.

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>
>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>
>>>>>>> Surely you can find some example that wouldn't go against your
>>>>>>> existing agreements.
>>>>>
>>>>> Ok, a long C function: [...]
>>>>
>>>>Good, thank you for tracking down what looks like a good
>>>>example.
>>>>
>>>>Before I look any further, are there any particular aspects
>>>>you would say are important to pay attention to or that
>>>>contribute to difficulty in refactoring?
>>>
>>> Not really, other than that I believe this was derived
>>> from BSD at one point.
> ^^^
>>>
>>> Here's the helpers:
>>>
>>> #define NBBY 8 /* number of bits in a byte */
>>
>>Why not just use CHAR_BIT?
>
> Was CHAR_BIT available in 1983?

Oh, *that* BSD, not one of its later derivatives! (I first used C under
BSD 4.1 myself.)

As others have mentioned, the code was updated to use newer features.
Replacing NBBY with CHAR_BIT would have made sense, but it's not a huge
deal.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>>
>>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>>
>>>>>>>> Surely you can find some example that wouldn't go against your
>>>>>>>> existing agreements.
>>>>>>
>>>>>> Ok, a long C function: [...]
>>>>>
>>>>>Good, thank you for tracking down what looks like a good
>>>>>example.
>>>>>
>>>>>Before I look any further, are there any particular aspects
>>>>>you would say are important to pay attention to or that
>>>>>contribute to difficulty in refactoring?
>>>>
>>>> Not really, other than that I believe this was derived
>>>> from BSD at one point.
>> ^^^
>>>>
>>>> Here's the helpers:
>>>>
>>>> #define NBBY 8 /* number of bits in a byte */
>>>
>>>Why not just use CHAR_BIT?
>>
>> Was CHAR_BIT available in 1983?
>
>Oh, *that* BSD, not one of its later derivatives! (I first used C under
>BSD 4.1 myself.)
>
>As others have mentioned, the code was updated to use newer features.
>Replacing NBBY with CHAR_BIT would have made sense, but it's not a huge
>deal.

Looks like they eliminated it in recent freebsd:

https://svnweb.freebsd.org/base/head/sys/kern/subr_prf.c?view=markup

starts at line 590.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>> Surely you can find some example that wouldn't go against your
>>>>> existing agreements.
>>>
>>> Ok, a long C function: [...]
>>
>> Good, thank you for tracking down what looks like a good
>> example.
>>
>> Before I look any further, are there any particular aspects
>> you would say are important to pay attention to or that
>> contribute to difficulty in refactoring?
>
> Not really, other than that I believe this was derived
> from BSD at one point.
>
> Here's the helpers: [...]

I got these, thank you. Additional comments in a followup
to your posting elsethread.

scott@slp53.sl.home (Scott Lurndal) writes:

> Manfred <invalid@invalid.add> writes:
>
>> On 1/25/2022 3:50 AM, James Kuyper wrote:
>>
>>> On 1/24/22 11:24, Scott Lurndal wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>> ...
>>>
>>>>> This is comp.lang.c. My question is about C code, not C++ code.
>>>>> C++ is a completely different animal.
>>>
>>> That's false, but so is the following:
>>>
>>>> No, it's just C with added capabilities.
>>>
>>> The C++ standard devotes 8 pages (C.5) to describing differences between
>>> the way C and C++ handle a variety of issues, and another pair of pages
>>> (C.6) that describe how the version of the C standard library that is
>>> supported as part of the C++ standard library differs from the one
>>> described by the C standard. That's not a lot out of a standard that
>>> runs 1826 pages, but it not entirely negligible, either.
>>>
>>> Note that those lists do not include the features that C++ has that C
>>> doesn't - they're about differences in the way that features shared
>>> between the two languages work.
>>
>> All true; it may also be worth recalling that this subthread is about
>> justification of long functions, and that C++ was brought up in this
>> comment:
>>
>>> ... In most cases, they were in bare-metal performance
>>> critical code (operating systems, hypervisors) in C and C++.
>>>
>>> One in particular is the code to handle page table walks in
>>> an ARM64 processor simulator. Another was handling the fork()
>>> system call in a unix-derived MPP operating system. Both in C++.
>>
>> Now, it is one of the goals of C++ compared to C to be able to write
>> more efficient and thus more compact code. I don't think C++ has failed
>> in this respect - the criticism of those who favor C against C++ may be
>> about complexity of the language, or lack of expressiveness in terms of
>> clarity, but not being more verbose than C.
>>
>> In particular, with reference to the example posted elsethread,
>> replacing long 'switch' blocks with more structured constructs is one
>> typical refactoring when porting to C++.
>
> Can you do that form of refactoring (specifically for a text
> formatting function such as the implementation of printf posted
> earlier) without sacrificing performance? [further C++ remarks
> omitted]

Writing in plain C, it isn't difficult to restructure the posted
printf-like code into multiple small or reasonably sized functions
(no more than 40ish lines, say). The effort needed isn't trivial
but it isn't really challenging either.

I'm intrigued by the phrase "without sacrificing performance". I
see no reason to suppose the performance of a restructured version
should be worse than that of the original. (Of course this means
on average; most likely some cases would be better and others
would be worse, but overall not significantly different.) So I'm
wondering why someone would think the performance of the original
is going to be better than refactored/restructured alternatives.

Looking at subr_prf.c (from the link posted elsethread) offers a
clue. The structure of that code is very nearly identical to the
code posted here. Looking at the copyright dates, it looks like
the subr_prf code was written between about 30 and 35 years ago.
At that time there were two significant differences relative to
today: processor behavior was less advanced, and compiler
technology was less sophisticated. Both of these trends make it
more likely that some performance advantage, if there was any, of
that earlier code would not accrue for more modern machines when
using more modern tools.

There are at least two other factors that weigh on the question.
One is workload: it is quite possible that alternative A would
give better performance than alternative B for one set of inputs,
and vice versa for a different set of inputs, and so which
alternative is better depends on what distribution of inputs is
expected. Another is operating context: these days performance
is highly multi-dimensional, being affected by all sorts of things
beyond just what sequence of instructions is executed. Here again
we might very well see a situation where alternative A is better
in one operating environment whereas alternative B is better in a
different operating environment. For both of these factors it
would be very unusual to see one alternative give better results
over all points in the space of plausible scenarios.

So it may be the case that the posted code would do better than
some proposed restructing, for its expected workload and intended
operating environment, etc. Without more specifics, however, the
proposition remains unconvincing.

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-01-22 at 12:04 -0800, Tim Rentsch wrote:
>
>> To be explicit the above is not meant as an argument to convince
>> you. I am however interested in whatever reactions you might
>> have.
>
> My reaction is simply that in real world, there's no one ring to rule
> them all. Each of us has to choose the tools that suit him best, based
> on many things: the exact need at hand, personal preferences, and
> personal limitations to name only the few that come to mind immediately.

I am trying to understand the reasons for those preferences.

>> I have looked through the list of changes between C90 and C99 and
>> don't see anything else that looks objectionable. Can I ask you
>> to provide a more comprehensive list? I really am at a loss to
>> know what sorts of things you wouldn't like and also would be
>> tempted to use.
>
> It's not only about temptation, it also about using tools that are as
> simple as possible. I like games with simple rules - one reason why I
> prefer Go over chess. Some say it's because I lack brain power, and
> they may be right. [...]
>
> Now, about features that I don't like in C99:
> - VLAs (temptation argument again, that may lead to stack exhaustion)
> - bool (don't see what added value this brings)
> - complex & imaginary numbers (I admit those may be useful in some
> niche usage, but *I* never had such need)

With all due respect, these sound more like rationalizations than
reasons. Have you made any effort to discover changes and new
features in C99 that you would like? It's important to look at
both sides, advantages as well as disadvantages.

> [...] Now, C99 isn't *that* much of a complication that I
> couldn't grasp it, but then where do I draw the line? C89 (or its gnu
> dialect) works for me and allows me to do the jobs I need to do without
> pain, so why bother.

If you don't give C99 an earnest try of non-trivial duration,
you'll never know.