Bart <bc@freeuk.com> writes:
[...]
> Funny how one remark by Scott that was likely erroneous and misleading
> attracts virtually no comment. But someone TRIES to show that they are
> wrong, and you try to annihilate them.

It's even funnier that I replied to Scott's post, cited your results,
and pointed out that snprintf() is likely to have substantial overhead.
I suppose that doesn't count, since it doesn't fit into your narrative.

And it's hilarious that you have yet to acknowledge that you lied about
something I wrote here, falsely claiming that I had said that the end
user must obtain the components for a C implementation from different
sources and mix and match them.

I don't expect you to admit that you liked, but you could at least
acknowledge that I didn't say what you claim I said.

--
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 */

antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
> > On 12/08/2021 09:29, David Brown wrote:
> > > On 12/08/2021 00:00, Bart wrote:
> >
> > Try this version of getstr():
> >
> > char* getstr(void){
> > enum {N=10000};
> > static char* s=NULL;
> >
> > if (s) return s;
> >
> > s=malloc(N+1);
> > memset(s,'A',N);
> > s[N]=0;
> > return s;
> > }
> >
> > You may need to adjust the timing loop in the other module for fewer
> > iterations, and ensure the str[] array is big enough for 5 copies. (And
> > maybe comment out the bits that print the strings!)
>
> I used the following with 'strcpy' and 'strlen':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> }
> puts(str);
> return 0;
> }
>
> but redirected output to '/dev/null'.
>
> time ./b5a > /dev/null
>
> real 0m0.400s
> user 0m0.400s
> sys 0m0.000s
>
> so 400ms for this version doing 100000
>
> With 'sprintf':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> sprintf(s, "%s", ns);
> }
> puts(str);
> return 0;
> }
>
> time ./b5c > /dev/null
>
> real 0m0.473s
> user 0m0.468s
> sys 0m0.000s
>
> BTW: For my tests I used 'get_str', so I renamed yours to 'get_str'
> to fit.
>
> > You might be surprised at the results.
> >
> > (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> > 440/2320 msec - sprintf was still several times slower.)
>
> Well, there are various design points. On short strings on my
> machine I get similar time as you with 'sprintf' and 2.4s
> using 'strcat' + 'strlen'. But on longer strings seem to be
> much faster (as I wrote on my machine string handling is via
> SSE instructions).

A little correction, I messed up sources and binaries and
'strcpy' version was doing onlyu four copies in the loop.
I also tried version using 'memcpy' instead of 'strcpy',
the critical fragment being:

l = strlen(ns);
memcpy(s, ns, l+1);
s += l;

Now the results are:

time ./b5a > /dev/null

real 0m0.476s
user 0m0.468s
sys 0m0.000s

time ./b5c > /dev/null

real 0m0.475s
user 0m0.472s
sys 0m0.000s

time ./b5d > /dev/null

real 0m0.500s
user 0m0.488s
sys 0m0.000s

where 'b5a' uses 'strcpy', 'b5c' uses 'sprintf' and 'b5d' uses
'memcpy'. As you see 'strcpy' variant and 'sprintf' have
almost the same speed, while 'memcpy' is slightly slower.

FYI, for 'strcpy' + 'strlen' and 'sprintf' this means 6.57
characters per clock. 'memcpy' + 'strlen' is doing only
6.25 characters per clock.

--
Waldek Hebisch

David Brown <david.brown@hesbynett.no> wrote:
> On 12/08/2021 17:59, Bart wrote:
> > On 12/08/2021 15:28, David Brown wrote:
> >> On 12/08/2021 13:10, Bart wrote:
> >
> >>> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> >>> 440/2320 msec - sprintf was still several times slower.)
> >>>
> >>
> >> I haven't claimed that sprintf is faster - I merely gave a possible
> >> explanation why it might be faster, for some situations.
> >
> > You said it's probably faster for short strings. It seems it can be
> > faster for much longer ones, but presumably not quoye as long as DFS's.
> >
>
> I said sprintf is going to be faster for /longer/ strings, because (in
> code sequences like your test code) it avoids the need to continually
> re-scan strings to find their length. That is, I think, quite obvious.

