On 10/08/2023 08:38, David Brown wrote:
> On 09/08/2023 14:32, Bart wrote:
>> On 09/08/2023 12:05, Dan Purgert wrote:
>> > On 2023-08-09, Bart wrote:
>> >> On 09/08/2023 03:04, Ben Bacarisse wrote:
>>
>> >> How does it know then to deal with prog.c and not prog.cpp or
>> prog.ftn?
>> >
>> > Because you wrote your makefile target such that it's dealing with
>> > "prog.c" and not prog.cpp or prog.ftn. Make isn't intelligent in the
>> > case of changing file extensions or similar. For example, renaming
>> > "prog.c" to "prog.cpp" will result in 'file not found' errors when
>> make
>> > is trying to run the defined 'gcc prog.c -o prog' command.
>>
>> I was replying to a post that says you can use 'make' without any
>> makefile; give it a filename, not even an extension, and it can
>> determine exactly what you want to do, even though it is not specific
>> to a language or compiler.
>>
>
> You can. Make installations usually have a set of default rules that
> work in simple cases.
>
> But if you have a more advanced case, you need at least some rules in
> your makefile. Surely this is not a surprise to you.

Compared to what I normally do, 'make' is neolithic.

Given the lead module 'prog.m' of any project, no matter where it is
located:

mm prog # compiles to prog.exe
ms prog # compiles and runs it (there is no .exe)

Given the lead module 'prog.q' of any scripting project:

qq prog # runs it

'make'? Where are we, in the 1980s still? (Even then /I/ was using IDEs
that whizzed through the modules of my projects!)

So all this stuff about extensions and gcc and make, for me is a
sideshow. It's only relevant when stuff to do with C comes up.

>> * You have to supply the extension (I hate that)
>
> We all feel /so/ sorry for you. Imagine having to type ".c" sometimes -
> the horror! If you add up all the Usenet posts you've made complaining
> about trivia, it would cover many lifetimes' worth of ".c" or "_t".

It is not sometimes, it's pretty much every time you run a language
tool; this is not limited to C, or compilers.

On Linux, it even applies to running executables. I imagine this is one
reason why Linux executable files don't have have extensions, otherwise
you'd have to do 'gcc.exe prog.c'.

/My/ tools tend to work on a specific file type, which becomes the
default since 100% of inputs will have that extension; what is the point
of typing it?

They are a total joy to use.

Yes, I know that gcc works on a million different languages, that was a
mistake. (Although in that case, what is the purpose of having 'g++'?)

Anyway all you suckers can keep typing your extensions; it's no skin off
my nose!

>> You have to define set of dependences between modules (and you may
>> need to do that manually, so it can be error prone).
>>
>
> I do it all automatically. But you'll blow a fuse if I try to tell you
> how.

At what point in C's evolution did that come about? And is it a reason
why it never acquired a proper module system?

In any case, if it can do automatically, presumably via some special
incantations fed to gcc, why is there a need for a makefile; why doesn't
gcc use its special powers to determine what to compile, using those
same incantations?

In my latest module system, there is nothing clever: all the modules
comprising a project are listed in the lead module. (In the 1980s, they
were listed in a project file the IDE used.)

You have to list a set of all enum names; modules are no different.

Only my C compiler tries something clever to discover all the modules
comprising a project, by recursively following #includes starting from
the lead modules. But it can't work in general because the pattern of .h
and .c files in C can be chaotic.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>

>> So how does make help here?
>
>There go the goalposts again. Why would it? Mind you, I don't like
>your commands since they overwrite the same executable. When comparing
>compilers and flags I use a one-line shell function so that the output
>file is, for example, 'gcc-O1-prog'.

Indeed, even something as simple as

make NO_OPTIMIZE

is sufficient if the makefile is properly written.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-09, Bart <bc@freeuk.com> wrote:
>> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
>
>If I were to guess, it's because the only person in the world who cares
>about it just complains in a newsgroup, that nobody in GCC development
>reads.
>
>Plus there are probably scripts out there that depend on a.out
>popping out of the compiler.
>
>(The GCC people don't even read the mailing list intended for GCC
>patches. In April 2022 I submitted a change (documented and test cased).
>Pinged a few times over the following six months. Never got a reply.)

