On 7/17/2023 3:01 PM, fir wrote:
> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>> C is a high level language.
>
> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level

I tend to agree with that.

[...]

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 17 July 2023 at 16:15:27 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >>
>> >> > On 16/07/2023 20:55, Ben Bacarisse wrote:
>> >> >> David Brown <david...@hesbynett.no> writes:
>> >> >
>> >> >>> Getting it /right/ is very simple. Two examples are :
>> >> >>>
>> >> >>> inline bool sign_bit(float f) {
>> >> >>> uint32_t u;
>> >> >>> memcpy(&u, &f, 4);
>> >> >>> return u & 0x80000000;
>> >> >>> }
>> >> >>>
>> >> >>> and
>> >> >>>
>> >> >>> inline bool sign_bit(float f) {
>> >> >>> union {
>> >> >>> uint32_t u;
>> >> >>> float f;
>> >> >>> } u;
>> >> >>> u.f = f;
>> >> >>> return u.u & 0x80000000;
>> >> >>> }
>> >> >>
>> >> >> Very a tangent, but I like the fact that compound literals and
>> >> >> designated initialisers let one write
>> >> >>
>> >> >> return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;
>> >> >
>> >> > I'm struggling to see the appeal of being able to do this!
>> >> It's not clear to what your "this" refers: the contraction into one
>> >> expression, the use of a union or something else?
>> >> > Also, consider that the function result is a bool, which means probably
>> >> > having to turn 0 or 0x80000000 into 0 or 1.
>> >> You can use
>> >>
>> >> return (union { uint32_t u; float f; }){ .f = f }.u >> 31;
>> >>
>> >> if you prefer. I kept the & 0x80000000 to minimise the changes. By
>> >> putting the float first, I could also have eliminated the designated
>> >> initialiser:
>> >>
>> >> return (union { float _; uint32_t u; }){ f }.u >> 31;
>> >> > A lot of things going on just to access bit 31 of the parameter. Why the
>> >> > need to go around the houses so much?
>> >> Because C has not way to get at bit 31 of a float. Anyway, I don't
>> >> think there are really many houses being gone round here.
>> >> > Sticking to C, however, I would just do:
>> >> >
>> >> > (*(u32*)&f) & 0x80000000 # get 0x00000000 or 0x80000000
>> >>
>> >> Why? It seems odd to prefer an expression with no defined meaning.
>> >>
>> > It's got two main advantages. You don't need to create a union, which
>> > is a bit messy (if you've several similar functions, do you create the
>> > same union everywhere in local scope, as you did, or do you create one
>> > in global scope - neither answer is ideal).
>> This is not very clear. Do you object to the declaration of an object
>> with a union type (as in DB's code) or the use of an anonymous object of
>> union type in my code? Your reference to local and global scope
>> suggests that you might be objecting to the former. Do you object to
>> the anonymous object as well?
>>
> You created an anonymous union, which of course had local scope.

Scope is a property of names. Neither the union type nor the temporary
object had a name.

Anyway, you did in fact object to the use of a temporary object of union
type. OK. I can't see why, but I know now that it was not only the
named declared object in DB's code you objected to.

> One
> drawback to that is that if we have several functions all accessing the bits
> of a float, then we'll want the unions to be declared in the same way, so that
> they match.

You have a habit of suggesting universal agreement (or at least
widely-held agreement) on tendentious matters by using "we". I don't
know what sort of matching you are referring to but it does not sound
like something I would care about.

> But you can't enforce that. People might use different identifiers
> to "u" and "f" for the members, for example.

Since the purpose of the other functions would be to reinterpret the
bits of different types I'd hope they would. Would you want f for a
complex number and u for and array of char?

I suppose they could be called "in" and "out" or "from" and "to", but a
failure to enforce that is preferable to using an undefined construct.

>> Anyway, I can only answer your question for my suggestion -- if I had a
>> number of these functions I'd use anonymous objects of just the right
>> union type for each function, just as you would, presumably, prefer to
>> use undefined cast expressions of the just the right type for each
>> function.
>>
> The undefined cast expressions are less likely to fail to match, though of
> course it's possible because there are several type aliases.

What is the matching that you want so very much that you will favour
using an undefined construct in order to get it?

>> > And the C is likely a very
>> > close match for the assembler.
>>
>> That's an odd way of putting it. The C you prefer is undefined, so you
>> are making some big assumptions about what the assembler is likely to
>> be! But, even so, why is this matching an advantage? And why do you
>> think my version does not result in a similar "close match"?
>>
> In assember we will certainly have a way of saying "take the memory at
> location f and interpret it as a 32 bit integer". It's less clear how
> we should write access to another member of a union in assembler.

Why don't you have a look at the generated assembler? When I did, the
assembler matched my expectations exactly. Since not knowing what the
legal C code should compile to is holding you back from using it, why
not fix that knowledge gap? Then one of the reasons you have for using
the undefined construct will go away.

>> I can't see anything that would make me prefer an undefined construct.
>>
> Writing to one member of a union and reading another is also undefined
> behaviour,

Well, this is an impasse. The academic in my wants to say "citation
please". The teacher in me wants to say no, see the C standard.

(Some uses of unions to re-interpret bits can be undefined since the
result can be a "non-value" as they are now called in C23, but not this
one.)

> though that rule is more honoured in the breach than the observance.
>>
>> > If you've got to use bitwise operations
>> > instead of comparing to zero with a relational operator to get the
>> > sign, then it's quite likely you'll end up going to assembly at some
>> > point.
>>
>> What are you thinking about here? If you have a more realistic example,
>> that might be worth discussing.
>>
> Here's a real bit of code
> double addwave(double a, double b) {
> if (std::signbit(a) == std::signbit(b)) {
> if (std::signbit(a) == 0)
> return a + b - a * b;
> else
> return a + b + a * b;
> }
> else
> return a + b;
> }
>
> This is very likely to be a rate limiting step, because it's got to be
> called for every sample of a wave. So it's the sort of thing which
> might be a candidate for assembly. If we're going to do that, it can
> help to write out the C so that each line of C corresponds to one
> assembly instruction.

I thought you had an example in mind that would back up your preference
for an undefined construct, but now it seems you think the union method
is undefined too!

> > > This doesn't mean incidentally that casting a pointer is the way Malcolm
>> > would do it, as some people seem to think. Just that there might be reasons
>> > for choosing that option.
>> Has the article quoting been messed up or are you referring to yourself
>> in the third person?
>>
> I'm quoting DB.

Quotes should look like quotes. If it's quoted from a post up-thread it
should have the right number of ">" marks (and an attribution line). If
it's not, you should make it clear using quotation marks and a note
about who said it.

wtorek, 18 lipca 2023 o 00:01:31 UTC+2 fir napisał(a):
> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> > C is a high level language.
>
> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)