Well, if you do not see sources it is not obvious. 'strlen'
and 'strcpy' may have highly optimized implementation, while
'sprintf' could use some slow general code. On my machine
'sprintf' clearly is optimized, but takes essentially the
same time as 'strcpy' + 'strlen'. Interestingly, replacing
'strcpy' by 'memcpy' gave slower code.

If you consider that Bart is using what looks like quite recent
gcc toolchain on old version of Window, he may get quite strange
mix of library functions...

--
Waldek Hebisch

On 12/08/2021 18:44, David Brown wrote:
> On 12/08/2021 17:59, Bart wrote:

>> That is just your opinion. Many of us do care about it, since
>> unoptimised code can give highly useful trade-offs (like 100 times
>> faster build speeds - ask any Rust developer whether they would like a
>> 100x faster build just once).
>
> I have no experience of Rust. But I can tell assure you that "gcc -O0"
> does not run 100 times faster than "gcc -O2", and is nowhere near as
> useful.

Unoptimised doesn't mean gcc -O0. For example:

C:\oldqx>tm gcc -O0 qq.c -oqqnop.exe
TM: 5.05

C:\oldqx>tm gcc -O2 qq.c -oqqopt.exe
TM: 16.91

C:\oldqx>tm tcc qq.c -oqqtcc.exe
TM: 0.17

gcc-O0 was ony 3.2 times as fast as gcc-O2. But tcc was pretty much 100
times as fast (and 123 times as fast as gcc-O3).

As for runtimes:

C:\oldqx>tm qqopt fib
fib(36) = 14930352
TM: 2.44

C:\oldqx>tm qqnop fib
fib(36) = 14930352
TM: 4.28

C:\oldqx>tm qqtcc fib
fib(36) = 14930352
TM: 5.24

Here, the trade-off for 100x faster compilation is that runtime is 2.14
times as long. But there are other non-optimising compilers:

C:\oldqx>tm mm qq
Compiling qq.m---------- to qq.exe
TM: 0.20

C:\oldqx>tm qq -fn fib
fib(36) = 14930352
TM: 4.11

About 77x faster compilatiOn, and 1.7 times longer runtime.

Or I can do this:

C:\oldqx>tm qq -asm fib
fib(36) = 14930352
TM: 0.74

So 77x faster compilation /and/ 3.3x FASTER runtime. Using my own ways
of optimising programs.

>> Any native code non-optimising compiler can still generate code that
>> will wipe the floor with any interpreted scripting language.
>>
>
> For most (for a very vague, hand-waving and unsubstantiated measurement
> of "most") code, run-time speed is not particularly important.

Well, the difference between code from gcc-O3 and tcc is generally just
over 2:1, and that's for computationally intensive code.

You're now saying that runtime speed isn't important after all. I don't
get you. Isn't that the main advantage of the optimisation flag on a
compiler?

You say here:

> No one (sane and knowledgable) cares about the speed of code generated
> by non-optimising compilers, or compilers with the optimisation turned
> off.

You seemed utterly dismissive about non-optimising compilers under any
circumstances. Now you seem to be acknowledging that perhaps their
somewhat poorer performance doesn't matter for a lot of code.

> I did not say that people don't run compilers without optimisations. I
> said that people who care about the speed of the results don't run
> compilers without optimisations.

Those people may care about having a lightweight, small-footprint and
nippy product; about not having to hang about to build any app; about
not needing to deal with innumerable, obscure compiler options; about
not having to mess with writing makefiles to ensure that incremental
compilation will work - just compile the lot; about creating an app
which doesn't care what compiler a third party may use, or which options
they choose.

They might also want a development system that is responsive even on
cheaper, low-end machines.

> If I want code to be fast, I enable optimisations. If I want it to be
> small, I enable optimisations.

If I use -Os on the above qq.c file, I get a 736KB executable. With my
MM compiler, it's 748KB; 1.6% bigger, but gcc took 67x longer, and it
runs a bit more slowly [than -O2].