That doesn't mean it wasn't read.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-10, Bart <bc@freeuk.com> wrote:
>> On 10/08/2023 01:21, Kaz Kylheku wrote:
>> > On 2023-08-09, Bart <bc@freeuk.com> wrote:
>> >> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
>> >
>> > If I were to guess, it's because the only person in the world who cares
>> > about it just complains in a newsgroup, that nobody in GCC development
>> > reads.
>> >
>> > Plus there are probably scripts out there that depend on a.out
>> > popping out of the compiler.
>>
>> How many depend on a.exe coming out of it?
>
>That's not easily knowable.

Perhaps not, but it is a logical extention of the historic practice
of generating a.out on unix-like systems with suitable modification
for the windows file extension scheme.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Thursday, 10 August 2023 at 01:21:40 UTC+1, Kaz Kylheku wrote:
>> On 2023-08-09, Bart <b...@freeuk.com> wrote:
>> > So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
>> If I were to guess, it's because the only person in the world who cares
>> about it just complains in a newsgroup, that nobody in GCC development
>> reads.
>>
>When I first used it, I thought it was a bit odd. Especially when the second
>run overwrote a.out instead of writing b.out.

As Keith pointed out, 'a.out' was the output from the assembler
back in the day.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:

>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>> just a fact.
>
>2+2 = 4. That's just a fact.

Indeed, and it is a fact for _any_ library containing optional functionality
that is needed by the application.

Bart <bc@freeuk.com> writes:
>On 09/08/2023 23:15, David Brown wrote:

>
> > Only a perverse masochist would want to have the same output file for
> > all of these, as they would be impossible to test.
>
>Well, they /are/ the same program! The thing about gcc is that it keeps
>using the same output file even for DIFFERENT programs.

No, it doesn't. You are the only person in the world that doesn't
specify the -o option to the tool chain.

On 07/08/2023 17:05, Ben Bacarisse wrote:
> Hmm... With statically allocated strings, or using malloc and therefore
> requiring free call not shown?
>
> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
> macro:
>
> typedef float salary_t;
> #define FMT_SALARY "f"
>
> typedef unsigned long int payrollid_t;
> #define FMT_PAYROLLID "lu"
>
> so that one can write
>
> printf("Hello %s your salary is %" FMT_SALLARY
> ", your payrollid %" FMT_PAYROLLID "\n",
> employee.name, employee.salary, employee.payrollid);
>
> -- Ben.

Ben, if you put floating points in money accountants get upset.

Three employees are paid $100.00, so it adds up to $300.

Deduct $20 from each, and it's $240.

Use floating point and sooner or later it won't add up. You can't have a
third of a cent.

Use integers and cents for money. Or pounds, shekels, whatever...

Andy

Michael S <already5chosen@yahoo.com> writes:

> On Thursday, August 10, 2023 at 2:01:55 AM UTC+3, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 09/08/2023 03:04, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >>
>> >>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>> >>>>
>> >>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>> >>>> variable to the name of the compiler:
>> >>>>
>> >>>> CC=bcc
>> >>>> ...
>> >>>> %.o: %.c
>> >>>> @$(QUIET) || echo " COMPILE $<"
>> >>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>> >>>>
>> >>> Exactly,
>> >>> Bart is right.
>> >>
>> >> You are deliberately ignoring the context. Bart wants gcc prog.c to
>> >> write to prog, but in the computer world I inhabit, you do that with
>> >> make prog.
>> >
>> > This is a good example of double standards.
>> >
>> > I've complained in the past about having to supply the .c extension to a
>> > /C/ compiler.
>> >
>> > Now here make does not need an extension.
>>
>> I call it consistency. A compiler is given the file to process, make is
>> given the file to build (AKA "make").
>
> I disagree.

OK, but your disagreement is about something else.

> Consistent design, a.k.a. principle of minimal surprise, would be for
> basal utility 'make' to have no built-in rules. On top of it, system
> can supply one or more extended utilities, probably implemented as
> shell scripts, that do have built-in rules.