besides it seem to me (yawn) that some people belives c is defined by the standard..its obvoisly false

(c is defined by some spirit/rules you may even name it ideology) and c standard is just around of it

On 17/07/2023 23:06, fir wrote:
> wtorek, 18 lipca 2023 o 00:01:31 UTC+2 fir napisał(a):
>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>> C is a high level language.
>>
>> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)
>
> besides it seem to me (yawn) that some people belives c is defined by the standard..its obvoisly false
>
> (c is defined by some spirit/rules you may even name it ideology) and c standard is just around of it

Half of it seems to be defined by the set of options you give to
compilers like gcc and Clang.

With one set of options, your program passes. But choose another set,
and it fails, or you have loads of warnings, or the behaviour is subtly
different.

So much for being portable.

Bart <bc@freeuk.com> writes:
[...]
> Half of it seems to be defined by the set of options you give to
> compilers like gcc and Clang.
>
> With one set of options, your program passes. But choose another set,
> and it fails, or you have loads of warnings, or the behaviour is
> subtly different.
>
> So much for being portable.

gcc and clang have options that cause them to (attempt to) be
conforming C compilers, something like "-std=cNN -pedantic", where
NN is the edition of the standard you want to conform to.

Without those options, gcc and clang are both non-conforming, and
of course any program that depends on compiler-specific extensions
is not portable.

You know all that. You just pretend not to so you can make some point
about how much you dislike C. *yawn*

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 17/07/2023 23:30, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Half of it seems to be defined by the set of options you give to
>> compilers like gcc and Clang.
>>
>> With one set of options, your program passes. But choose another set,
>> and it fails, or you have loads of warnings, or the behaviour is
>> subtly different.
>>
>> So much for being portable.
>
> gcc and clang have options that cause them to (attempt to) be
> conforming C compilers, something like "-std=cNN -pedantic", where
> NN is the edition of the standard you want to conform to.
>
> Without those options, gcc and clang are both non-conforming, and
> of course any program that depends on compiler-specific extensions
> is not portable.

I genuinely don't understand your points.

To usefully use C, you need to compile a program in it, and the compiler
needs to be told some things about how to that, how strict it should be etc.

This means the same source file could do different things depending how
it is compiled: pass or fail, do X or Y, use this or that -D macro. You
don't even need to make use of extensions.

Actually this is not /my/ point, but one made by Walter Bright in this
video:

https://www.youtube.com/watch?v=y7KWGv_t-MU

From 5:30.

This is a problem for me. In 2014 I posted a link to an 18Kloc program.
Compiled with gcc, it worked fine. But then some people here ramped up
the warning options, so that it spewed 1000s of warnings.

Was there anything wrong my program or not?

Apparently if /I/ stipulate the exact set of gcc options (ie. none),
then it's legal C; a perfectly valid program.

But other people prefer a stricter version of C, and to satisfy them,
many things would need changing.

This is why I said that a program, ostensibly in C, is really in a
language partly defined by the choice of compile options.

wtorek, 18 lipca 2023 o 00:11:59 UTC+2 Bart napisał(a):
> On 17/07/2023 23:06, fir wrote:
> > wtorek, 18 lipca 2023 o 00:01:31 UTC+2 fir napisał(a):
> >> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> >>> C is a high level language.
> >>
> >> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)
> >
> > besides it seem to me (yawn) that some people belives c is defined by the standard..its obvoisly false
> >
> > (c is defined by some spirit/rules you may even name it ideology) and c standard is just around of it
> Half of it seems to be defined by the set of options you give to
> compilers like gcc and Clang.
>
> With one set of options, your program passes. But choose another set,
> and it fails, or you have loads of warnings, or the behaviour is subtly
> different.
>
> So much for being portable.