On 12/08/2021 17:52, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 12/08/2021 09:29, David Brown wrote:
>>> On 12/08/2021 00:00, Bart wrote:
>>
>> Try this version of getstr():
>>
>> char* getstr(void){
>> enum {N=10000};
>> static char* s=NULL;
>>
>> if (s) return s;
>>
>> s=malloc(N+1);
>> memset(s,'A',N);
>> s[N]=0;
>> return s;
>> }
>>
>> You may need to adjust the timing loop in the other module for fewer
>> iterations, and ensure the str[] array is big enough for 5 copies. (And
>> maybe comment out the bits that print the strings!)
>
> I used the following with 'strcpy' and 'strlen':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> }
> puts(str);
> return 0;
> }

This combination is generally faster than strcat on my machine, even
without extracting the getstr() call into one variable. (That's intended
to represent some arbitrary string, that can change on each call.)

In some cases it was double the speed of strcat.

It was faster even when I put both into a single function 'strcpylen',
so needing one call to getstr. But trying to replace those two calls
inside strcpylen with an actual copying loop, to eliminate a separate
strlen, was much slower (between strcat and my sprintf).

In any case, I've seen no evidence that sprintf can be reliably faster
than strcat or strcpy etc. It's also more untidy to call.

On 12/08/2021 19:10, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Funny how one remark by Scott that was likely erroneous and misleading
>> attracts virtually no comment. But someone TRIES to show that they are
>> wrong, and you try to annihilate them.
>
> It's even funnier that I replied to Scott's post, cited your results,
> and pointed out that snprintf() is likely to have substantial overhead.
> I suppose that doesn't count, since it doesn't fit into your narrative.

'virtually'. Compare the total lines posted trashing my results.

> And it's hilarious that you have yet to acknowledge that you lied about
> something I wrote here, falsely claiming that I had said that the end
> user must obtain the components for a C implementation from different
> sources and mix and match them.

So then you admit that a C implementation usually comes as a ready-made
bundle WITH a compiler, headers, library (or arrangements for the
library) INCLUDING functions like printf, and any other tools necessary
to turn source into runnable code?

Because it seems to me that you've always claimed these parts as distinct.

Bart <bc@freeuk.com> writes:
[SNIP]
>> And it's hilarious that you have yet to acknowledge that you lied about
>> something I wrote here, falsely claiming that I had said that the end
>> user must obtain the components for a C implementation from different
>> sources and mix and match them.
>
> So then you admit that a C implementation usually comes as a
> ready-made bundle WITH a compiler, headers, library (or arrangements
> for the library) INCLUDING functions like printf, and any other tools
> necessary to turn source into runnable code?

I do not "admit" it. The word "admit" implies that I've previously
stated otherwise. I have not. I certainly *acknowledge* it.

> Because it seems to me that you've always claimed these parts as distinct.