So you also disagree with Bart whose compiler has a built-in rule about
what file extension to assume. You probably won't bring that up, though.

--
Ben.

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Bart <bc@freeuk.com> writes:
>
>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>> just a fact.
>>
>>2+2 = 4. That's just a fact.
>
> Indeed, and it is a fact for _any_ library containing optional functionality
> that is needed by the application.

That's only true in a circular way. Why are the math functions
considered optional? Why not, for example, consider the IO functions
optional so that any program that includes <stdio.h> has to link with
-lio? (I know the history -- that's not what I'm asking.)

There's even a division that could be justified by the standard. Any
program that uses functions not required in a freestanding
implementation could be obliged to link with -lhosted, but requiring -lm
is just a historical barnacle.

--
Ben.

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 07/08/2023 17:05, Ben Bacarisse wrote:
>> Hmm... With statically allocated strings, or using malloc and therefore
>> requiring free call not shown?
>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>> macro:
>> typedef float salary_t;
>> #define FMT_SALARY "f"
>> typedef unsigned long int payrollid_t;
>> #define FMT_PAYROLLID "lu"
>> so that one can write
>> printf("Hello %s your salary is %" FMT_SALLARY
>> ", your payrollid %" FMT_PAYROLLID "\n",
>> employee.name, employee.salary, employee.payrollid);
>> -- Ben.
>
> Ben, if you put floating points in money accountants get upset.

I'm not. When I offer an alternative to someone's code, I change as
little as possible to keep the discussion focused. I took Malcolm's
QFMT_REAL to denote some real floating-point type.

--
Ben.

On 10/08/2023 15:25, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
>
>>> If working with Linux and you need -lm, then 'make prog' won't
work. That's
>>> just a fact.
>>
>> 2+2 = 4. That's just a fact.
>
> Indeed, and it is a fact for _any_ library containing optional
functionality
> that is needed by the application.
>

Yet, C programs can use `printf` without needing to specifically link in
a library for it. What's the difference with `sqrt`?

One difference is that many machines these days actually implement sqrt
in the hardware, but very few implement printf in hardware. Yet guess
which one is made optional.

How big is the library (libm.so?) anyway?

My own library from 8-bit days, where I also had to emulate basic
floating point arithmetic, was 4KB IIRC, on a 64KB machine. What's the
hit these days?

From stackoverflow answering why -lm is needed:

"Because of ridiculous historical practice that nobody is willing to
fix. Consolidating all of the functions required by C and POSIX into a
single library file would not only avoid this question getting asked
over and over, but would also save a significant amount of time and
memory when dynamic linking, since each .so file linked requires the
filesystem operations to locate and find it, and a few pages for its
static variables, relocations, etc."

https://stackoverflow.com/questions/1033898/why-do-you-have-to-link-the-math-library-in-c

On Windows, such functions are in msvcrt.dll, and the total size of
that, for 1400 functions in total, is 700KB. But since it is so widely
used, it is near-100% certain that it is already in memory.

(I suspect libm is already incorporated into a bigger library, but '-lm'
is needed for 'historical' reasons.)

But this is by the by; in my stuff I haven't needed to worry about
special options to include maths libraries since ... never. Other than
having to /implementent/ such libraries and support.

I'm just bemused by C users (and on Linux) having to bother themselves
with it.

On 10/08/2023 15:38, Vir Campestris wrote:
> On 07/08/2023 17:05, Ben Bacarisse wrote:
>> Hmm...  With statically allocated strings, or using malloc and therefore
>> requiring free call not shown?
>>
>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>> macro:
>>
>>    typedef float salary_t;
>>    #define FMT_SALARY "f"
>>
>>    typedef unsigned long int payrollid_t;
>>    #define FMT_PAYROLLID "lu"
>>
>> so that one can write
>>
>>    printf("Hello %s your salary is %" FMT_SALLARY
>>           ", your payrollid %" FMT_PAYROLLID "\n",
>>           employee.name, employee.salary, employee.payrollid);
>>
>> -- Ben.
>
> Ben, if you put floating points in money accountants get upset.
>
> Three employees are paid $100.00, so it adds up to $300.
>
> Deduct $20 from each, and it's $240.
>
> Use floating point and sooner or later it won't add up. You can't have a
> third of a cent.
>
> Use integers and cents for money. Or pounds, shekels, whatever...