i probably woildnt agree with that but i never thinked on this... as to being 'inderdefined' i also
never thinked on that so i got no opinion.. i femember hovever for example (if im not wrong)
thut such thing is not defined

foo(a(),b(),c());

i mean which order of a b c calling is and it seems kinda problem -as probably c-spirit not defines this
(though maybe? from left to right? though its not clear but if there is some reason it shouldnt be it shouldnt be)
and is standard not defines it in fact it may be a hole in language

wtorek, 18 lipca 2023 o 01:10:34 UTC+2 fir napisał(a):
> 'inderdefined'
underdefined

wtorek, 18 lipca 2023 o 01:10:34 UTC+2 fir napisał(a):
> wtorek, 18 lipca 2023 o 00:11:59 UTC+2 Bart napisał(a):
> > On 17/07/2023 23:06, fir wrote:
> > > wtorek, 18 lipca 2023 o 00:01:31 UTC+2 fir napisał(a):
> > >> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> > >>> C is a high level language.
> > >>
> > >> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)
> > >
> > > besides it seem to me (yawn) that some people belives c is defined by the standard..its obvoisly false
> > >
> > > (c is defined by some spirit/rules you may even name it ideology) and c standard is just around of it
> > Half of it seems to be defined by the set of options you give to
> > compilers like gcc and Clang.
> >
> > With one set of options, your program passes. But choose another set,
> > and it fails, or you have loads of warnings, or the behaviour is subtly
> > different.
> >
> > So much for being portable.
> i probably woildnt agree with that but i never thinked on this... as to being 'inderdefined' i also
> never thinked on that so i got no opinion.. i femember hovever for example (if im not wrong)
> thut such thing is not defined
>
> foo(a(),b(),c());
>
> i mean which order of a b c calling is and it seems kinda problem -as probably c-spirit not defines this
> (though maybe? from left to right? though its not clear but if there is some reason it shouldnt be it shouldnt be)
> and is standard not defines it in fact it may be a hole in language

if someone know such holes in c language may mention them and some my discuss how they should be closed

wtorek, 18 lipca 2023 o 01:10:34 UTC+2 fir napisał(a):
> wtorek, 18 lipca 2023 o 00:11:59 UTC+2 Bart napisał(a):
> > On 17/07/2023 23:06, fir wrote:
> > > wtorek, 18 lipca 2023 o 00:01:31 UTC+2 fir napisał(a):
> > >> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> > >>> C is a high level language.
> > >>
> > >> i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)
> > >
> > > besides it seem to me (yawn) that some people belives c is defined by the standard..its obvoisly false
> > >
> > > (c is defined by some spirit/rules you may even name it ideology) and c standard is just around of it
> > Half of it seems to be defined by the set of options you give to
> > compilers like gcc and Clang.
> >
> > With one set of options, your program passes. But choose another set,
> > and it fails, or you have loads of warnings, or the behaviour is subtly
> > different.
> >
> > So much for being portable.
> i probably woildnt agree with that but i never thinked on this... as to being 'uderdefined' i also

i mean if c has a numerous holes and compile options decide how to treat them (if one way or another)
i could agree what you say - its kinda point... but i wouldnt agre to seriously say that.. especially i personally not fall in that holes in pratice (or if i fell in some i didnt even noticed and thats okay for me) ..if i would port code and fall into few such holes i would just repair this as bugs and thats all, treating this as normal bugs - those are not mystical problems and in practice imo those are far far less important that normal bugs (probably)

On 2023-07-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Half of it seems to be defined by the set of options you give to
>> compilers like gcc and Clang.
>>
>> With one set of options, your program passes. But choose another set,
>> and it fails, or you have loads of warnings, or the behaviour is
>> subtly different.
>>
>> So much for being portable.
>
> gcc and clang have options that cause them to (attempt to) be
> conforming C compilers, something like "-std=cNN -pedantic", where
> NN is the edition of the standard you want to conform to.
>
> Without those options, gcc and clang are both non-conforming, and
> of course any program that depends on compiler-specific extensions
> is not portable.
>
> You know all that. You just pretend not to so you can make some point
> about how much you dislike C. *yawn*

Each compiler option that affects semantics splits the implementation's
language into two dialects (if the option is Boolean; more if it has
multiple values).

There is a language standard, but in actual practice, the C world cannot
agree on a single C language that everyone can like. One project wants
wrapping integer arithmetic. Another project deosn't care for that, but
want to defeat strict aliasing optimizations. Yet another wants char to
be unsigned.

The standard ignores the fact that there exist compiler options and
those options influence the language dialect, but which sit squarely
outside of the language syntax, and so don't appear in the translation
unit

Everything that changes language semantics should be in the language
syntax, and standardized.

The translation unit itself should be able to declare that it
wants wrapping arithmetic, and over which parts of the code.

A standard C in which you have standard-defined optimization controls
and code generation options in important areas would be a huge
improvement.

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

I don't know if anyone comes across comp.lang.c when trying to learn C
anymore, but if they do, a word of warning: Bart's purpose here is
always to obfuscate and confuse; he almost never explains or clarifies.
He want's everyone to find C as mysterious as me (pretends?) he does.

For example

Bart <bc@freeuk.com> writes:

> This is why I said that a program, ostensibly in C, is really in a language
> partly defined by the choice of compile options.