Yes, depending on what you mean by "distinct". The distinct components
are, in many cases, provided as a bundle. Sometimes the components are
all provided by the same provider. Sometimes they're provided by two or
more providers and somebody else creates the bundle, perhaps as part of
something larger. (For example, both gcc and glibc are pre-installed on
Ubuntu, at least in the configurations I've used.)

It is not typical for an end user to assemble the distinct components
into a working implementation.

Even if, for example, the compiler and the standard library are
tightly couple and provided in a single downloadable bundle, there
is still a clear internal distinction between them. There's no
particular requirement that they must be internally distinct, but
they (almost?) always are in practice, because it doesn't make
sense for them not to be.

Here's what you wrote:

| According to Keith, every C implementation consists of assorted
| components like this:
|
| * Possibly, a discrete preprocessor
| * Compiler
| * Standard headers
| * Assembler
| * Linker
| * Standard library
| * Extensions
|
| which everyone who ever installs an implementation is expected to obtain
| from different sources and mix and match to create a custom C system.

That is false; I did not say that. Typically "everyone who ever
installs an implementation" installs some bundle that already includes
the components that make up a C implementation.

Is it possible that you actually believed when you made that statement
that that was what I had said? I don't know *how* you could have
reached that conclusion.

--
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 8/12/21 7:52 PM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [SNIP]
>>> And it's hilarious that you have yet to acknowledge that you lied about
>>> something I wrote here, falsely claiming that I had said that the end
>>> user must obtain the components for a C implementation from different
>>> sources and mix and match them.
>>
>> So then you admit that a C implementation usually comes as a
>> ready-made bundle WITH a compiler, headers, library (or arrangements
>> for the library) INCLUDING functions like printf, and any other tools
>> necessary to turn source into runnable code?
>
> I do not "admit" it. The word "admit" implies that I've previously
> stated otherwise. I have not. I certainly *acknowledge* it.
>
>> Because it seems to me that you've always claimed these parts as distinct.
>
> Yes, depending on what you mean by "distinct". The distinct components
> are, in many cases, provided as a bundle. Sometimes the components are
> all provided by the same provider. Sometimes they're provided by two or
> more providers and somebody else creates the bundle, perhaps as part of
> something larger. (For example, both gcc and glibc are pre-installed on
> Ubuntu, at least in the configurations I've used.)
>
> It is not typical for an end user to assemble the distinct components
> into a working implementation.
>
> Even if, for example, the compiler and the standard library are
> tightly couple and provided in a single downloadable bundle, there
> is still a clear internal distinction between them. There's no
> particular requirement that they must be internally distinct, but
> they (almost?) always are in practice, because it doesn't make
> sense for them not to be.
>
> Here's what you wrote:
>
> | According to Keith, every C implementation consists of assorted
> | components like this:
> |
> | * Possibly, a discrete preprocessor
> | * Compiler
> | * Standard headers
> | * Assembler
> | * Linker
> | * Standard library
> | * Extensions
> |
> | which everyone who ever installs an implementation is expected to obtain
> | from different sources and mix and match to create a custom C system.
>
> That is false; I did not say that. Typically "everyone who ever
> installs an implementation" installs some bundle that already includes
> the components that make up a C implementation.
>
> Is it possible that you actually believed when you made that statement
> that that was what I had said? I don't know *how* you could have
> reached that conclusion.
>

Slight disagreement.

To the Standard, there is ONLY a complete implementation.

That implementation might be buildable out of building blocks, but as
far as the Standard is concerned, it is the responsibility of the entity
that puts it all together to make sure the results is 'Conforming'.

GCC, for example, it just a piece of an implementation, mostly the piece
called the 'compiler' (which I don't think is actually a defined term
for the Standard), and includes documentation for how to combine it with
the other pieces.

THere are library vendors who will provide other pieces of the
implementation, and documentation of how to combine it with other pieces
to make an implementation.

THen someone takes these pieces and creates the actual implementation.
They depend on the documentation from the various component vendors to
help them ensure that they make a 'Conforming' Implementation. If they
did the job right, it will be (or at least as close as practical
software will be to meeting some specification).

Sometimes the integrator intentionally makes the combination
non-conforming because that meets their needs better (perhaps adding a
non-conforming extension to the implementation). This is perfectly fine
too, 'Conformance' isn't the only criteria to judge an implementation by.

Richard Damon <Richard@Damon-Family.org> writes:
> On 8/12/21 7:52 PM, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [SNIP]
>>>> And it's hilarious that you have yet to acknowledge that you lied about
>>>> something I wrote here, falsely claiming that I had said that the end
>>>> user must obtain the components for a C implementation from different
>>>> sources and mix and match them.
>>>
>>> So then you admit that a C implementation usually comes as a
>>> ready-made bundle WITH a compiler, headers, library (or arrangements
>>> for the library) INCLUDING functions like printf, and any other tools
>>> necessary to turn source into runnable code?
>>
>> I do not "admit" it. The word "admit" implies that I've previously
>> stated otherwise. I have not. I certainly *acknowledge* it.
>>
>>> Because it seems to me that you've always claimed these parts as distinct.
>>
>> Yes, depending on what you mean by "distinct". The distinct components
>> are, in many cases, provided as a bundle. Sometimes the components are
>> all provided by the same provider. Sometimes they're provided by two or
>> more providers and somebody else creates the bundle, perhaps as part of
>> something larger. (For example, both gcc and glibc are pre-installed on
>> Ubuntu, at least in the configurations I've used.)
>>
>> It is not typical for an end user to assemble the distinct components
>> into a working implementation.
>>
>> Even if, for example, the compiler and the standard library are
>> tightly couple and provided in a single downloadable bundle, there
>> is still a clear internal distinction between them. There's no
>> particular requirement that they must be internally distinct, but
>> they (almost?) always are in practice, because it doesn't make
>> sense for them not to be.
>>
>> Here's what you wrote:
>>
>> | According to Keith, every C implementation consists of assorted
>> | components like this:
>> |
>> | * Possibly, a discrete preprocessor
>> | * Compiler
>> | * Standard headers
>> | * Assembler
>> | * Linker
>> | * Standard library
>> | * Extensions
>> |
>> | which everyone who ever installs an implementation is expected to obtain
>> | from different sources and mix and match to create a custom C system.
>>
>> That is false; I did not say that. Typically "everyone who ever
>> installs an implementation" installs some bundle that already includes
>> the components that make up a C implementation.
>>
>> Is it possible that you actually believed when you made that statement
>> that that was what I had said? I don't know *how* you could have
>> reached that conclusion.
>>
>
> Slight disagreement.
>
> To the Standard, there is ONLY a complete implementation.
>
> That implementation might be buildable out of building blocks, but as
> far as the Standard is concerned, it is the responsibility of the entity
> that puts it all together to make sure the results is 'Conforming'.
>
> GCC, for example, it just a piece of an implementation, mostly the piece
> called the 'compiler' (which I don't think is actually a defined term
> for the Standard), and includes documentation for how to combine it with
> the other pieces.
>
> THere are library vendors who will provide other pieces of the
> implementation, and documentation of how to combine it with other pieces
> to make an implementation.
>
> THen someone takes these pieces and creates the actual implementation.
> They depend on the documentation from the various component vendors to
> help them ensure that they make a 'Conforming' Implementation. If they
> did the job right, it will be (or at least as close as practical
> software will be to meeting some specification).
>
> Sometimes the integrator intentionally makes the combination
> non-conforming because that meets their needs better (perhaps adding a
> non-conforming extension to the implementation). This is perfectly fine
> too, 'Conformance' isn't the only criteria to judge an implementation by.

Hmm. I agree with you, and I'm not sure how you disagree (slightly)
with me. The discussion was about typical implementations.

--
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 */

John Bode <jfbode1029@gmail.com> writes:

> On 7/11/21 2:26 AM, Tim Rentsch wrote:
>
>> John Bode <jfbode1029@gmail.com> writes:
>>
>>> On 6/24/21 12:33 PM, Tim Rentsch wrote:
>>>
>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> To reiterate a point I make a lot - typedef on its own creates
>>>>> leaky abstractions. If I need to know that I have to use the
>>>>> `.` or `->` operator on something, I'd rather have it declared
>>>>> as `struct A foo;` or `struct B *ptr;` instead of a type name
>>>>> that doesn't convey struct-ness at all. Same reason I don't
>>>>> like it when people hide pointers behind typedefs - I once spent
>>>>> half a day chasing my tail because somebody created a typedef
>>>>> name for a pointer type and used that as a template parameter
>>>>> for a vector in C++, such that when I was using an iterator I
>>>>> needed to write
>>>>>
>>>>> (*it)->do_something();
>>>>>
>>>>> However, since the typedef name didn't indicate pointer-ness *at
>>>>> all*, I wound up writing
>>>>>
>>>>> it->do_something();
>>>>>
>>>>> and g++ vomited up hundreds of incomprehensible error messages
>>>>> that basically boiled down to "you need to use a * here, dummy".
>>>>
>>>> Sounds to me like the culprit is C++, not typedefs.
>>>
>>> g++ doesn't handle errors in template parameters very well and
>>> generates a *lot* of hard-to-follow error messages for relatively
>>> simple mistakes. And at the time I was still relatively
>>> inexperienced with C++, which didn't help.
>>>
>>> But the typedef name (or, more properly, the incomplete and leaky
>>> abstraction introduced by that typedef name) was the actual
>>> culprit. [...]
>>
>> I stand by my earlier claim that the culprit here is C++
>> rather than typedefs.
>
> I honestly don't know how to make it any clearer. I lost time due
> to using the wrong syntax. I was using the wrong syntax because the
> information I needed in order to use the right syntax was hidden
> from me. That's not a function of it being C++, that's a function
> of the abstraction not being complete.

You reported a case in a C++ program where confusion of pointer
versus non-pointer generated "hundreds of incomprehensible error
messages", causing you to lose time tracking down the problem.
Consider an analogous case in C:

it.do_something();

with 'it' having the pointer-concealing-typedef'ed type. In gcc
this expression produce a one-line error message:

what.c:7:15: error: 'it' is a pointer; did you mean to use '->'?

and in clang pretty much the same. If we consider a case with a
type that is a pointer to the pointer-concealing-typedef'ed type,
such as:

it->do_something();

where we should have used

(*it)->do_something();

again gcc gives a one-line error message:

what.c:11:15: error: '*it' is a pointer; did you mean to use '->'?

and clang again pretty much the same.

In all of these cases fixing the problem takes perhaps 15 to 30
seconds. By far the larger part of the problem is C++, not any
"hidden" pointerness, which is why I say that the culprit here is
C++ rather than typedefs.

John Bode <jfbode1029@gmail.com> writes:

> Yeah, and what I'm saying is don't half-ass the abstraction - either
> make it fully abstract or don't bother. Don't hide the information
> I need to properly use the type behind a typedef. I would rather
> you leave the type "naked", even if it's more eye-stabby or a pain
> in the ass to type.

Note that what you're saying here is different from what you were
saying before. It isn't that putting pointerness inside typedefs
will per se cause problems, but only that you don't like them.
There's nothing wrong with having an opinion, but don't dress it
up as something more than what it is.

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

> Guillaume <message@bottle.org> writes:
>
>> Le 27/07/2021 a` 19:55, Keith Thompson a @C3{A9}crit :
>>
>>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>>
>>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>>
>>>>> If you're going to hide a struct or union type behind a typedef
>>>>> name, don't make me hunt down the typedef to know how to access
>>>>> the members - provide an API to do that for me.
>>>>
>>>> I don't find that reasonable; it's pretty common to make typedef
>>>> names for structures just to have a shorthand for declaring them,
>>>> without intending to create a fully opaque type with abstracted
>>>> operations.
>>>>
>>>> typedef struct version {
>>>> int major;
>>>> int minor;
>>>> } version_t;
>>>>
>>>> The typedef is co-located with the struct declaration; your
>>>> ediutor should be able to jump to the definition of version_t
>>>> which is the above line.
>>>
>>> I disagree. I prefer to refer to the type as "struct version" and
>>> not bother with the typedef.
>>
>> Okay,then certainly it's a matter of taste, and that can't be
>> discussed.
>>
>> All I'm seeing though is that your argument could be used for just
>> any type really. Any typedef "hides" the type. It's made for
>> that. It's an abstraction. It's the whole point. Are you for
>> typeless languages?
>>
>> Or, what is it that you specifically have with structs that you
>> wouldn't mind with other types? Like, why does it bother you not
>> to directly see that a type is a struct, while the fact it's an
>> int, a double, or an array would matter to you? In any case, you
>> must know what a given type is for properly using it.
>
> Consider abstract types such as pid_t or off_t. [...]

Neither off_t nor pid_t is an abstract type. Both are signed
integer types with defined meanings for the values. In the case
of off_t, the value is how many bytes to go forward or backward.
In the case of pid_t, the value is the identifying number of the
process, with two distinguished values (0 and -1) that mean
something else. Knowing the identifying number of a process is
useful for comparing with things like 'ps' output. Also, even if
the identifying number of a process isn't especially useful by
itself, that the value is a signed integer can be useful for
other uses such as sorting or producing hash values. Such things
would not be available if these types were truly abstract types.

What these type names do provide is some amount of information
hiding, in particular how wide the underlying integer type is.
In most cases code doesn't need to know exactly how wide the
underlying type is. Following the principle (in programming)
that if it isn't really important to know something then it's
better not to know it, information about exactly which integer
types are used is hidden behind a typedef name.

> When you hide a struct behind a typedef, it's not opaque,
> as the field names are not generic (there was a time when any
> field name could be used with any pointer, but that's long in
> the past now).

Using a typedef name for a struct type similarly provides a
degree of information hiding. If there are 25 "clients" of a
struct type, and only 5 of them actually make use of the type's
"structness" (with . or ->), the other 20 can be written without
regard to whether the type is a struct or it isn't. The
principle of information hiding says doing that has value.
Conversely, not using a typedef name for said struct type forces
every client to be aware of the type being a struct type, whether
they need to know that or not. That's an unfortunate consequence
of a rule prohibiting the use of typedefs for struct types.

> I generally fall into Keith's camp on this in C, and in C++
> I never use typedef to hide a struct (the struct tag is,
> in a sense, a typedef in C++).

In many cases struct types are used as "mostly abstract" types,
with only a few use points needing to make use of member access.
In such cases it's nice to have the option of using a typedef so
that the type name reflects the dominant use case.

Michael S <already5chosen@yahoo.com> writes:

> On Wednesday, August 11, 2021 at 4:55:41 PM UTC+3, Scott Lurndal wrote:
>
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Wednesday, August 11, 2021 at 11:34:16 AM UTC+3,
>>> anti...@math.uni.wroc.pl wrote:
>>> [...]
>>> strcat() should have been deprecated in 1989 with replacement that
>>> returns something potentially useful, e.g. pointer to
>>> termination character of result string or length of result string.
>>> Or return nothing, which still would be an improvement.
>>>
>>> But committees have their own logic.
>>
>> Having been a member of those committees for a decade, I'll point
>> out that deprecating or changing the semantics of strcat
>
> For me, deprecation does not mean *immediate* removal. For me, it
> mean that we threaten to remove a function in 15 years time and
> are actually removing it after 30 years. Or never.

The ISO C standard normally uses the term "obsolescent" to
indicate a language or library feature that may be removed at
some indeterminate point in the future. If ever, and not
necessarily - some language or library features have been
termed "obsolescent" in earlier versions of the C standard
but restored to non-obsolescent status in later versions.

The ISO C standard normally uses the term "deprecated" to
indicate a language or library feature that is expected to be
removed in some subsequent version of the C standard. There is a
good chance that removal happens soon (e.g., in the next release)
but there is no guarantee of that.

> But in the mean time conforming compilers issue annoying
> diagnostics.

The ISO C standard does not require diagnostics either for
obsolescent features or deprecated features. I think it's common
for implemenations to issue diagnostics for deprecated features
but that is completely up to the implementation. And of course
an implementation is free to issue diagnostics for anything it
wants to, as long as it accepts all strictly conforming programs
(and using obsolescent or deprecated features doesn't violate
that condition, IIANM).

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Bart <bc@freeuk.com> writes:
> [SNIP]
>
>>> And it's hilarious that you have yet to acknowledge that you
>>> lied about something I wrote here, falsely claiming that I had
>>> said that the end user must obtain the components for a C
>>> implementation from different sources and mix and match them.
>>
>> So then you admit that a C implementation usually comes as a
>> ready-made bundle WITH a compiler, headers, library (or
>> arrangements for the library) INCLUDING functions like printf,
>> and any other tools necessary to turn source into runnable code?
>
> I do not "admit" it. The word "admit" implies that I've
> previously stated otherwise. [...]

In normal English usage the word "admit" neither requires nor
implies a previous statement to the contrary. For example, in
court a defendent may admit guilt without have made any previous
statement regarding guilt or innocence before pleading guilty.
Books and newspaper articles offer countless other examples.

Michael S <already5chosen@yahoo.com> writes:

[...]

> The purpose of my_pritntf() is to prevent buffer overflows [...]
> rather than to always output something meaningful. [...]

Sounds useful and practical.

> [..some whitespace added in what follows..]
>
> #include <stdio.h>
> #include <limits.h>
> #include <stdarg.h>
>
> #include "my_snprintf.h"
>
> // my_snprintf - Write formatted output to sized buffer
> // my_snprintf is similar to snprintf() with following modifications
> //
> // 1. Argument n is signed. For n <= 0 the function does nothing
> // and returns 0
> //
> // 2. Return value is always a number of characters that have been
> // into s, not counting the terminating null character.
> //
> // The rest of description applies to case of positive n.
> // Unlike snprintf(), if an encoding error occurs, a 0 is returned
> // and the terminating null character is written to s[0].
> // Unlike snprintf(), if n had not been sufficiently large, a
> // value of n-1 is returned and the terminating null character is
> // written to s[n-1].
>
> int
> my_snprintf(char * s, ptrdiff_t n, const char * format, ...)
> {
> if (n <= 0)
> return 0;
> if (n > INT_MAX)
> n = INT_MAX;
>
> va_list args;
> va_start(args, format);
> int ret = vsnprintf(s, n, format, args);
> if (ret < 0)
> { // encoding error.
> // since our code uses no UNICODE, it should never happen,
> // but let's handle it nevertheless
> s[0] = 0; // may be, unnecessary
> return 0;
> }
>
> if (ret >= n) {
> s[n-1] = 0; // most likely unnecessary
> return n-1;
> }
>
> return ret;
> }

Some short comments:

One: signed types have issues. Rather than using a signed type
for the parameter 'n', use a large unsigned type such as unsigned
long long. Doing that still allows arguments having a signed
type to be checked for negative values, following the rules for
conversion of a signed value to an unsigned type.

Two: va_start() always requires a corresponding va_end().

Three: when supplying a *printf() function, it is customary to
supply also a corresponding *vprintf() function, which makes
writing the non-v form straightforward. It's two functions for
the price of one (plus only a little bit). Also it makes the
habit of using va_end() along with va_start() fall out with
essentially no effort.

To illustrate these points in C code, here is a revised writing
of my_snprintf(), along with my_vsnprintf();

// --- cut here ---

#include <limits.h>
#include <stdio.h>
#include <stdarg.h>

typedef unsigned long long ULL;

extern int my_vsnprintf( char *, ULL, const char *, va_list );

int
my_snprintf( char * s, ULL n, const char * format, ... ){
va_list args;
int r;

va_start( args, format );
r = my_vsnprintf( s, n, format, args );
va_end( args );

return r;
}

int
my_vsnprintf( char * s, ULL n0, const char * format, va_list args ){
if( n0 > -1ULL>>1 || n0 == 0 ) return 0;

size_t n = n0 > INT_MAX ? INT_MAX : n0;

int ret = vsnprintf( s, n, format, args );

return
ret < 0 ? s[0] = 0, 0 :
ret >= n ? s[n-1] = 0, n-1 :
ret;
}

On 10/1/2021 1:44 PM, Tim Rentsch wrote:
>
> The ISO C standard normally uses the term "obsolescent" to
> indicate a language or library feature that may be removed at
> ...
> The ISO C standard normally uses the term "deprecated" to
> indicate a language or library feature that is expected to be
> ...

Um...

The ISO C standard uses the term "obsolescent" to refer to features
marked for future removal. ISO C standard does designate the word
"deprecated" as a standard term. One can encounter the word "deprecated"
in the standard text, but it is never used to refer to language features.

"Deprecated" is used by C++ standard. "Deprecated" in C++ is an exact
synonym of "obsolescent" in C.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 10/1/2021 1:44 PM, Tim Rentsch wrote:
>
>> The ISO C standard normally uses the term "obsolescent" to
>> indicate a language or library feature that may be removed at
>> ...
>> The ISO C standard normally uses the term "deprecated" to
>> indicate a language or library feature that is expected to be
>> ...
>
> Um...
>
> The ISO C standard uses the term "obsolescent" to refer to
> features marked for future removal.

No, it doesn't. ISO C standard, Introduction, paragraph 2:

Certain features are /obsolescent/, which means that they may
be considered for withdrawal in future revisions of this
International Standard.

Note the phrase "may be considered". (The slant characters around
the word obsolescent indicate italics, meaning a definition.) Such
features may be /considered/ for removal, but they are not /marked/
for removal.

> ISO C standard does designate the word "deprecated" as a standard
> term.

None of the several versions of the ISO C standard that I looked
at give a definition for "deprecate" or "deprecated". All use
the word, but none of them define it.

> One can encounter the word "deprecated" in the standard text, but
> it is never used to refer to language features.

Certainly it is is. For example N1256, which is C99 plus three
technical corrigenda, says this in 7.26.9 paragraph 2:

The gets function is obsolescent, and is deprecated.

> "Deprecated" is used by C++ standard. "Deprecated" in C++ is an
> exact synonym of "obsolescent" in C.

No, it isn't. A feature being obsolescent in C means only that
it "may be considered" at a later time, whereas a feature being
deprecated in C++ means that it "[has] been identified" as being
subject to removal in a later standard. The word obsolescent is
tentative, the word deprecated more definite. The two terms may
be related but they are not the same.