How does that work out for calculating daily compound interest?

Or even working out 6.9% sales tax on $199.99?

You need to follow whatever guidelines are mandated for rounding
intermediate results.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>Bart <bc@freeuk.com> writes:
>>
>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>> just a fact.
>>>
>>>2+2 = 4. That's just a fact.
>>
>> Indeed, and it is a fact for _any_ library containing optional functionality
>> that is needed by the application.
>
>That's only true in a circular way. Why are the math functions
>considered optional? Why not, for example, consider the IO functions
>optional so that any program that includes <stdio.h> has to link with
>-lio? (I know the history -- that's not what I'm asking.)
>
>There's even a division that could be justified by the standard. Any
>program that uses functions not required in a freestanding
>implementation could be obliged to link with -lhosted, but requiring -lm
>is just a historical barnacle.

Yes, it's historical, and an artifact of small memory systems and
archive libraries.

None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
-ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
driver (cc)?

On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>Bart <bc@freeuk.com> writes:
>>>
>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>>> just a fact.
>>>>
>>>>2+2 = 4. That's just a fact.
>>>
>>> Indeed, and it is a fact for _any_ library containing optional functionality
>>> that is needed by the application.
>>
>>That's only true in a circular way. Why are the math functions
>>considered optional? Why not, for example, consider the IO functions
>>optional so that any program that includes <stdio.h> has to link with
>>-lio? (I know the history -- that's not what I'm asking.)
>>
>>There's even a division that could be justified by the standard. Any
>>program that uses functions not required in a freestanding
>>implementation could be obliged to link with -lhosted, but requiring -lm
>>is just a historical barnacle.
>
> Yes, it's historical, and an artifact of small memory systems and
> archive libraries.
>
> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> driver (cc)?

This is entirely feasible, technologically.

As a pretty simple hack, header files for these libraries could
declare the "soname" that is required to call their functions.

The compiler would attach that to the declarations made in those
headers and then if any of those symbols are referenced, append
the -l<soname> to the linker line.

In the Microsoft Visual C/C++ world, a source file can indicate that it
needs a particular DLL, so that it doesn't have to be specified on the
command line.

Another solution would be entirely at run-time.

What we could have is that an executable just dynamically links to
functions in these libraries, and the system automatically finds them at
load time, without the executable having to specify which libraries.