This is true of almost every programming language I have ever used.
Fortran is defined by ISO standards, but you can write programs that
look very much like ISO Fortran but which are really written in a
language only accepted by some compiler invoked with certain options.
It has always been this way, particularly for large, serious languages
with long histories.

The C programming language is defined by a series of ISO standards and,
before that, by the book written by Kernighan and Ritchie. Most old
C programs are not valid ISO C programs and the same is true (to a
lesser extent) with the various revisions of the standard.

Also, most C compilers accept programs written in languages that are not
entirely unlike C, but aren't quite. As I said, this is not peculiar to
C. What is possibly peculiar to C (I've not studied the matter) is that
C compilers often don't default to accepting the most recent standard
version of the language. Compilers often cater to a community used to
some non-standard variation, and it's that language that is accepted by
default.

So, in the spirit of being helpful, if you are learning C, you should
(a) get a good book; (b) use a good compiler (setting it's options to
the version of the language standard your book describes); and (c) crank
up the warning level so the compiler gives you as much help as possible.

For example, when someone posts here, I will compile it with something
like this

gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
-fsanitize=undefined -Wbad-function-cast \
-Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
-Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store

so I can see problems as early as possible.

--
Ben.

Bart <bc@freeuk.com> writes:
> On 17/07/2023 23:30, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Half of it seems to be defined by the set of options you give to
>>> compilers like gcc and Clang.
>>>
>>> With one set of options, your program passes. But choose another set,
>>> and it fails, or you have loads of warnings, or the behaviour is
>>> subtly different.
>>>
>>> So much for being portable.
>>
>> gcc and clang have options that cause them to (attempt to) be
>> conforming C compilers, something like "-std=cNN -pedantic", where
>> NN is the edition of the standard you want to conform to.
>>
>> Without those options, gcc and clang are both non-conforming, and
>> of course any program that depends on compiler-specific extensions
>> is not portable.
>
> I genuinely don't understand your points.

I lack the patience to explain them to you again.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 18/07/2023 01:28, Ben Bacarisse wrote:
> I don't know if anyone comes across comp.lang.c when trying to learn C
> anymore, but if they do, a word of warning: Bart's purpose here is
> always to obfuscate and confuse; he almost never explains or clarifies.
> He want's everyone to find C as mysterious as me (pretends?) he does.
>
> For example
>
> Bart <bc@freeuk.com> writes:
>
>> This is why I said that a program, ostensibly in C, is really in a
language
>> partly defined by the choice of compile options.
>
> This is true of almost every programming language I have ever used.
> Fortran is defined by ISO standards, but you can write programs that
> look very much like ISO Fortran but which are really written in a
> language only accepted by some compiler invoked with certain options.
> It has always been this way, particularly for large, serious languages
> with long histories.

OK. But in that case why is C's so-called portability touted so much?

(In the case of Fortran, I remember using machine-specific types such as
INTEGER*4 (i32) in 1979; was there anything similar in C before C99?

Funny that the non-low-level language had machine types, and
close-to-the-metal C didn't!

Fortran anyway doesn't mind embracing change; the language has evolved
considerably since then.)

> For example, when someone posts here, I will compile it with something
> like this
>
> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
> -fsanitize=undefined -Wbad-function-cast \
> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>
> so I can see problems as early as possible.

So you're using a version of the language defined by those options.

BTW I can't remember using any options when compiling Fortran. Maybe it
was too long ago, but would have remembered having to type in that lot!

On 2023-07-18, Bart <bc@freeuk.com> wrote:
> OK. But in that case why is C's so-called portability touted so much?

Because a lot of people have success in writing something on one system
and using it on two others.

It used to be those three were actually different architectures,
and the compilers were from different vendors.

Today it's "wow, portable" if two of them are 64 bit x86 and one is ARM,
with just operating systems being different (e.g Windows, MacOS, Linux)
and the compilers being GCC and/or Clang.

This low portability bar is allowing other camps to proclaim that their shit
portable (e.g. Rust, which has no abstract integer types: only int16,
int32, int64 ...: all the world's a VAX^H^H^SPARC^H^H^HX86^H^H^HARM!)

We could make a graph something like this:

No of programmers
▲
│ ┌────┐
│ │ │
│ │ │
│ │ │
│ │ │
/ / /
: : :
/ / /
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │ ┌────┐
│ │ │ │ │ ┌────┐
│ │ │ │ │ │ │ ┌────┐
│ └────┘ └────┘ └────┘ └────┘ ───── ───── ───── ─────
└───────────────────────────────────────────────────────────────────────►
0 1 2 3 4 5 6 7 8 or more
Max no of platforms ported any software to.

(There should be a 0 bar for those who never got their stuff properly
ported to the one and only platform they targeted.)

The 2, 3 and 4 crowd proclaim that they are portable programmers, and they
vastly outnumber 5+.

Bart <bc@freeuk.com> writes:

> On 18/07/2023 01:28, Ben Bacarisse wrote:
>> I don't know if anyone comes across comp.lang.c when trying to learn C
>> anymore, but if they do, a word of warning: Bart's purpose here is
>> always to obfuscate and confuse; he almost never explains or clarifies.
>> He want's everyone to find C as mysterious as me (pretends?) he does.
>>
>> For example
>>
>> Bart <bc@freeuk.com> writes:
>>
>>> This is why I said that a program, ostensibly in C, is really in a
> language
>>> partly defined by the choice of compile options.
>>
>> This is true of almost every programming language I have ever used.
>> Fortran is defined by ISO standards, but you can write programs that
>> look very much like ISO Fortran but which are really written in a
>> language only accepted by some compiler invoked with certain options.
>> It has always been this way, particularly for large, serious languages
>> with long histories.
>
> OK. But in that case why is C's so-called portability touted so much?

Who touts it? Picking an old version of C, and sticking to the standard
can result in reasonably portable programs, but the whole notion is
fraught with misunderstandings and is not easy to define. C is often
thought of as being very portable because almost every platform has a C
compiler, but writing highly portable is very hard and few people know
how to do it well. Does that mean that C is portable or does it mean it
isn't? The question is not an easy one to answer.

> (In the case of Fortran, I remember using machine-specific types such as
> INTEGER*4 (i32) in 1979; was there anything similar in C before C99?

For a while in the 1970s and into the 80s I would have said that FORTRAN
66 was probably the most "portable" language around. It was widely
implemented and had a strict language standard.

> Funny that the non-low-level language had machine types, and
> close-to-the-metal C didn't!

INTEGER*4 is not a machine type on the 6502 but C's int can be
efficiently implemented on small systems. You have invented a fiction
about what C "should be" in order to criticise it, while using a similar
fiction about Fortran to big up that language.

> Fortran anyway doesn't mind embracing change; the language has evolved
> considerably since then.)

C has changed quite a bit too but I'm not sure what part of your myth
that C is defined by compiler options is backed up by Fortran having
changed a lot (and C less).

>> For example, when someone posts here, I will compile it with something
>> like this
>>
>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>> -fsanitize=undefined -Wbad-function-cast \
>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>
>> so I can see problems as early as possible.
>
> So you're using a version of the language defined by those options.

That's what every compiler ever written does: process a language defined
by the author(s), the options used and the bugs in the implementation.
I really don't know what you hope to gain by saying obvious things like
this other than to (incorrectly) imply that C -- the language -- is not
defined by it's defining documents -- the ISO standards -- but by
compiler options.

Fortunately, gcc is a quality compiler and these options make the
language it accepts as close to ISO standard C (the 2011 version) as I
can get it, but there will always be bugs and misunderstandings.

> BTW I can't remember using any options when compiling Fortran.

Really? Odd. I remember needing multiple JCL cards to invoke the IBM
360 FORTRAN compiler, but you didn't get much choice about the language.
It implemented IBM's interpretation of FORTRAN IV and you were stuck
with it, though you could choose to write in a more portable subset.

> Maybe it was
> too long ago, but would have remembered having to type in that lot!

Fortunately every OS I've used provides mechanisms to avoid having to
type commands like this. I suspect every OS you'd used does as well,
but you can't help reaching for a sound bite.

--
Ben.

Bart <bc@freeuk.com> writes:
[...]
> (In the case of Fortran, I remember using machine-specific types such
> as INTEGER*4 (i32) in 1979; was there anything similar in C before
> C99?
>
> Funny that the non-low-level language had machine types, and
> close-to-the-metal C didn't!

So your complaint is that C has fixed-width types *now*, but didn't
acquire them until 24 years ago? It's difficult to imagine any
explanation that would satisfy you.

And you're referring to the intN_t types as "machine types"?
Why do you call them that?

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 18/07/2023 00:01, Chris M. Thomasson wrote:
> On 7/17/2023 3:01 PM, fir wrote:
>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>   C is a  high level language.
>>
>> i propose to say c is mid-level language.. i would say its closer to
>> low-lewel than high-level
>
> I tend to agree with that.
>

I don't know if there is any kind of "official" definition of a
high-level language. But I think a reasonable choice would be to say
that a low-level language is one that is defined in terms of the
hardware. Operations in the language do what the hardware says they
will do. A high-level language is one that is defined independently of
any particular hardware.

By that definition, C is a high-level language - it is defined in terms
of an abstract machine. It has some implementation-dependent factors
(as do all languages - though C has perhaps more than most, and is more
explicit about it than most). But those affect particular
implementations of the language rather than the language itself.

Another way to distinguish low and high level languages is to consider
the usage, and suitability of usage, in "low level" or "systems" coding,
close to the hardware, as distinct from more abstract coding. Python is
then "high level", with native support for infinite precision integers,
hash maps, standard libraries for application-level features, etc. C is
"low level" for supporting efficient and direct hardware access and
systems coding. But C++ would then be both a low-level /and/ a
high-level language.

I personally think it is more accurate to say that C is a low-level
high-level language, or a high-level language targeting low-level
programming. A binary low/high classification is not particularly
useful - it is perhaps better to think of a scale, in which a language
like Python would be significantly higher than C. But as C would score
well above 0 here, it is very definitely a high level language.

On 7/18/2023 12:26 AM, David Brown wrote:
> On 18/07/2023 00:01, Chris M. Thomasson wrote:
>> On 7/17/2023 3:01 PM, fir wrote:
>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>>   C is a  high level language.
>>>
>>> i propose to say c is mid-level language.. i would say its closer to
>>> low-lewel than high-level
>>
>> I tend to agree with that.
>>
>
> I don't know if there is any kind of "official" definition of a
> high-level language.  But I think a reasonable choice would be to say
> that a low-level language is one that is defined in terms of the
> hardware.  Operations in the language do what the hardware says they
> will do.  A high-level language is one that is defined independently of
> any particular hardware.
>
> By that definition, C is a high-level language - it is defined in terms
> of an abstract machine.  It has some implementation-dependent factors
> (as do all languages - though C has perhaps more than most, and is more
> explicit about it than most).  But those affect particular
> implementations of the language rather than the language itself.
>
> Another way to distinguish low and high level languages is to consider
> the usage, and suitability of usage, in "low level" or "systems" coding,
> close to the hardware, as distinct from more abstract coding.  Python is
> then "high level", with native support for infinite precision integers,
> hash maps, standard libraries for application-level features, etc.  C is
> "low level" for supporting efficient and direct hardware access and
> systems coding.  But C++ would then be both a low-level /and/ a
> high-level language.
>
> I personally think it is more accurate to say that C is a low-level
> high-level language, or a high-level language targeting low-level
> programming.  A binary low/high classification is not particularly
> useful - it is perhaps better to think of a scale, in which a language
> like Python would be significantly higher than C.  But as C would score
> well above 0 here, it is very definitely a high level language.

Well, I can use C to steal bits from a pointer. Pretty nice and useful,
from time to time, so to speak... :^)

On 7/18/2023 12:33 AM, Chris M. Thomasson wrote:
> On 7/18/2023 12:26 AM, David Brown wrote:
>> On 18/07/2023 00:01, Chris M. Thomasson wrote:
>>> On 7/17/2023 3:01 PM, fir wrote:
>>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>>>   C is a  high level language.
>>>>
>>>> i propose to say c is mid-level language.. i would say its closer to
>>>> low-lewel than high-level
>>>
>>> I tend to agree with that.
>>>
>>
>> I don't know if there is any kind of "official" definition of a
>> high-level language.  But I think a reasonable choice would be to say
>> that a low-level language is one that is defined in terms of the
>> hardware.  Operations in the language do what the hardware says they
>> will do.  A high-level language is one that is defined independently
>> of any particular hardware.
>>
>> By that definition, C is a high-level language - it is defined in
>> terms of an abstract machine.  It has some implementation-dependent
>> factors (as do all languages - though C has perhaps more than most,
>> and is more explicit about it than most).  But those affect particular
>> implementations of the language rather than the language itself.
>>
>> Another way to distinguish low and high level languages is to consider
>> the usage, and suitability of usage, in "low level" or "systems"
>> coding, close to the hardware, as distinct from more abstract coding.
>> Python is then "high level", with native support for infinite
>> precision integers, hash maps, standard libraries for
>> application-level features, etc.  C is "low level" for supporting
>> efficient and direct hardware access and systems coding.  But C++
>> would then be both a low-level /and/ a high-level language.
>>
>> I personally think it is more accurate to say that C is a low-level
>> high-level language, or a high-level language targeting low-level
>> programming.  A binary low/high classification is not particularly
>> useful - it is perhaps better to think of a scale, in which a language
>> like Python would be significantly higher than C.  But as C would
>> score well above 0 here, it is very definitely a high level language.
>
> Well, I can use C to steal bits from a pointer. Pretty nice and useful,
> from time to time, so to speak... :^)
>

Fun times! Storing meta data in a pointer, then masking it off before we
actually use the pointer. Undefined behavior for sure, but can it work
and be used in highly beneficial ways, yup.

On 7/18/2023 12:35 AM, Chris M. Thomasson wrote:
> On 7/18/2023 12:33 AM, Chris M. Thomasson wrote:
>> On 7/18/2023 12:26 AM, David Brown wrote:
>>> On 18/07/2023 00:01, Chris M. Thomasson wrote:
>>>> On 7/17/2023 3:01 PM, fir wrote:
>>>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>>>>   C is a  high level language.
>>>>>
>>>>> i propose to say c is mid-level language.. i would say its closer
>>>>> to low-lewel than high-level
>>>>
>>>> I tend to agree with that.
>>>>
>>>
>>> I don't know if there is any kind of "official" definition of a
>>> high-level language.  But I think a reasonable choice would be to say
>>> that a low-level language is one that is defined in terms of the
>>> hardware.  Operations in the language do what the hardware says they
>>> will do.  A high-level language is one that is defined independently
>>> of any particular hardware.
>>>
>>> By that definition, C is a high-level language - it is defined in
>>> terms of an abstract machine.  It has some implementation-dependent
>>> factors (as do all languages - though C has perhaps more than most,
>>> and is more explicit about it than most).  But those affect
>>> particular implementations of the language rather than the language
>>> itself.
>>>
>>> Another way to distinguish low and high level languages is to
>>> consider the usage, and suitability of usage, in "low level" or
>>> "systems" coding, close to the hardware, as distinct from more
>>> abstract coding. Python is then "high level", with native support for
>>> infinite precision integers, hash maps, standard libraries for
>>> application-level features, etc.  C is "low level" for supporting
>>> efficient and direct hardware access and systems coding.  But C++
>>> would then be both a low-level /and/ a high-level language.
>>>
>>> I personally think it is more accurate to say that C is a low-level
>>> high-level language, or a high-level language targeting low-level
>>> programming.  A binary low/high classification is not particularly
>>> useful - it is perhaps better to think of a scale, in which a
>>> language like Python would be significantly higher than C.  But as C
>>> would score well above 0 here, it is very definitely a high level
>>> language.
>>
>> Well, I can use C to steal bits from a pointer. Pretty nice and
>> useful, from time to time, so to speak... :^)
>>
>
> Fun times! Storing meta data in a pointer, then masking it off before we
> actually use the pointer. Undefined behavior for sure, but can it work
> and be used in highly beneficial ways, yup.

