Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> On 2024-03-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:

>> * Each shared object that simulates a Data Link Processor (DLP), will
>> * contain a single namespace-scope function <b>get_dlp</b> which constructs
>> * a DLP object of the specified type (for example, a #c_uniline_dlp,
>> * #c_card_reader_dlp, et alia). <b>get_dlp</b> returns the constructed
>> * object as a #c_dlp object to the #channel function, which is then used
>> * by the I/O subsystem to request services of the DLP at the MLI level.
>> */
>> typedef c_dlp* (*get_dlp_t)(const char *, uint64_t, c_logger *);
>> ...
>> get_dlp_t sym;
>> ...
>>
>> sym = (get_dlp_t)dlsym(handle, "get_dlp");
>> if (sym == NULL) {
>> lp->log("Invalid DLP shared object format: %s\n", dlerror());
>> unregister_handle(channel);
>> dlclose(handle);
>> return 1;
>> }
>>
>>
>>> I think there was a time in the development of GCC when there was
>>> a warning even with the cast. I don't think it's enabled by default
>>> now?
>>
>> We compile with -Wall -Werror and have never seen any warnings related to
>> casting the result of dlsym(), and we build with GCC[4..13].
>
>Do you use -pedantic? Compiling with -pedantic using gcc 8.4.0
>gives a warning diagnostic (and a fatal error if -pedantic-errors
>is specified in place of -pedantic).

Of course not. We write production code not standard C (or in this
case, C++) code. Portability to compilers other than gcc is
not a requirement for the several million line codebase.

On Sat, 30 Mar 2024 19:29:50 GMT, Scott Lurndal wrote:

> We write production code not standard C (or in this
> case, C++) code. Portability to compilers other than gcc is
> not a requirement for the several million line codebase.

Interesting. Has GCC become the de-facto-standard C compiler?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sat, 30 Mar 2024 19:29:50 GMT, Scott Lurndal wrote:
>
>> We write production code not standard C (or in this
>> case, C++) code. Portability to compilers other than gcc is
>> not a requirement for the several million line codebase.
>
>Interesting. Has GCC become the de-facto-standard C compiler?

I'm not sure how you derived that conclusion from a single
proprietary project description.

Our target is linux. gcc is more than sufficient for the
task.

On 31/03/2024 00:05, Lawrence D'Oliveiro wrote:
> On Sat, 30 Mar 2024 19:29:50 GMT, Scott Lurndal wrote:
>
>> We write production code not standard C (or in this
>> case, C++) code. Portability to compilers other than gcc is
>> not a requirement for the several million line codebase.
>
> Interesting. Has GCC become the de-facto-standard C compiler?

gcc is the most commonly used compiler on Linux and in embedded systems.
It is not the most common on Windows, AFAIK - that honour goes to
MSVC. A number of gcc extensions, practices and flags have been copied
by other compilers (such as clang, icc, and others). A number of
features that started off as gcc extensions ended up in the C standards
- more, I think, than for extensions of any other compiler.

If you consider that to mean gcc is the "de-facto-standard C compiler",
that's up to you - it is not the standard C compiler in the context of
comp.lang.c, where "standard" refers to the C standards, since there is
no C standard reference compiler. But the term "de-facto standard" is
so vague and poorly defined that you can use it any way you like,
without conveying any useful information.

I can't speak for Scott, but in my work I happily use gcc extensions
(though I don't use them when standard C does as good a job). I don't
do that because it is a "de-facto standard" or anything of the sort - I
use gcc extensions when they let me write better code or give better
results, since my code does not normally have to be portable to other
compilers. If I happen to be working on a project that uses a different
compiler, I'll happily use extensions for that compiler too.

On 3/30/2024 4:05 PM, Lawrence D'Oliveiro wrote:
> On Sat, 30 Mar 2024 19:29:50 GMT, Scott Lurndal wrote:
>
>> We write production code not standard C (or in this
>> case, C++) code. Portability to compilers other than gcc is
>> not a requirement for the several million line codebase.
>
> Interesting. Has GCC become the de-facto-standard C compiler?

I don't think so.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>
>>>> On 2024-03-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>
>>> * Each shared object that simulates a Data Link Processor (DLP),
>>> * will contain a single namespace-scope function <b>get_dlp</b>
>>> * which constructs a DLP object of the specified type (for example,
>>> * a #c_uniline_dlp, #c_card_reader_dlp, et alia). <b>get_dlp</b>
>>> * returns the constructed object as a #c_dlp object to the #channel
>>> * function, which is then used by the I/O subsystem to request
>>> * services of the DLP at the MLI level.
>>> */
>>> typedef c_dlp* (*get_dlp_t)(const char *, uint64_t, c_logger *);
>>> ...
>>> get_dlp_t sym;
>>> ...
>>>
>>> sym = (get_dlp_t)dlsym(handle, "get_dlp");
>>> if (sym == NULL) {
>>> lp->log("Invalid DLP shared object format: %s\n", dlerror());
>>> unregister_handle(channel);
>>> dlclose(handle);
>>> return 1;
>>> }
>>>
>>>
>>>> I think there was a time in the development of GCC when there was
>>>> a warning even with the cast. I don't think it's enabled by default
>>>> now?
>>>
>>> We compile with -Wall -Werror and have never seen any warnings related
>>> to casting the result of dlsym(), and we build with GCC[4..13].
>>
>> Do you use -pedantic? Compiling with -pedantic using gcc 8.4.0
>> gives a warning diagnostic (and a fatal error if -pedantic-errors
>> is specified in place of -pedantic).
>
> Of course not. We write production code not standard C (or in this
> case, C++) code. Portability to compilers other than gcc is
> not a requirement for the several million line codebase.

It's quite amusing to hear of a team that insists on -Wall but
avoids -pedantic, saving a tiny drizzle of cases (all of which
are easy to remedy) while enduring the ever-changing force 5
blizzard of conditions tested by -Wall.

bart <bc@freeuk.com> writes:

> On 30/03/2024 09:32, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> I was aware of the double conversion but KT used 'a cast' so I
>>> wondered if there was a single cast that could be used.
>>
>> There is not, if it's important that it work reliably across
>> different compilers and different platforms.
>>
>>> It is odd however that function and object pointers can be
>>> considered so different that even an explicit conversion
>>> between them is deemed to be meaningless.
>>
>> Function pointers and object pointers don't have to be the same
>> size, or use the same form of representation. The C standard
>> allows implementations where code and data live in completely
>> separate memories. In such cases there is no sensible way to
>> convert between the two kinds of pointers, because the two kinds
>> of addresses have no relationship to each other.
>
> Suppose a object pointer is 32 bits, and a function pointer is a
> 32-byte descriptor.
>
> An implementation could choose to present a function pointer as a
> 32-bit object pointer, which points to the full 32-byte descriptor in
> data memory.
>
> The simplest way of doing that is to have, for each function (or each
> one whose address is taken), a fixed corresponding descriptor in data
> memory. So here function and object pointers can be exactly the same
> size, and can both refer to data memory, as far as the programmer is
> concerned.
>
> Dereferencing such a function pointer, to call the function, will
> involve an extra bit of indirection. It would need something extra
> anyway to deal with those 32 bytes.

Two problems. One, even if the proposed scheme is workable in some
cases that doesn't mean it will be in all cases. Two, it imposes
what may be a significant cost but offers essentially no benefit.
The only useful thing that can be done with a converted function
pointer is cast it to an appropriate function pointer type so that
the function can be called. If someone wants to have values and
variables that can hold both object pointers and function pointers
it is easy enough to do that by using a union:

typedef union { void *pv; void (*pf)(); } VorF;

with no hidden implementation machinery needed. There is no good
reason to gussy up the language or have implementations jump
through hoops when the needed capability is already present in
the language as it is now (and has been for more than 30 years).

On 09/04/2024 08:01, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:

>>>> We compile with -Wall -Werror and have never seen any warnings related
>>>> to casting the result of dlsym(), and we build with GCC[4..13].
>>>
>>> Do you use -pedantic? Compiling with -pedantic using gcc 8.4.0
>>> gives a warning diagnostic (and a fatal error if -pedantic-errors
>>> is specified in place of -pedantic).
>>
>> Of course not. We write production code not standard C (or in this
>> case, C++) code. Portability to compilers other than gcc is
>> not a requirement for the several million line codebase.
>
> It's quite amusing to hear of a team that insists on -Wall but
> avoids -pedantic, saving a tiny drizzle of cases (all of which
> are easy to remedy) while enduring the ever-changing force 5
> blizzard of conditions tested by -Wall.

I guess that's because his team writes real-world code using real-world
tools, rather than living in some sort of fantasy realm or ivory tower.

gcc's -Wall does not change much from version to version, and not
without a lot of debate and consideration. A new warning does not get
added to -Wall unless there is strong confidence and agreement that it
will have a very low rate of false positives, and the things it catches
have a high rate of being real problems (not just stylistic choices).
And part of the beta test procedure involves complete rebuilds of the
entire Debian and Red Hat source bases - many packages would fail to
build if changes to -Wall triggered new warnings.

And most real-world C programs are not strictly limited to fully
portable standard C. If portability is not an issue, then compiler
extensions give you a better language - better error checking, more
efficient results, easier coding, clearer coding, and of course features
that are tied to the target platform. "-pedantic" is not helpful for
such code.

Of course there are also people whose C coding must be strictly
according to the standards, and there are endless other variants in how
people use the language, tools and flags. But I expect the use of
"-Wall" without "-Wpedantic" to be very much more common than the opposite.