(Symbolic references would have to be fastidiously versioned since
if multiple versions of a library were installed, the executable would
not be indicataing which file it wants, other than through the
names it needs. And also for another reason: clashing names between
libraries. But the programmer wouldn't see the library and verison
qualification on the symbol; that's handled transparently by the
toolchain.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
> On 07/08/2023 17:05, Ben Bacarisse wrote:
>> Hmm... With statically allocated strings, or using malloc and therefore
>> requiring free call not shown?
>>
>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>> macro:
>>
>> typedef float salary_t;
>> #define FMT_SALARY "f"
>>
>> typedef unsigned long int payrollid_t;
>> #define FMT_PAYROLLID "lu"
>>
>> so that one can write
>>
>> printf("Hello %s your salary is %" FMT_SALLARY
>> ", your payrollid %" FMT_PAYROLLID "\n",
>> employee.name, employee.salary, employee.payrollid);
>>
>> -- Ben.
>
> Ben, if you put floating points in money accountants get upset.
>
> Three employees are paid $100.00, so it adds up to $300.
>
> Deduct $20 from each, and it's $240.
>
> Use floating point and sooner or later it won't add up.

Use floating-point *naively* and the truncation errors will accumulate
to the point of making at least a one cent difference, screwing up the
accounting.

Use floating-point intelligently and that won't happen.

> You can't have a third of a cent.

That is neither here nor there.

You can't have a third of a cent in accounting, because accounting is
decimal based, at least with US dollars and similar currencies,
where you don't have beasties like sixths of a dollar.

"Third of a cent" is a financial quantity nobody works with, in any
representation of dollars. And even if they did, floating point
could handle it just fine, if everyone agreed that around 15
digits of precision is good enough.

The problem specific to floating point is that you can't have a
hundredth of a dollar in floating point, if 1.0 is used to represent
$1.00.

However, floating-point will give you a ridiculously precise
approximation of 0.01.

You have to do many calculations before enough error accumulates
so that the result goes to the wrong penny.

There is a way to prevent accumulating error: after each calculation,
snap the result to the nearest cent (or whatever fundamental fraction
you are working with, tenth of a cent, ...).

If, after each calculation, you ensure that it has the best
floating-point approximation of the result that pencil-and-paper
accounting would produce, you cannot have a problem. Almost.

The remaining issue is that you get so rich that the dollar amounts you
are working with can no longer represent individual pennies in floating
point.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>Bart <bc@freeuk.com> writes:
>>>
>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>>> just a fact.
>>>>
>>>>2+2 = 4. That's just a fact.
>>>
>>> Indeed, and it is a fact for _any_ library containing optional functionality
>>> that is needed by the application.
>>
>>That's only true in a circular way. Why are the math functions
>>considered optional? Why not, for example, consider the IO functions
>>optional so that any program that includes <stdio.h> has to link with
>>-lio? (I know the history -- that's not what I'm asking.)
>>
>>There's even a division that could be justified by the standard. Any
>>program that uses functions not required in a freestanding
>>implementation could be obliged to link with -lhosted, but requiring -lm
>>is just a historical barnacle.
>
> Yes, it's historical, and an artifact of small memory systems and
> archive libraries.
>
> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> driver (cc)?

Of course not. But the functions in <math.h> are part of the C language
just like malloc and printf. It's not the same kind of thing at all.

--
Ben.

On Thursday, August 10, 2023 at 6:53:26 PM UTC+3, Scott Lurndal wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >sc...@slp53.sl.home (Scott Lurndal) writes:
> >
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >>>Bart <b...@freeuk.com> writes:
> >>
> >>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
> >>>> just a fact.
> >>>
> >>>2+2 = 4. That's just a fact.
> >>
> >> Indeed, and it is a fact for _any_ library containing optional functionality
> >> that is needed by the application.
> >
> >That's only true in a circular way. Why are the math functions
> >considered optional? Why not, for example, consider the IO functions
> >optional so that any program that includes <stdio.h> has to link with
> >-lio? (I know the history -- that's not what I'm asking.)
> >
> >There's even a division that could be justified by the standard. Any
> >program that uses functions not required in a freestanding
> >implementation could be obliged to link with -lhosted, but requiring -lm
> >is just a historical barnacle.
> Yes, it's historical, and an artifact of small memory systems and
> archive libraries.
>
> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> driver (cc)?

When linking for Linux:
pthread - yes
ncurses - no
openssl - probably, not sure
For the rest of them, I don't know what they are.

On 10/08/2023 16:53, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>>> just a fact.
>>>>
>>>> 2+2 = 4. That's just a fact.
>>>
>>> Indeed, and it is a fact for _any_ library containing optional functionality
>>> that is needed by the application.
>>
>> That's only true in a circular way. Why are the math functions
>> considered optional? Why not, for example, consider the IO functions
>> optional so that any program that includes <stdio.h> has to link with
>> -lio? (I know the history -- that's not what I'm asking.)
>>
>> There's even a division that could be justified by the standard. Any
>> program that uses functions not required in a freestanding
>> implementation could be obliged to link with -lhosted, but requiring -lm
>> is just a historical barnacle.
>
> Yes, it's historical, and an artifact of small memory systems and
> archive libraries.
>
> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> driver (cc)?

The Windows program below uses the maths library, and the equivalent of
'dl'.

It builds to a 2.5KB executable (with my compiler, which is the minimum
size).

It automatically links to dynamic libraries msvcrt.dll, gdi32.dll,
kernel32.dll, user32.dll, all of which are likely already memory-resident.

Between them those export 5000 functions (and some variables), yet it
does not impact the executable size: they are shared libraries.

I don't need to muck about with -lm or -ldl.

(C is a little backward, but in my language, if the functions from a
particular library are declared with the FFI, it will automatically
include that DLL for dynamic linking.

In more complex cases (eg. functions are spread over diverse DLLs), the
DLLs have to be listed manually, but this is done in the source code. No
extra command line inputs are needed. The compiler input is always just
the name of the lead module.)

----------------------------------
#include <stdio.h>
#include <windows.h>
#include <math.h>

int main(void) {
void* handle;
void* fnptr;
double x=3.0;

handle=LoadLibrary("msvcrt.dll");

if (handle) {
fnptr=GetProcAddress(handle, "sqrt");
printf("fnptr=%p\n",fnptr);
} else {
puts("no lib");
}

printf("%f\n",sqrt(x));
}

On Thursday, August 10, 2023 at 6:08:45 PM UTC+3, Ben Bacarisse wrote:
> Michael S <already...@yahoo.com> writes:
>
> > On Thursday, August 10, 2023 at 2:01:55 AM UTC+3, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >> > On 09/08/2023 03:04, Ben Bacarisse wrote:
> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >>
> >> >>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >> >>>>
> >> >>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >> >>>> variable to the name of the compiler:
> >> >>>>
> >> >>>> CC=bcc
> >> >>>> ...
> >> >>>> %.o: %.c
> >> >>>> @$(QUIET) || echo " COMPILE $<"
> >> >>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >> >>>>
> >> >>> Exactly,
> >> >>> Bart is right.
> >> >>
> >> >> You are deliberately ignoring the context. Bart wants gcc prog.c to
> >> >> write to prog, but in the computer world I inhabit, you do that with
> >> >> make prog.
> >> >
> >> > This is a good example of double standards.
> >> >
> >> > I've complained in the past about having to supply the .c extension to a
> >> > /C/ compiler.
> >> >
> >> > Now here make does not need an extension.
> >>
> >> I call it consistency. A compiler is given the file to process, make is
> >> given the file to build (AKA "make").
> >
> > I disagree.
> OK, but your disagreement is about something else.
> > Consistent design, a.k.a. principle of minimal surprise, would be for
> > basal utility 'make' to have no built-in rules. On top of it, system
> > can supply one or more extended utilities, probably implemented as
> > shell scripts, that do have built-in rules.
> So you also disagree with Bart whose compiler has a built-in rule about
> what file extension to assume. You probably won't bring that up, though.
>
> --
> Ben.

Compiler and generic build utility are not in the same boat.
It is less surprising to have defaults in compiler than to have built-in
implicit rules in generic build utility.
But yes, I don't like Bart's decision to allow omission of .c.
However as long as his compiler is his personal toy I am not going to complain.

On 2023-08-10, Bart <bc@freeuk.com> wrote:
> On 10/08/2023 15:25, Scott Lurndal wrote:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >> Bart <bc@freeuk.com> writes:
> >
> >>> If working with Linux and you need -lm, then 'make prog' won't
> work. That's
> >>> just a fact.
> >>
> >> 2+2 = 4. That's just a fact.
> >
> > Indeed, and it is a fact for _any_ library containing optional
> functionality
> > that is needed by the application.
> >
>
> Yet, C programs can use `printf` without needing to specifically link in
> a library for it. What's the difference with `sqrt`?

It's just a historic baggage.

More programs in a system can be expected to use math functions
than, say, setsid()!

Why is setsid linked by default, but not math functions?

If even one program in a given system installation uses math function,
you save disk space by having that in the same library image
instead of a separate libm.so.6 (with wasteful symlinks thereto taking
up more inodes).

The fix is to have a dummy, empty library for those programs that
specify -lm in their build, so that they don't break.

I rember reading some article years ago about how some libary
was planning to remove the need for -lm; I seem to be misremember
that it was glibc? If so, what happened?

I think some systems do this? Ah, OK, here is one example. Do you know
of the C library called Musl? It's a Glibc alternative. Some distros
like Alpine Linux, are based on it.

https://www.musl-libc.org/faq.html

Why is libm.a empty?

On musl, the entire standard library is included in a single
library file — libc.a for static linking, and libc.so for
dynamic linking. This significantly improves the efficiency of
dynamic linking, and avoids all sorts of symbol interposition
bugs that arise when you split the libraries up — bugs which
have plagued glibc for more than a decade.

Why not just omit libm.a, libpthread.a, etc. entirely? POSIX says
-lm, -lpthread, etc. are valid options to the compiler and
conforming applications must use these options when they need the
corresponding functionality, and the easiest way to comply with that
requirement (and avoid breaking applications) is with empty .a files
by those names. What is ridiculous is that there are many funtions
in the main library, including ones which are very rare.

So they are doing exactly what I say; -lm is there so that your
compiler command line doesn't break, effectively as a backward
compatibility dongle, and it works via an actual empty library.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:

> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>> Hmm... With statically allocated strings, or using malloc and therefore
>>> requiring free call not shown?
>>>
>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>> macro:
>>>
>>> typedef float salary_t;
>>> #define FMT_SALARY "f"
>>>
>>> typedef unsigned long int payrollid_t;
>>> #define FMT_PAYROLLID "lu"
>>>
>>> so that one can write
>>>
>>> printf("Hello %s your salary is %" FMT_SALLARY
>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>> employee.name, employee.salary, employee.payrollid);
>>>
>>> -- Ben.
>>
>> Ben, if you put floating points in money accountants get upset.
>>
>> Three employees are paid $100.00, so it adds up to $300.
>>
>> Deduct $20 from each, and it's $240.
>>
>> Use floating point and sooner or later it won't add up.
>
> Use floating-point *naively* and the truncation errors will accumulate
> to the point of making at least a one cent difference, screwing up the
> accounting.
>
> Use floating-point intelligently and that won't happen.
>
>> You can't have a third of a cent.
>
> That is neither here nor there.
>
> You can't have a third of a cent in accounting, because accounting is
> decimal based, at least with US dollars and similar currencies,
> where you don't have beasties like sixths of a dollar.

Actually, many currencies (including the US Dollar) allow for measurements
in the thousandths of a dollar, and such calculations are common in both
stock brokerage pricing (a broker may charge, say, 5 mils per share on
bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
tax calculation.

> "Third of a cent" is a financial quantity nobody works with, in any
> representation of dollars.

Except for those who work with money as a commodity, stock brokers,
municipal property tax assessors, and a wide variety of others. Consider,
at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
How inconvenient would it be if programmers just took the position that
there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
therefore, purchases $0.00 USD?

> And even if they did, floating point
> could handle it just fine, if everyone agreed that around 15
> digits of precision is good enough.

For very small and very large sums of money, most banking systems
will stay /very/ far away from floatingpoint in any form. Better
to do (expensive) fixed-precision math and get exact answers than
to do (cheaper) floatingpoint math and get the final /financial/
answer wrong. That's how banks fail, and programmers get rich
from rounding errors (watch the movie "Office Space").

[snip]

--
Lew Pitcher
A retired programmer/analyst/architect for a large Canadian bank
"In Skills We Trust"

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>Bart <bc@freeuk.com> writes:
>>>>
>>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>>>> just a fact.
>>>>>
>>>>>2+2 = 4. That's just a fact.
>>>>
>>>> Indeed, and it is a fact for _any_ library containing optional functionality
>>>> that is needed by the application.
>>>
>>>That's only true in a circular way. Why are the math functions
>>>considered optional? Why not, for example, consider the IO functions
>>>optional so that any program that includes <stdio.h> has to link with
>>>-lio? (I know the history -- that's not what I'm asking.)
>>>
>>>There's even a division that could be justified by the standard. Any
>>>program that uses functions not required in a freestanding
>>>implementation could be obliged to link with -lhosted, but requiring -lm
>>>is just a historical barnacle.
>>
>> Yes, it's historical, and an artifact of small memory systems and
>> archive libraries.
>>
>> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
>> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
>> driver (cc)?
>
>This is entirely feasible, technologically.
>
>As a pretty simple hack, header files for these libraries could
>declare the "soname" that is required to call their functions.
>
>The compiler would attach that to the declarations made in those
>headers and then if any of those symbols are referenced, append
>the -l<soname> to the linker line.
>
>In the Microsoft Visual C/C++ world, a source file can indicate that it
>needs a particular DLL, so that it doesn't have to be specified on the
>command line.

Ah, yes. DLL hell. Something that has not yet been an issue for
unix/linux, and hopefully never will.

On 10/08/2023 17:49, Michael S wrote:
>> So you also disagree with Bart whose compiler has a built-in rule about
>> what file extension to assume. You probably won't bring that up, though.

> Compiler and generic build utility are not in the same boat.
> It is less surprising to have defaults in compiler than to have built-in
> implicit rules in generic build utility.
> But yes, I don't like Bart's decision to allow omission of .c.

It's possible the *nix people are downplaying the advantage of having
default extensions, because of those systems it is not practical.

That is because 'prog' and 'prog.' are distinct filenames.

On Windows:

prog means apply a default extension
prog. means use 'prog' with no extension
prog.ext means use the given extension

Under *nix:

prog means the literal file "prog"
prog. means the literal file "prog."
prog.ext means use the given extension

There is no way to indicate a default extension, without losing the
ability to denote a literal filename "prog".

But whether that's the real problem is doubtful; for a C compiler, it
would be unusual to use an extension for source files that is anything
but .c, or one that might clash with an executable file.

> However as long as his compiler is his personal toy I am not going to
complain.

Sure; over about 15 years I sold about $10m of software developed with
my toy compilers. I'm not going to complain either!

On Thursday, August 10, 2023 at 7:59:25 PM UTC+3, Scott Lurndal wrote:
> Kaz Kylheku <864-11...@kylheku.com> writes:
> >On 2023-08-10, Scott Lurndal <sc...@slp53.sl.home> wrote:
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >>>sc...@slp53.sl.home (Scott Lurndal) writes:
> >>>
> >>>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >>>>>Bart <b...@freeuk.com> writes:
> >>>>
> >>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
> >>>>>> just a fact.
> >>>>>
> >>>>>2+2 = 4. That's just a fact.
> >>>>
> >>>> Indeed, and it is a fact for _any_ library containing optional functionality
> >>>> that is needed by the application.
> >>>
> >>>That's only true in a circular way. Why are the math functions
> >>>considered optional? Why not, for example, consider the IO functions
> >>>optional so that any program that includes <stdio.h> has to link with
> >>>-lio? (I know the history -- that's not what I'm asking.)
> >>>
> >>>There's even a division that could be justified by the standard. Any
> >>>program that uses functions not required in a freestanding
> >>>implementation could be obliged to link with -lhosted, but requiring -lm
> >>>is just a historical barnacle.
> >>
> >> Yes, it's historical, and an artifact of small memory systems and
> >> archive libraries.
> >>
> >> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> >> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> >> driver (cc)?
> >
> >This is entirely feasible, technologically.
> >
> >As a pretty simple hack, header files for these libraries could
> >declare the "soname" that is required to call their functions.
> >
> >The compiler would attach that to the declarations made in those
> >headers and then if any of those symbols are referenced, append
> >the -l<soname> to the linker line.
> >
> >In the Microsoft Visual C/C++ world, a source file can indicate that it
> >needs a particular DLL, so that it doesn't have to be specified on the
> >command line.
> Ah, yes. DLL hell. Something that has not yet been an issue for
> unix/linux, and hopefully never will.

In my personal experience DLL hell on Linux is innumerably worse
than it ever was on Windows.
On Windows, at worst one can put needed versions of DLLs in the
same directory with exe and things will work.
On Linux, I found no ways short of static link to cause binaries compiled
on newer Debian to run on LTS variant of Ubuntu. And that's with Debian
and Ununtu, two distros that are rather close relatives. I wonder what is
going to happen if try unrelated distros.