Actually, they can be used in VERY good ways, pointer tricks. Big time.
One time, I thought of the following song when I first started using the
non-portable trick.

https://youtu.be/s09LuDYX12g

:^)

On 18/07/2023 04:25, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>>> I don't know if anyone comes across comp.lang.c when trying to learn C
>>> anymore, but if they do, a word of warning: Bart's purpose here is
>>> always to obfuscate and confuse; he almost never explains or clarifies.
>>> He want's everyone to find C as mysterious as me (pretends?) he does.
>>>
>>> For example
>>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> This is why I said that a program, ostensibly in C, is really in a
>> language
>>>> partly defined by the choice of compile options.
>>>
>>> This is true of almost every programming language I have ever used.
>>> Fortran is defined by ISO standards, but you can write programs that
>>> look very much like ISO Fortran but which are really written in a
>>> language only accepted by some compiler invoked with certain options.
>>> It has always been this way, particularly for large, serious languages
>>> with long histories.
>>
>> OK. But in that case why is C's so-called portability touted so much?
>
> Who touts it? Picking an old version of C, and sticking to the standard
> can result in reasonably portable programs, but the whole notion is
> fraught with misunderstandings and is not easy to define. C is often
> thought of as being very portable because almost every platform has a C
> compiler, but writing highly portable is very hard and few people know
> how to do it well. Does that mean that C is portable or does it mean it
> isn't? The question is not an easy one to answer.
>

It is more accurate, I think, to say that C /supports/ portable
programming, rather than saying that C is a portable language.

The language was designed for two main uses. One was /portable/
application-level programming. The other was /non-portable/
systems-level programming - alleviating developers from having to use
assembly.

It's use has spread far beyond its original designers' imaginations, and
even with those two categories, there is no hard boundary between them.

Typically, programs will consist of a lot of portable code (even if it
was not actually written with portability in mind), and some
non-portable parts. Some projects actively divide code like that with a
view to ease of reuse on different targets, others mix freely. Some
bits of code are written intentionally as very portable, others make
assumptions that limit portability. I think it is fair to say that you
can write a great deal of C /code/ in a portable (or fairly portable)
manner without extra effort or run-time overhead - but you can write few
complete C /programs/ in a highly portable fashion without extra work.

>
>>> For example, when someone posts here, I will compile it with something
>>> like this
>>>
>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>> -fsanitize=undefined -Wbad-function-cast \
>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>
>>> so I can see problems as early as possible.
>>
>> So you're using a version of the language defined by those options.

Note (this is primarily for Bart - it's nothing new to Ben) that none of
these flags define the language - they merely ask for warnings on
suspicious code. "-std=c11" /chooses/ which language standard to use,
but does not define it.

gcc does offer options that change the language - you can choose to
support gcc extensions, and you can add additional semantics to C with
options such as "-fwrapv" and "-fno-strict-aliasing". But those are not
in Ben's list.

>
> That's what every compiler ever written does: process a language defined
> by the author(s), the options used and the bugs in the implementation.
> I really don't know what you hope to gain by saying obvious things like
> this other than to (incorrectly) imply that C -- the language -- is not
> defined by it's defining documents -- the ISO standards -- but by
> compiler options.
>

One thing to remember is Bart's comparison here. He is forever
comparing C to his own language - a language that is, in a sense,
constant because there is only one implementation of it. There are no
flags that affect the language, because what might be an optional
feature in another compiler, is for him a fixed change to the language
implemented by changing the compiler source. With only one user, and
only one compiler, there are no options or variations. It is fully
portable - all programs in his language can be compiled by all
implementations. There are no conflicts between language definition
documents and implementations, because there are no documents defining
the language - the language is whatever the implementation does. There
is no scope for alternative interpretation of the definition - with one
user, there is always consensus. There are no flaws in the language -
it works exactly as its users want it to.

Because Bart has primarily used his own language (or languages) for many
decades, he struggles to understand how things work for a language that
has developed over decades, has formal standards, has countless
implementations, countless users, and an enormous quantity of code
written to wildly varying qualities.

On 7/17/2023 1:26 PM, Kalevi Kolttonen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Do you have PIL installed?
>
> [root@hostname ~]# rpm -qa|grep -i python|grep -i pil
> python3-pillow-9.4.0-2.fc38.x86_64
>
> The result of googling:
>
> "What is PIL/Pillow? PIL (Python Imaging Library) adds
> many image processing features to Python. Pillow is a
> fork of PIL that adds some user-friendly features."
>
> It seems to me that Fedora 38 ships with Pillow but
> not PIL.
>
> Anyway, your code worked after inserting a shebang line:
>
> #!/usr/bin/python3

Yup. Python 3 for sure. Shebang lol. Doing it right makes it work:

https://youtu.be/LL-gyhZVvx0

;^D

On 18/07/2023 02:14, Kaz Kylheku wrote:
> On 2023-07-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Half of it seems to be defined by the set of options you give to
>>> compilers like gcc and Clang.
>>>
>>> With one set of options, your program passes. But choose another set,
>>> and it fails, or you have loads of warnings, or the behaviour is
>>> subtly different.
>>>
>>> So much for being portable.
>>
>> gcc and clang have options that cause them to (attempt to) be
>> conforming C compilers, something like "-std=cNN -pedantic", where
>> NN is the edition of the standard you want to conform to.
>>
>> Without those options, gcc and clang are both non-conforming, and
>> of course any program that depends on compiler-specific extensions
>> is not portable.
>>
>> You know all that. You just pretend not to so you can make some point
>> about how much you dislike C. *yawn*
>
> Each compiler option that affects semantics splits the implementation's
> language into two dialects (if the option is Boolean; more if it has
> multiple values).
>
> There is a language standard, but in actual practice, the C world cannot
> agree on a single C language that everyone can like.

The world cannot agree on a type of car that everyone can like. Yet we
manage to drive on the same roads.

Different people need different things for their programming - a certain
degree of variety and option is necessary. But there is also a common
subset - standard C - that can be used by anyone and (baring bugs) on
any compiler.

> One project wants
> wrapping integer arithmetic. Another project deosn't care for that, but
> want to defeat strict aliasing optimizations. Yet another wants char to
> be unsigned.
>

If you want these features, and your implementation (compiler plus flags
plus any other details) guarantees them, fine. Most implementations
can't guarantee these features, so you should not use them. (And if
your code relies on the signedness of "char" in any way, it is broken -
use "signed char" or "unsigned char" if that's what you mean.)

Requirements for the implementation should be part of the documentation
and build information for the code. It is even better if it is in the
code itself - the few pieces of code I have written that benefited from
wrapping signed integer arithmetic had pre-processor checks for GCC, and
a pragma to set the "-fwrapv" flag. And it would be really nice if C
had standardised pragmas to set these commonly requested features (or at
least standardised pre-defined macros to let you check them at compile
time).

> The standard ignores the fact that there exist compiler options and
> those options influence the language dialect, but which sit squarely
> outside of the language syntax, and so don't appear in the translation
> unit

The standard defines a common subset - it is not an implementation.

>
> Everything that changes language semantics should be in the language
> syntax, and standardized.

Disallowing extensions would inhibit innovation and improvement. C is
quite a stable language, but it /has/ changed over the years. And most
significant additions to the C standards since C90 have been based on
extensions found in real-world implementations - that's how the C
standards committee knows the additions are useful and work well in
practice.

>
> The translation unit itself should be able to declare that it
> wants wrapping arithmetic, and over which parts of the code.
>

Agreed - that would be a nice feature. (Implementations would be able
to refuse to compile the code if they don't support wrapping.)

> A standard C in which you have standard-defined optimization controls
> and code generation options in important areas would be a huge
> improvement.
>

There are some cases (such as wrapping signed integer overflow) that are
common enough to benefit from standardisation.

But there are many, many more that are not. Microsoft's C compiler for
x86-64 should not have to support flags or pragmas for gcc's code
generation on AVR microcontrollers. And changes to gcc's AVR port
should not have to wait for a new C standard to be published before
adding a feature to support a new microcontroller.

On 7/18/2023 12:26 AM, David Brown wrote:
> On 18/07/2023 00:01, Chris M. Thomasson wrote:
>> On 7/17/2023 3:01 PM, fir wrote:
>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>>   C is a  high level language.
>>>
>>> i propose to say c is mid-level language.. i would say its closer to
>>> low-lewel than high-level
>>
>> I tend to agree with that.
>>
>
> I don't know if there is any kind of "official" definition of a
> high-level language.  But I think a reasonable choice would be to say
> that a low-level language is one that is defined in terms of the
> hardware.  Operations in the language do what the hardware says they
> will do.  A high-level language is one that is defined independently of
> any particular hardware.
>
> By that definition, C is a high-level language - it is defined in terms
> of an abstract machine.  It has some implementation-dependent factors
> (as do all languages - though C has perhaps more than most, and is more
> explicit about it than most).  But those affect particular
> implementations of the language rather than the language itself.
>
> Another way to distinguish low and high level languages is to consider
> the usage, and suitability of usage, in "low level" or "systems" coding,
> close to the hardware, as distinct from more abstract coding.  Python is
> then "high level", with native support for infinite precision integers,
> hash maps, standard libraries for application-level features, etc.  C is
> "low level" for supporting efficient and direct hardware access and
> systems coding.  But C++ would then be both a low-level /and/ a
> high-level language.
>
> I personally think it is more accurate to say that C is a low-level
> high-level language, or a high-level language targeting low-level
> programming.  A binary low/high classification is not particularly
> useful - it is perhaps better to think of a scale, in which a language
> like Python would be significantly higher than C.  But as C would score
> well above 0 here, it is very definitely a high level language.
>

Artificially align memory on a large boundary, then use the extra bits
in the pointers to it.

>
>
>