On 19/07/2023 13:38, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 03:29, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>>> <cut>
>>>>>>> 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.
>>> I may be missing the distinction you are making, but the languages
>>> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>>
>> I was trying to make a distinction between /defining/ a language variant
>> and /choosing/ a language variant. The language variant you get with "gcc
>> -std=c11 -pendantic" is not defined by those flags - it is defined by the
>> ISO standards.
>
> I am still missing something. How does any flag define a language or
> variant rather than just providing a way to choose it?

It doesn't define the language. The "-std" flag in particular chooses
the language variant, it does not /define/ anything.

If you have enough flags that vary or enable different features, then
you could say that a particular combination of flags defines the
language variation. That would, perhaps, be a reasonable description of
what you are doing if you had "-Werror" and a selection of different
warning flags - you are then fine-tuning exactly what you consider
acceptable or not in the language you are compiling.

But I'd rather say that for common use at least, like the flags you
gave, you are choosing or specifying the language variation than
defining it.

>
>> I would also not describe "-std=c11" and "-std=c11 -pendantic" as "very
>> different" languages or language variants. The "-pedantic" flag makes gcc
>> give warnings on certain code constructs that were valid in older C
>> versions but not in C11, and on constraint errors where the standard
>> requires a diagnostic even though the compiler can generate reasonable
>> code.
> <cut>
>> However, I still feel "different" languages is a poor description - even if
>> you compare "-std=c11 -pedantic-errors" with "-std=gnu11", you are talking
>> about extensions or additional features - one language is a subset of the
>> other. Code that is accepted by the compiler with both flag settings
>> (whether you consider "accepted" to mean accepted without errors, or
>> accepted without warnings) has the same semantics.
>
> Yes, I thought the problem was one of using terms differently.

That is often the case.

> My
> background includes teaching both the formal theory of languages and
> introductory programming. This:
>
> int main(void) { return ({0;}); }
>
> is a syntax error in every published version of the C language, right
> back to K&R1. Without -pedantic, gcc does not diagnose the syntax
> error. Formally, that's accepting a different language, and from the
> practical point of view of teaching C, I'd want a student to see a
> diagnostic if they wrote that.

I suppose that depends on what we expect to happen with something that
is not in the defined syntax of the language. And it also depends on
how different the language has to be before considering it relevant, or
"very different". A compiler that accepted, without warning or
diagnostic, an otherwise good C file that did not end in a newline
character, would formally be accepting a different language.

Still, I appreciate what you mean. And I'd prefer if gcc extensions
like this needed an explicit enable flag - it would be better to follow
the standards more closely by default. I'd like an explicit choice of
"-std" flag to be mandatory for gcc (I'd actually like there to be a
standardised mandatory pragma for it in the source code). I don't think
it's likely to change, however :-(

>
>> There /are/ gcc flags that actually make the language different, but you
>> need to pick them specifically. "-fgnu89-inline", for example, will make
>> the "inline" keyword work like the pre-standardised version that gcc
>> supported before C99. "-fsigned-char" or "-funsigned-char" will change the
>> sign of plain "char" to something other than the ABI-specified choice for
>> the target, which can affect the semantics of the code.
>
> Since all we are doing at this point is explaining our terms, I'll just
> point out that, to me, C is a language in which the signedness of plain
> char is not specified. "-fsigned-char" or "-funsigned-char" specify the
> same language. Over the years I've seen both defaults several times, so
> now, when I write char, I mentally check that I really mean that. To
> me,
>
> char c;
>
> means "let c be char whose signedness I don't care about". For others,
> it probably means "let c be a char with native (ABI-defined)
> signedness".

I have the same attitude. "char" is for characters - to me, it makes no
sense to have a signdness characteristic. If I want a signed char or an
unsigned char, I write them explicitly. (Actually I'd usually use
uint8_t or int8_t in practice - or their "fast" versions for some kinds
of code. In my kind of coding you often want to be explicit about sizes.)

>
>> So for your list of flags above, consider "-pedantic-errors" rather than
>> "-pedantic".
>
> Obviously I've considered it, but I don't care about the colour of the
> diagnostic, and it's actually handy, when compiling code posted here, to
> be able to run the executable after reviewing the warnings.
>

Fair enough. I've just seen too many cases of "It's only a warning, so
I can ignore it. If it were serious, it would be an error". I also
like to have "-Werror" in my own flag settings, once a program has taken
shape - warnings have a tendency to disappear when you type "make"
twice. But this all depends on the context and what you are trying to
do at the time.

David Brown <david.brown@hesbynett.no> writes:

> On 19/07/2023 13:38, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 19/07/2023 03:29, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>>>> <cut>
>>>>>>>> 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.
>>>> I may be missing the distinction you are making, but the languages
>>>> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>>>
>>> I was trying to make a distinction between /defining/ a language variant
>>> and /choosing/ a language variant. The language variant you get with "gcc
>>> -std=c11 -pendantic" is not defined by those flags - it is defined by the
>>> ISO standards.
>> I am still missing something. How does any flag define a language or
>> variant rather than just providing a way to choose it?
>
> It doesn't define the language. The "-std" flag in particular chooses the
> language variant, it does not /define/ anything.

Of course. That was (I thought) my point and not yours. I'm sure we
agree on all of the facts here, so let me just explain why I thought
your were saying something different to me.

Your wrote (to Bart), "none of these flags define the language [...]
-std=c11 /chooses/ which language standard to use" and then in the next
paragraph "gcc does offer options that change the language...". That
juxtaposition suggested a distinction between two kinds of flag which I
could not understand.

When I asked for clarification you said "I was trying to make a
distinction between /defining/ a language variant and /choosing/ a
language variant". Can you see how I could think were saying that some
flags don't just choose a variant but define one?

--
Ben.

On 19/07/2023 13:30, Malcolm McLean wrote:
> On Wednesday, 19 July 2023 at 11:02:30 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>>> For someone implementing a compiler, the language is defined by the standards
>>> document. But for someone who is not implementing a compiler, the language
>>> is ultimatelt defined by the behaviour of compilers.

No. You could more reasonably say that the language is defined by the
/specification/ or /documentation/ of the compilers you use, if you are
happy with non-portable code that is only sure of working with those
specific compilers. (And often that is exactly what you want.)

Trial-and-error programming is a /bad/ development methodology, unless
you are able to test your code in every possible choice of input.

If you rely on the behaviour of a compiler as it is, then your code
could easily fail when the compiler is upgraded, or flags are changed,
or bugs are fixed. It could fail when your code is used in a different
way, or when re-arrangements and optimisations lead to different inlining.

You can rely on /documented/ behaviours of the compiler beyond what the
standards guarantee. But relying on how it happens to work when you
test it is relying on luck - you are creating a maintenance nightmare
for the future.

(Very occasionally, there can be good reasons for relying on the exact
details of code produced by a particular compiler. But then the
compiler is part of your source - your code is dependent on an exact
toolchain and flag selection for its correctness.)

>> I don't agree completely; I see the situation as more symmetric.
>> I see the standard as a proposed contract between implementers and
>> users. Neither side is (usually) obligated to accept the contract,
>> but both sides can choose to do so, and can expect to be able to rely
>> on the other side to follow the rules. Implementers can provide
>> non-standard extensions, and users can write code that depends on
>> those extensions.
>>
>> An implementation that doesn't at least provide a mode that conforms
>> to the standard is going to be unpopular, and a programmer who
>> doesn't know what's guaranteed by the standard and what's specific
>> to an implementation will have a hard time if they ever want to
>> use a different implementation.
>>
> Well for example the standard doesn't guarantee two's complement
> representation (or at least didn't, I think it might have changed). So anyone
> who relied on that could have seen their code break. But it so unlikely
> that it is hardly worth bothering about.
>

You are very close to saying something very dangerous here. And given
your misconceptions about accessing data through pointer casts, I
suspect you are making similar mistakes here.

Virtually all current implementations use two's complement
representation for signed integers. Up until C23, C allowed ones'
complement and sign-magnitude as alternative representations - these are
no long allowed in C23. However, integer types can still have padding
bits in C23.

I agree that it is reasonable to assume two's complement representation
for signed integers, unless you are writing code with extreme portability.

However, when people talk about two's complement signed integers, they
are sometimes talking about signed arithmetic overflows. This is a very
different matter from the representation of the types. And while almost
all current processors will use two's complement wrapping in their
signed arithmetic instructions, C (including C23) does /not/ guarantee
any behaviour for overflows, and C compilers do not, as a rule,
guarantee any behaviour for overflows. Many optimising compilers will
optimise code on the assumption that signed integer arithmetic does not
overflow. This is not new - I first saw it nearly 30 years ago. It is
not just gcc or clang - MSVC also does such optimisations. The only
compilers I know about for which you can rely on wrapping behaviour are
gcc and clang with the "-fwrapv" flag enabled.

This is a fine example for which people write code thinking "my
processor does this, so C will do that too" and often it will work as
expected during initial testing. But it can fail later, or with
different input, or different optimisation flags.

That is why you should stick to /defined/ behaviour when coding. Rely
on behaviour defined by the compiler rather than the C standards if you
don't need portability and like the extra features. But do not write
code that relies on undefined behaviour happening to compile the way you
want it to.

> Then to take the current example, I checked and Ben is right. The use of a union
> to type pun is "implementation defined".

It is fully define behaviour (though the interpretation of the bits as
different type is implementation-defined, like most type
representations). I don't know what you are referring to as "Ben is
right" here, since I am confident that Ben knows how type-punning unions
work in C. ("Ben is right" is usually a safe bet!)

See 6.5.2.3p3 of the standards, along with the accompanying footnote.

> In C. In C++ it's "undefined". Hence my
> confusion. But it's not unlikely that C code will be compiled by a C++ compiler.
> Now of course you can say "well a C++ compiler compiles a different language,
> so all bets are off", but that's being pedantic rather than useful.

No, it is being useful - C and C++ are significantly different
languages. C is roughly a subset of C++, but there are major points of
divergence.

> The fact is
> that a C++ compiler is a C compiler which supports the conservative core subset
> of the C language, but not necessarily more esoteric features, and you need to
> be aware of that if you undertake to write code snippets which will be generally
> useful.
>

The fact is that C++ compilers are C++ compilers, and C compilers are C
compilers. They might share some common parts - I have never heard of a
C++ compiler that did not have a companion C compiler, other than MSVC
having an extremely limited companion C compiler. (I believe they
finally implemented C99, some 20 years late.)

If a compiler implements a "conservative core subset of the C language",
it is not a C compiler - it's just a partial sort-of-C compiler. If it
does not implement the "more esoteric features", whatever those might
be, then it is not a C compiler. It might still be a useful tool, and
able to handle a useful subset of C, but it is not a C compiler.

If you need to write code that can be handled by such a sort-of C or
subset-C compiler, or code that can be compiled as C and C++ with the
same semantics, then you need to understand the details and limitations.
And that means understanding the /documented/ languages, features and
limitations.

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

> On Wednesday, 19 July 2023 at 03:31:43 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 18/07/2023 03:25, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >>>
>> You /are/ allowed to use it. The fact that it is undefined simply means
>> that the definition of the language does not say what the code means.
>> >> 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.
>> >
>> > I've given examples in the past where the same C program either:
>> >
>> > * Passed with 0 lines of errors or warnings
>> >
>> > * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
>> So you are still trying to imply that C -- the language -- is not
>> defined by it's defining documents -- the ISO standards -- but by
>> compiler options. You are still wrong.
>>
> For someone implementing a compiler, the language is defined by the
> standards document. But for someone who is not implementing a
> compiler, the language is ultimatelt defined by the behaviour of
> compilers.

Your use of the definite article is permitting a confusion to go
unnoticed. I would say that you are talking about two languages here:
there is the C language (defined by the standards) and the language
implemented by the compiler. We usually hope that they are very
similar.

The language implemented by the compiler is obviously very important in
practice, but it's almost impossible to talk about it because it
includes everything from bugs to misunderstandings of the standards.

In that sense, this second language is defined only by the compiler
source code -- it's still not defined by the options. Bart wants to
spread confusion by suggesting that C is a language defined by compiler
options.

--
Ben.

On Wednesday, 19 July 2023 at 14:38:36 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 19 July 2023 at 03:31:43 UTC+1, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >> > On 18/07/2023 03:25, Ben Bacarisse wrote:
> >> >> Bart <b...@freeuk.com> writes:
> >> >>>
> >> You /are/ allowed to use it. The fact that it is undefined simply means
> >> that the definition of the language does not say what the code means.
> >> >> 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.
> >> >
> >> > I've given examples in the past where the same C program either:
> >> >
> >> > * Passed with 0 lines of errors or warnings
> >> >
> >> > * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
> >> So you are still trying to imply that C -- the language -- is not
> >> defined by it's defining documents -- the ISO standards -- but by
> >> compiler options. You are still wrong.
> >>
> > For someone implementing a compiler, the language is defined by the
> > standards document. But for someone who is not implementing a
> > compiler, the language is ultimatelt defined by the behaviour of
> > compilers.
> Your use of the definite article is permitting a confusion to go
> unnoticed. I would say that you are talking about two languages here:
> there is the C language (defined by the standards) and the language
> implemented by the compiler. We usually hope that they are very
> similar.
>
> The language implemented by the compiler is obviously very important in
> practice, but it's almost impossible to talk about it because it
> includes everything from bugs to misunderstandings of the standards.
>
It's also because the standard has to include every extant architecture, and
maybe some which don't exist but theoretically could exist, like Fibonacci
representation machines. Whilst in fact you can probably rely on features like
CHAR_BIT being exactly eight. The standard doesn't guarantee it, but the
vast majority of achitectures make it natural, and on big mainframes that don't
allow 8 bit memory access, in fact C compilers put the program through ANDs
and ORs to create 8 bit chars, because otherwise too much code breaks.
Only digital signals processing chips have wider chars, and they can't run general
purpose programs anyway.
>
> In that sense, this second language is defined only by the compiler
> source code -- it's still not defined by the options. Bart wants to
> spread confusion by suggesting that C is a language defined by compiler
> options.
>
It is a bit of an odd situation. If we write a program which branches if a char is
negative, it will produce one output if we use the "signed chars" option and
another if we use the "unsigned chars" option. So two executables with the
same source and written in the same language produce different output.
So you can argue that in fact the language can't be the same. Or you can argue,
as you have done, that computer languages allow for a sort of ambiguity which
we don't see in natural languages.

Bart <bc@freeuk.com> writes:

> On 19/07/2023 03:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 18/07/2023 03:25, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> 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.
>>>
>>> So why pick on [criticise] a method of accessing the top bit of a 32-bit
>>> word that is going to work on all platforms of interest?
>>
>> It's getting increasingly hard to believe you don't know. I've
>> commented before that you and I seem to view programming in entirely
>> different and incompatible ways, so I suppose it's possible that you
>> think that some code that worked today is correct (today).
>>
>>> What's really going on is that because that method might be tagged as UB
>>> (/because/ of various obscure architectures where it won't work), we're
> not
>>> allowed to use it in cases (perhaps the majority) where there would be
> no
>>> problem.
>>
>> It is explicitly stated to be undefined. It's pure spin to say that it
>> "might be tagged as UB". It's been undefined since ANSI C in 1989.
>
> Tell me again what exactly it is that is undefined. Although whatever it
> is, I'm likely to disagree that is should be undefined.

Using an lvalue expression of type int (*(int *)...) to access an object
whose effective type is float (&f).

> Is it accessing an object declared as f32 via an i32* or u32* pointer?

Why use names that are not those of C types? The original code didn't.
What do you gain by adding more undefined names to the mix?

> For example (assume both are 32 bits):
>
> float* p = malloc(sizeof(float));
>
> int* q = (void*)(p);
>
> *q; // is it this?

No, that's fine. Since you have already stated that you don't want to
learn anything more about C I won't explain why, but it's fine.

> In this case, space for 4 bytes has been allocated. malloc doesn't know if
> that space is for floats, ints, or anything else. I genuinely can't see the
> problem.

Good, because there is no problem.

> Maybe floats and ints are stored in different kinds of memory in some
> peculiar architecture, so that given `float f; int a;`, `&f; &a` are
> radically different pointers? (In that case, how are unions of those even
> possible?)
>
> Tell me!

C is not a structured assembler. It can accommodate very peculiar
hardware because what is permitted by the standard is very carefully
defined.

If you write a bit more about how this special hardware works, I could
probably say whether C could be implemented on it. After all, unions
only have to behave as defined by the abstract machine. Maybe the bit
pattern only has to be moved to the "float area" for doing calculations.
Or (for the particular case in question) the compiler might be able keep
the object in the float area all the time because the machine provides
an operation that permits examining bits in a float. Without more
detail it's impossible to say.

BTW, I like these kinds of thought experiment. Making up crazy
architectures to see of C can be implemented on them can be
entertaining.

>>> I've given examples in the past where the same C program either:
>>>
>>> * Passed with 0 lines of errors or warnings
>>>
>>> * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
>>
>> So you are still trying to imply that C -- the language -- is not
>> defined by it's defining documents -- the ISO standards -- but by
>> compiler options. You are still wrong.
>
> So the C standard gives no leeway to a compiler in whether a particular
> construct in an input should Pass, be given an Warning, or fail with an
> Error?

Maybe we could clear up one point at a time? If you are not trying to
imply (or indeed state) that C is defined by compiler options, say so
and I stop talking about that. But if you are, we really need to clear
that up before moving on to what the standard says about diagnostics.

>> Are you seriously going to go over this old ground again? I can't
>> believe you've forgotten, so what do think would be the point of
>> re-hashing it all again?
>
> Because it is crazy.

I note your opinion but I don't think it's worth going over it all
again.

>>> My bcc compiler failed it /unless/ I specified '-old'.
>>
>> Curious. Why is the program acceptable with that flag but not without?
>
> My compiler accepts two variations of C for practical reasons. There's the
> version I prefer, and the less safe version that is necessary to build
> legacy code without needing extensive changes.

That's not what I was asking. I think I was unclear. The example you
gave is undefined by every C standard. I wondered what it was that -old
was toggling inside the compiler.

--
Ben.

On 19/07/2023 13:07, Bart wrote:
>
> On 19/07/2023 03:31, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> On 18/07/2023 03:25, Ben Bacarisse wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>> 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.
> >>
> >> So why pick on [criticise] a method of accessing the top bit of a
> 32-bit
> >> word that is going to work on all platforms of interest?
> >
> > It's getting increasingly hard to believe you don't know.  I've
> > commented before that you and I seem to view programming in entirely
> > different and incompatible ways, so I suppose it's possible that you
> > think that some code that worked today is correct (today).
> >
> >> What's really going on is that because that method might be tagged
> as UB
> >> (/because/ of various obscure architectures where it won't work),
> we're not
> >> allowed to use it in cases (perhaps the majority) where there would
> be no
> >> problem.
> >
> > It is explicitly stated to be undefined.  It's pure spin to say that it
> > "might be tagged as UB".  It's been undefined since ANSI C in 1989.
>
> Tell me again what exactly it is that is undefined. Although whatever it
> is, I'm likely to disagree that is should be undefined.
>
> Is it accessing an object declared as f32 via an i32* or u32* pointer?

Yes, I believe that is the topic in question.

Again - it is entirely reasonable to feel it /should/ be defined
behaviour. It is entirely reasonable to define the behaviour in your
own compiler. I am not trying to say what I think C should be - that's
a matter of opinion. I am trying to tell you what it /is/ - matters of
fact, not opinion. (Well, as factually accurate as I can manage - Ben,
Keith or others will correct me if I'm wrong.)

But the simple fact is that in the C language, it is /not/ defined
behaviour (unless you are using something like a Analog Devices SHARC
processor, which has CHAR_BIT equal to 32). And the fact is that some
compilers use type-based alias analysis to give more efficient results
for correct code - they do not guarantee that incorrect C code that
messes with pointer aliasing will give the results the programmer might
be wanting.

>
> For example (assume both are 32 bits):
>
>      float* p = malloc(sizeof(float));
>
>      int* q = (void*)(p);
>
>      *q;        // is it this?
>
> In this case, space for 4 bytes has been allocated. malloc doesn't know
> if that space is for floats, ints, or anything else. I genuinely can't
> see the problem.

Please read section 6.5 of the standards, paragraphs 6 and 7. The
details are more complicated for allocated space than for declared objects.

The line "*q;" is, I believe, undefined behaviour - it is attempting to
read an "int" object when no such object exists at that address. You
would have the same problem evaluating "*p;" as no float object exists
at that address either.

You would be fine if you wrote "*q = 123;". Thereafter, there is an
"int" object at that address, and you can write "int x = *q;" if you
like. But then "float f = *p;" would be undefined behaviour, as you are
attempting to read an int object via an incompatible lvalue type. (See
6.5p7 for all the defined ways to access the data.)

Unlike with an object that is declared with a specific type, you are
allowed to change the effective type of the object stored. So this is fine:

*q = 123;
int x = *q;

*p = 45.6f;
float f = *p;

But now "int y = *q;" is undefined behaviour.

>
> Maybe floats and ints are stored in different kinds of memory in some
> peculiar architecture, so that given `float f; int a;`, `&f; &a` are
> radically different pointers? (In that case, how are unions of those
> even possible?)
>
> Tell me!

This /has/ been explained to you many times - dozens or hundreds of
times over the years. And it is all laid out in the C standards - you
have been given the reference dozens of times at least.

It is not about the sizes of the types, or the kinds of memory, or the
way the pointers work. (I have actually used a system where 8-bit data
and 16-bit, and bigger, data were in different memory areas, but that's
beside the point.)

For the language definition, it is about what makes sense in the code.
C is a typed language. It does not make it very hard to mess around
with types, and it does not have good support for making your own types
that are convenient to use, but it /is/ a typed language. A float is a
float - it is not an int, and it does not make sense to use it as an
int. If you have some particular reason to want to access the
underlying bits in the representation of a float object, C has was to do
that - but simply pretending it is an int is not valid. (It would be
nice if pointer casts were not as simple to write as they are, or gave
more warnings by default in tools, but that would make some other
legitimate and defined code more awkward.)

For the compiler, it is about effective types, and their use in alias
analysis. Alias analysis is a very significant part of optimisation -
it can make a big difference to code if the compiler knows for sure that
a certain piece of data may or may not be accessed via a certain lvalue
(identifier or pointer). Such knowledge lets the compiler be much more
aggressive about keeping data in registers, re-using results, or
pre-calculating information. Type-based alias analysis - knowing which
lvalue types can be used to access which objects - is part of that. In
C, it is a relatively small part - it makes a bigger difference in C++
optimisation, as C++ programmers tend to use a lot more types. But it
happens in C too. Let's take a silly little example:

#pragma GCC optimize "-O2"

float foo(float * f, int * p, float x, int y) {
*f = x;
*p = y;
return *f;
}

#pragma GCC optimize "-fno-strict-aliasing"

float foo2(float * f, int * p, float x, int y) {
*f = x;
*p = y;
return *f;
}

foo:
movss %xmm0, (%rdi)
movl %edx, (%rsi)
ret
foo2:
movss %xmm0, (%rdi)
movl %edx, (%rsi)
movss (%rdi), %xmm0
ret

In "foo", the compiler can optimise knowing that the float object
pointed to by "*f" can never be addressed by the int pointer "p". The
last line can be implemented as "return x;".

In "foo2", we have told the compiler to disable type-based alias
analyses - we allow any pointer type to access any object type. Now the
compiler has to assume that the line "*p = y;" might affect the float
object pointed at by "*f", because "p" and "f" might alias. Thus it has
to make an extra load here for "return *f;".

In real-world code, under heavy optimisation, you have a lot of code
inlined, moved around and re-arranged. The compiler will fight hard to
keep data in registers and minimise memory accesses, because memory
accesses (even when cached) are slow. Every hint of information that
can let it avoid an extra access is a good thing.

>
> Bear in mind that I've created and implemented systems languages for
> decades, and have also implemented a version of C. I'm the position of
> being able to ensure that such code is well-defined for /my/
> implementations on a specified range of targets.
>

You do what you like in your own languages.

> If a C implementation (not mine) decides to seize on UB to make obvious
> code do something non-obvious and against the clear intentions of the
> programmer, that is not something I would have sympathy with.
>

The thing about UB is that it is /not/ clear what the programmer meant -
because there is no defined behaviour for it. It might look clear in
simple cases (and in simple cases the compiler will likely do what the
programmer wanted, even if it is UB - but perhaps with a warning), but
gets a lot less clear in more complex cases.

On 19/07/2023 15:12, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 13:38, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 19/07/2023 03:29, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>
>>>>>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>>>>> <cut>
>>>>>>>>> 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.
>>>>> I may be missing the distinction you are making, but the languages
>>>>> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>>>>
>>>> I was trying to make a distinction between /defining/ a language variant
>>>> and /choosing/ a language variant. The language variant you get with "gcc
>>>> -std=c11 -pendantic" is not defined by those flags - it is defined by the
>>>> ISO standards.
>>> I am still missing something. How does any flag define a language or
>>> variant rather than just providing a way to choose it?
>>
>> It doesn't define the language. The "-std" flag in particular chooses the
>> language variant, it does not /define/ anything.
>
> Of course. That was (I thought) my point and not yours. I'm sure we
> agree on all of the facts here, so let me just explain why I thought
> your were saying something different to me.
>
> Your wrote (to Bart), "none of these flags define the language [...]
> -std=c11 /chooses/ which language standard to use" and then in the next
> paragraph "gcc does offer options that change the language...". That
> juxtaposition suggested a distinction between two kinds of flag which I
> could not understand.
>
> When I asked for clarification you said "I was trying to make a
> distinction between /defining/ a language variant and /choosing/ a
> language variant". Can you see how I could think were saying that some
> flags don't just choose a variant but define one?
>

Yes, I can see how there was different interpretations here - it's a
risk when mixing replies to more than one person in the same post. But
I think we've got it sorted and agreed now.

David Brown <david.brown@hesbynett.no> writes:

> On 19/07/2023 15:12, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 19/07/2023 13:38, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 19/07/2023 03:29, Ben Bacarisse wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>>
>>>>>>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>>>>>> <cut>
>>>>>>>>>> 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.
>>>>>> I may be missing the distinction you are making, but the languages
>>>>>> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>>>>>
>>>>> I was trying to make a distinction between /defining/ a language variant
>>>>> and /choosing/ a language variant. The language variant you get with "gcc
>>>>> -std=c11 -pendantic" is not defined by those flags - it is defined by the
>>>>> ISO standards.
>>>> I am still missing something. How does any flag define a language or
>>>> variant rather than just providing a way to choose it?
>>>
>>> It doesn't define the language. The "-std" flag in particular chooses the
>>> language variant, it does not /define/ anything.
>> Of course. That was (I thought) my point and not yours. I'm sure we
>> agree on all of the facts here, so let me just explain why I thought
>> your were saying something different to me.
>> Your wrote (to Bart), "none of these flags define the language [...]
>> -std=c11 /chooses/ which language standard to use" and then in the next
>> paragraph "gcc does offer options that change the language...". That
>> juxtaposition suggested a distinction between two kinds of flag which I
>> could not understand.
>> When I asked for clarification you said "I was trying to make a
>> distinction between /defining/ a language variant and /choosing/ a
>> language variant". Can you see how I could think were saying that some
>> flags don't just choose a variant but define one?
>
> Yes, I can see how there was different interpretations here - it's a risk
> when mixing replies to more than one person in the same post. But I think
> we've got it sorted and agreed now.

Well, no, because I still don't know what the "other" set of options do.
It's not choosing a variant and it's not defining the language; it's
something else. Anyway, I am not particularly bothered, but only one of
us knows what you meant!

--
Ben.

David Brown <david.brown@hesbynett.no> writes:

> On 19/07/2023 13:07, Bart wrote:

>> Is it accessing an object declared as f32 via an i32* or u32* pointer?
>
> Yes, I believe that is the topic in question.

Specifically (to avoid using Bart's undefined types) it's

float f;
static_assert(sizeof f == sizeof (int));
...
*(int *)&f;

> But the simple fact is that in the C language, it is /not/ defined
> behaviour (unless you are using something like a Analog Devices SHARC
> processor, which has CHAR_BIT equal to 32).

Not sure why you say this. Surely *(int *)&f is undefined even when
CHAR_BIT is 32, and *(char *)&f is defined regardless of the value of
CHAR_BIT, is it not?

There's the issue of non-values that can result in UB depending on lots
of factors, but that's not what's being discussed here.

>> For example (assume both are 32 bits):
>>      float* p = malloc(sizeof(float));
>>      int* q = (void*)(p);
>>      *q;        // is it this?
>> In this case, space for 4 bytes has been allocated. malloc doesn't know
>> if that space is for floats, ints, or anything else. I genuinely can't
>> see the problem.
>
> Please read section 6.5 of the standards, paragraphs 6 and 7. The details
> are more complicated for allocated space than for declared objects.
>
> The line "*q;" is, I believe, undefined behaviour - it is attempting to
> read an "int" object when no such object exists at that address. You would
> have the same problem evaluating "*p;" as no float object exists at that
> address either.

I think you are right about *q being UB, but I don't think "no such
object exists" is a useful way to put it. I've not studied the details
of the new standard, but accessing an object with an indeterminate value
is probably still UB, but there's surely an object there if malloc
succeeds.

I replied saying it's fine (I'll post a correction) because it's fine
from the point of view of the effective type rules that are what was
being discussed.

> You would be fine if you wrote "*q = 123;".

If "no such object exists at that address" how could that be permitted.
malloc (if it succeeds) simply creates an object with no effective type.

--
Ben.

Am 17.07.2023 um 22:28 schrieb Kalevi Kolttonen:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Python is totally different and for sure not designed
>> for the same purposes.
>
> Both are suitable for some application programming,
> so there is some overlap between their usage
> cases.

C and C++ are designed to develop software that is system-near
and / or have near-optimal performance. Python can't do that,
it's much easier to program for it.

Am 18.07.2023 um 12:37 schrieb Blue-Maned_Hawk:
> On 7/17/23 12:26, Bonita Montero wrote:
>> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>>>
>>> ​Ain't nothing gonna dethrone C until a total revolution of the
>>> modern computing ecosystem; in other words, replacing C would require
>>> replacing everything else all at once.
>>
>> C has already been dethroned many times.
>
> ​I think you and i have different definitions of "dethrone" here.

This statement is based on the language features. There are now
some languages that are also system-related and also allow almost
optimal performance, but are much more comfortable to program.
F.e. Rust and C++.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:

>> For example (assume both are 32 bits):
>>
>> float* p = malloc(sizeof(float));
>>
>> int* q = (void*)(p);
>>
>> *q; // is it this?
>
> No, that's fine. Since you have already stated that you don't want to
> learn anything more about C I won't explain why, but it's fine.

It's fine by the effective type rules that are being discussed, but
David has reminded me that it's undefined for another reason -- the
value in the object is indeterminate.

--
Ben.

środa, 19 lipca 2023 o 18:08:12 UTC+2 Bonita Montero napisał(a):
> Am 18.07.2023 um 12:37 schrieb Blue-Maned_Hawk:
> > On 7/17/23 12:26, Bonita Montero wrote:
> >> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
> >>>
> >>> ​Ain't nothing gonna dethrone C until a total revolution of the
> >>> modern computing ecosystem; in other words, replacing C would require
> >>> replacing everything else all at once.
> >>
> >> C has already been dethroned many times.
> >
> > ​I think you and i have different definitions of "dethrone" here.
>
> This statement is based on the language features. There are now
> some languages that are also system-related and also allow almost
> optimal performance, but are much more comfortable to program.
> F.e. Rust and C++.

i asked for rust somewhat becouse there are people who say it should detrone c though i
recently found an opinion it uis rather to 'dethrone' c++, your favourite pony

so what with that you will bite that rust?

On 19/07/2023 15:27, David Brown wrote:
> On 19/07/2023 13:07, Bart wrote:
> For the language definition, it is about what makes sense in the code. C
> is a typed language. It does not make it very hard to mess around with
> types, and it does not have good support for making your own types that
> are convenient to use, but it /is/ a typed language. A float is a float
> - it is not an int, and it does not make sense to use it as an int.
Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
memory and defined what they represented by the operations you chose.

If you've ever written interpreters, you might well have found that a
'bytecode' program is a sequence of values, all allocated as one
homogeneous block of u64 or whatever, where any value can represent a
bytecode, or function pointer, or integer, or float, or data pointer, or ...

While it is also very common for a 64-bit operand to be a pointer,
integer or float according to some bit-encoding, eg the low bits of the
pointer, or some special set of NaN values.

I'm sure this can also be written in C, which is going to play havoc
with all your aliasing rules.

> If
> you have some particular reason to want to access the underlying bits in
> the representation of a float object, C has was to do that - but simply
> pretending it is an int is not valid.
Then it doesn't play well as a /systems/ programming language. I want
such a language to be only a couple of steps above assembly. In assembly
(this is mine for x64), I can write this:

main::
mov D10, fmt
mov D11, [f]
mov XMM1, [f] # (variadic floats must be loaded to both)
mov D12, [a]
call printf*
mov D10,0
call exit*

isegment
f:
a:
dq 1.0

fmt:
db "%llX %f",10,0

There is a float64 value that is accessed as both a float64, and an int64.

The output here is:

3FF0000000000000 1.000000

This ASM corresponds to this program in my language, which has the same
output:

real f=1.0
int a @ f

proc main=
printf("%llX %f\n", f, a)
end

However, it can't be directly expressed in C. The nearest might be:

#include <stdio.h>

union {
double f;
long long int a;
} dummy = {1.0};

int main(void) {
printf("%llX %f\n", dummy.f, dummy.a);
}

Not too bad. But in mine you don't really need that equivalence (the @),
nor printf!. It is far more amenable to low-level systems work without
tying yourself up in knots.

> happens in C too. Let's take a silly little example:
>
> #pragma GCC optimize "-O2"
>
> float foo(float * f, int * p, float x, int y) {
> *f = x;
> *p = y;
> return *f;
> }
>
> #pragma GCC optimize "-fno-strict-aliasing"
>
> float foo2(float * f, int * p, float x, int y) {
> *f = x;
> *p = y;
> return *f;
> }
>
> foo:
> movss %xmm0, (%rdi)
> movl %edx, (%rsi)
> ret
> foo2:
> movss %xmm0, (%rdi)
> movl %edx, (%rsi)
> movss (%rdi), %xmm0
> ret
>
>
> In "foo", the compiler can optimise knowing that the float object
> pointed to by "*f" can never be addressed by the int pointer "p". The
> last line can be implemented as "return x;".

How well does the foo example work when called like this:

union { float f; int a;} xx;
memset(&xx, 0, sizeof(xx));
printf("%f\n", foo(&xx.f, &xx.a, 53.4, 777));

I get output of 0.0 with gcc -O0/O1, and approx 53.4 with -O2/O3.

I thought the use of unions was well-defined?

On 19/07/2023 17:08, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>
>>> For example (assume both are 32 bits):
>>>
>>> float* p = malloc(sizeof(float));
>>>
>>> int* q = (void*)(p);
>>>
>>> *q; // is it this?
>>
>> No, that's fine. Since you have already stated that you don't want to
>> learn anything more about C I won't explain why, but it's fine.
>
> It's fine by the effective type rules that are being discussed, but
> David has reminded me that it's undefined for another reason -- the
> value in the object is indeterminate.

Reading uninitialised memory is UB? OK. I hadn't bothered with
initialising in my example as it seemed irrelevant. Assume I'd called
some `mallocz` function that zeros the allocation (or is all-bits-zero
not guaranteed to be a valid float64 value?!).

You say that typewise it's fine, but it looks like it will still cause
problems with David's foo(float*, int*, float, int) example.

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

> On Wednesday, 19 July 2023 at 14:38:36 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 19 July 2023 at 03:31:43 UTC+1, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >>
>> >> > On 18/07/2023 03:25, Ben Bacarisse wrote:
>> >> >> Bart <b...@freeuk.com> writes:
>> >> >>>
>> >> You /are/ allowed to use it. The fact that it is undefined simply means
>> >> that the definition of the language does not say what the code means.
>> >> >> 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.
>> >> >
>> >> > I've given examples in the past where the same C program either:
>> >> >
>> >> > * Passed with 0 lines of errors or warnings
>> >> >
>> >> > * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
>> >> So you are still trying to imply that C -- the language -- is not
>> >> defined by it's defining documents -- the ISO standards -- but by
>> >> compiler options. You are still wrong.
>> >>
>> > For someone implementing a compiler, the language is defined by the
>> > standards document. But for someone who is not implementing a
>> > compiler, the language is ultimatelt defined by the behaviour of
>> > compilers.
>> Your use of the definite article is permitting a confusion to go
>> unnoticed. I would say that you are talking about two languages here:
>> there is the C language (defined by the standards) and the language
>> implemented by the compiler. We usually hope that they are very
>> similar.
>>
>> The language implemented by the compiler is obviously very important in
>> practice, but it's almost impossible to talk about it because it
>> includes everything from bugs to misunderstandings of the standards.
>>
> It's also because the standard has to include every extant
> architecture,

I'm not sure what "it" refers to here so I'll leave this bit alone...

> and maybe some which don't exist but theoretically could exist, like
> Fibonacci representation machines. Whilst in fact you can probably
> rely on features like CHAR_BIT being exactly eight. The standard
> doesn't guarantee it, but the vast majority of achitectures make it
> natural, and on big mainframes that don't allow 8 bit memory access,
> in fact C compilers put the program through ANDs and ORs to create 8
> bit chars, because otherwise too much code breaks. Only digital
> signals processing chips have wider chars, and they can't run general
> purpose programs anyway.
>>
>> In that sense, this second language is defined only by the compiler
>> source code -- it's still not defined by the options. Bart wants to
>> spread confusion by suggesting that C is a language defined by compiler
>> options.
>>
> It is a bit of an odd situation. If we write a program which branches
> if a char is negative, it will produce one output if we use the
> "signed chars" option and another if we use the "unsigned chars"
> option. So two executables with the same source and written in the
> same language produce different output.

Yes, but I am surprised you think that's odd. Maybe I think about the
meaning of programs in very different terms to you. In formal
semantics, there's no problem stating that there is more than one
possible output, and when being informal you just need to adjust the
words a bit. The "meaning" of this program:

#include <stdio.h>

int main(void) { printf("%u\n", -1u); }

is "print the decimal representation of the largest unsigned int". It's
not "print 4294967295" or "print 65535" (or any of the other
possibilities).

> So you can argue that in fact
> the language can't be the same. Or you can argue, as you have done,
> that computer languages allow for a sort of ambiguity which we don't
> see in natural languages.

I am not arguing that. For one thing, I don't consider "print the
decimal representation of the largest unsigned int" to be ambiguous, but
even if you do consider it so, it is ambiguous in a very particular
sense, quite unlike most ambiguities in natural language.

--
Ben.

On 2023-07-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> I am still missing something. How does any flag define a language or
> variant rather than just providing a way to choose it?

Because the combinations of flags are not separately defined languages.
If you have 8 Boolean flags, giving rise to 256 combinations, that could
in principle select one of 256 separately-defined language
implementations. In practice, it doesn't. You're defining it
via feature combination.

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

On 19/07/2023 18:30, Bart wrote:
> On 19/07/2023 17:08, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>
>>>> For example (assume both are 32 bits):
>>>>
>>>>       float* p = malloc(sizeof(float));
>>>>
>>>>       int* q = (void*)(p);
>>>>
>>>>       *q;        // is it this?
>>>
>>> No, that's fine.  Since you have already stated that you don't want to
>>> learn anything more about C I won't explain why, but it's fine.
>>
>> It's fine by the effective type rules that are being discussed, but
>> David has reminded me that it's undefined for another reason -- the
>> value in the object is indeterminate.
>
> Reading uninitialised memory is UB? OK.

Yes. But as you say, it /is/ okay - after all, there is no point in
doing so.

> I hadn't bothered with
> initialising in my example as it seemed irrelevant. Assume I'd called
> some `mallocz` function that zeros the allocation (or is all-bits-zero
> not guaranteed to be a valid float64 value?!).

Or perhaps the actual standard function for that purpose - calloc().

>
> You say that typewise it's fine, but it looks like it will still cause
> problems with David's foo(float*, int*, float, int) example.
>

I covered that in detail in another reply. (For the record, the zero
initialisation with calloc() does not give the memory a type, so the
treatment of everything after that is the same.)

On 19/07/2023 18:06, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 13:07, Bart wrote:
>
>>> Is it accessing an object declared as f32 via an i32* or u32* pointer?
>>
>> Yes, I believe that is the topic in question.
>
> Specifically (to avoid using Bart's undefined types) it's
>
> float f;
> static_assert(sizeof f == sizeof (int));
> ...
> *(int *)&f;

We could use int32_t (from C99) and float32_t (from C23). But while it
is strange of Bart to use his home-made types in a C group, I don't
think it is /too/ unreasonable to assume the meaning of his types.

>
>> But the simple fact is that in the C language, it is /not/ defined
>> behaviour (unless you are using something like a Analog Devices SHARC
>> processor, which has CHAR_BIT equal to 32).
>
> Not sure why you say this. Surely *(int *)&f is undefined even when
> CHAR_BIT is 32, and *(char *)&f is defined regardless of the value of
> CHAR_BIT, is it not?

Of course you are correct - "int" is not the same type as "char" or
"signed char", even if they are the same size. It is conceivable - but
unlikely - that "int32_t" is a typedef for "signed char" on the
platform, in which case you /could/ use an "int32_t *" pointer to access
the float.

>
> There's the issue of non-values that can result in UB depending on lots
> of factors, but that's not what's being discussed here.

And platforms with non-values, trap values or padding bits for these
types are even more obscure than devices with 32-bit char.

>
>>> For example (assume both are 32 bits):
>>>      float* p = malloc(sizeof(float));
>>>      int* q = (void*)(p);
>>>      *q;        // is it this?
>>> In this case, space for 4 bytes has been allocated. malloc doesn't know
>>> if that space is for floats, ints, or anything else. I genuinely can't
>>> see the problem.
>>
>> Please read section 6.5 of the standards, paragraphs 6 and 7. The details
>> are more complicated for allocated space than for declared objects.
>>
>> The line "*q;" is, I believe, undefined behaviour - it is attempting to
>> read an "int" object when no such object exists at that address. You would
>> have the same problem evaluating "*p;" as no float object exists at that
>> address either.
>
> I think you are right about *q being UB, but I don't think "no such
> object exists" is a useful way to put it. I've not studied the details
> of the new standard, but accessing an object with an indeterminate value
> is probably still UB, but there's surely an object there if malloc
> succeeds.
>

By "no such object exists", I mean "no object of type int exists at that
address". There is an object with size, but no declared or effective type.

To be honest, I couldn't find a clear rule here. Attempting to use the
value of an automatic storage variable while it is indeterminate is
explicitly UB, but I saw no obvious paragraph in the standards (C17 or
C23) about it. (I see Tim Rentsch is blessing the group with a flying
visit again. If he gets bored necroposting, maybe he will join in here
and give an opinion - I find his style very irritating, but there's no
denying his knowledge of these kinds of details.)

> I replied saying it's fine (I'll post a correction) because it's fine
> from the point of view of the effective type rules that are what was
> being discussed.

Agreed.

>
>> You would be fine if you wrote "*q = 123;".
>
> If "no such object exists at that address" how could that be permitted.
> malloc (if it succeeds) simply creates an object with no effective type.
>

As I understand it, malloc creates an object with size but no declared
type. When you store a value with a type (in this case, an "int") to an
object having no declared type, the effective type for the object
becomes that of the lvalue used for the access - thus you can now put
the int value into the int object. And the object remains of int type
until you store something else in it, in which case it inherits that new
type.

(This is all from 6.5p6.)

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-07-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> I am still missing something. How does any flag define a language or
>> variant rather than just providing a way to choose it?
>
> Because the combinations of flags are not separately defined languages.
> If you have 8 Boolean flags, giving rise to 256 combinations, that could
> in principle select one of 256 separately-defined language
> implementations. In practice, it doesn't. You're defining it
> via feature combination.

That is a reasonable point view. I wonder if that is what was meant.

Personally, I think the definition comes from the documentation that
describes the flags, but I can see what you mean.

--
Ben.

On 19/07/2023 18:22, Bart wrote:
> On 19/07/2023 15:27, David Brown wrote:
> > On 19/07/2023 13:07, Bart wrote:
> > For the language definition, it is about what makes sense in the code. C
> > is a typed language.  It does not make it very hard to mess around with
> > types, and it does not have good support for making your own types that
> > are convenient to use, but it /is/ a typed language.  A float is a float
> > - it is not an int, and it does not make sense to use it as an int.
> Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
> memory and defined what they represented by the operations you chose.
>

BCPL is before my time. But I think you are correct. C was intended to
have stronger typing than BCPL.

> If you've ever written interpreters, you might well have found that a
> 'bytecode' program is a sequence of values, all allocated as one
> homogeneous block of u64 or whatever, where any value can represent a
> bytecode, or function pointer, or integer, or float, or data pointer, or
> ...

I have only written very specialist interprets for micro-languages, so
that's not very relevant here. But I have had occasions where I've
wanted to view buffers as different types. Usually a union is the most
convenient answer, but sometimes memcpy() is better, and sometimes types
with gcc's "may_alias" attribute. (A type with that attribute has the
"superpowers" that char lvalues have, and may be used to access objects
of any type. It's a gcc extension, rather than a standard feature,
unfortunately.)

>
> While it is also very common for a 64-bit operand to be a pointer,
> integer or float according to some bit-encoding, eg the low bits of the
> pointer, or some special set of NaN values.
>
> I'm sure this can also be written in C, which is going to play havoc
> with all your aliasing rules.
>

Unions are typically your friend here.

> >  If
> > you have some particular reason to want to access the underlying bits in
> > the representation of a float object, C has was to do that - but simply
> > pretending it is an int is not valid.
> Then it doesn't play well as a /systems/ programming language. I want
> such a language to be only a couple of steps above assembly. In assembly
> (this is mine for x64), I can write this:

There are many things that can be expressed in assembly that cannot be
expressed in C. The higher level a language, the more you cannot
express in it - that's what makes high level languages more powerful,
because you can rely on more invariants and more assumptions about your
data.

>     real f=1.0
>     int a @ f
>
>     proc main=
>         printf("%llX %f\n", f, a)
>     end
>
> However, it can't be directly expressed in C. The nearest might be:
>
>     #include <stdio.h>
>
>     union {
>         double f;
>         long long int a;
>     } dummy = {1.0};
>
>     int main(void) {
>         printf("%llX %f\n", dummy.f, dummy.a);
>     }
>
> Not too bad. But in mine you don't really need that equivalence (the @),
> nor printf!. It is far more amenable to low-level systems work without
> tying yourself up in knots.

I have done low-level programming for about three decades, and I cannot
imagine a situation where I would feel the need for "amenable" ways to
do this. I see the use in treating data (such as a struct) was an array
of bytes for passing around network packets, and that kind of thing.
But reading or writing floating point data as integer data? It makes no
sense. Still, C lets me do it safely if I want to do it, and it is a
/good/ thing if the language requires awkward code for rare and
dangerous operations. (It would be better if it also make seemingly
obvious but incorrect alternatives, such as via pointer casts, hard errors.)

>
>
> > happens in C too.  Let's take a silly little example:
> >
> > #pragma GCC optimize "-O2"
> >
> > float foo(float * f, int * p, float x, int y) {
> >      *f = x;
> >      *p = y;
> >      return *f;
> > }
> >
> > #pragma GCC optimize "-fno-strict-aliasing"
> >
> > float foo2(float * f, int * p, float x, int y) {
> >      *f = x;
> >      *p = y;
> >      return *f;
> > }
> >
> > foo:
> >          movss   %xmm0, (%rdi)
> >          movl    %edx, (%rsi)
> >          ret
> > foo2:
> >          movss   %xmm0, (%rdi)
> >          movl    %edx, (%rsi)
> >          movss   (%rdi), %xmm0
> >          ret
> >
> >
> > In "foo", the compiler can optimise knowing that the float object
> > pointed to by "*f" can never be addressed by the int pointer "p".  The
> > last line can be implemented as "return x;".
>
> How well does the foo example work when called like this:
>
>     union { float f; int a;} xx;
>     memset(&xx, 0, sizeof(xx));
>     printf("%f\n", foo(&xx.f, &xx.a, 53.4, 777));
>
> I get output of 0.0 with gcc -O0/O1, and approx 53.4 with -O2/O3.
>
> I thought the use of unions was well-defined?
>

The use of unions /is/ well-defined. But you are not using unions at
the point of failure - the superpowers of the union are lost. The
language standards form a contract in C - the compiler promises to give
expected results for all code that follows the standards and has defined
behaviour, and the programmer promises that the code presented to the
compiler will follow those rules. You have passed pointers to "foo"
that break those rules, and you pay the price.

David Brown <david.brown@hesbynett.no> writes:

> On 19/07/2023 18:06, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 19/07/2023 13:07, Bart wrote:
<cut>
>>>> For example (assume both are 32 bits):
>>>>      float* p = malloc(sizeof(float));
>>>>      int* q = (void*)(p);
>>>>      *q;        // is it this?
>>>> In this case, space for 4 bytes has been allocated. malloc doesn't know
>>>> if that space is for floats, ints, or anything else. I genuinely can't
>>>> see the problem.
>>>
>>> Please read section 6.5 of the standards, paragraphs 6 and 7. The details
>>> are more complicated for allocated space than for declared objects.
>>>
>>> The line "*q;" is, I believe, undefined behaviour - it is attempting to
>>> read an "int" object when no such object exists at that address. You would
>>> have the same problem evaluating "*p;" as no float object exists at that
>>> address either.
>>
>> I think you are right about *q being UB, but I don't think "no such
>> object exists" is a useful way to put it. I've not studied the details
>> of the new standard, but accessing an object with an indeterminate value
>> is probably still UB, but there's surely an object there if malloc
>> succeeds.
>
> By "no such object exists", I mean "no object of type int exists at that
> address". There is an object with size, but no declared or effective
> type.
>
> To be honest, I couldn't find a clear rule here. Attempting to use the
> value of an automatic storage variable while it is indeterminate is
> explicitly UB, but I saw no obvious paragraph in the standards (C17 or
> C23) about it.

I find that phrasing odd. It's "explicitly UB" but you could not find
where this was made explicit?

6.2.6.1 p5 says (in part)

"Certain object representations need not represent a value of the
object type. If such a representation is read by an lvalue expression
that does not have character type, the behavior is undefined."

Elsewhere we can find wording to say that uninitialised local variables
and newly allocated storage contain indeterminate representations. This
includes the possibility of non-value representations.

Thus it's tempting to consider *q as being "almost always well-defined"
but since my view is that the semantics of a construct should include
all the possibilities, the only meaning we can put on "int p;
printf("%d\n", p);" is "none".

We could say it means "print any int value or do anything at all when
int can have non-value representations" but the latter part trumps the
former in formal terms.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 19/07/2023 17:08, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>
>>>> For example (assume both are 32 bits):
>>>>
>>>> float* p = malloc(sizeof(float));
>>>>
>>>> int* q = (void*)(p);
>>>>
>>>> *q; // is it this?
>>>
>>> No, that's fine. Since you have already stated that you don't want to
>>> learn anything more about C I won't explain why, but it's fine.
>> It's fine by the effective type rules that are being discussed, but
>> David has reminded me that it's undefined for another reason -- the
>> value in the object is indeterminate.
>
> Reading uninitialised memory is UB?

Yes, but for reasons that have nothing to do with why the original *(int
*)&f code is undefined. Have you given up on that, or have you just
moved on.

> OK. I hadn't bothered with initialising
> in my example as it seemed irrelevant. Assume I'd called some `mallocz`

You could use calloc.

> function that zeros the allocation (or is all-bits-zero not guaranteed to
> be a valid float64 value?!).

Whatever float64 is, it's irrelevant here. What matters is what all
bits zero mean for the effective type you are "imposing" on the storage,
and that's int.

> You say that typewise it's fine, but it looks like it will still cause
> problems with David's foo(float*, int*, float, int) example.

I didn't bother to comment on that because you don't want to know the
answer.

--
Ben.

On 19/07/2023 20:01, David Brown wrote:
> On 19/07/2023 18:22, Bart wrote:
>> Not too bad. But in mine you don't really need that equivalence (the
>> @), nor printf!. It is far more amenable to low-level systems work
>> without tying yourself up in knots.
>
> I have done low-level programming for about three decades, and I cannot
> imagine a situation where I would feel the need for "amenable" ways to
> do this. I see the use in treating data (such as a struct) was an array
> of bytes for passing around network packets, and that kind of thing. But
> reading or writing floating point data as integer data? It makes no
> sense.

I've done that all the time, but I guess I've worked in different fields.

For example in reading and writing binary file formats that including
float data, but the file is a series of binary bytes.

Or transpiling a HLL to low-level C where most of the type system is
dispensed with, including structs and floats. (One example is
representing data initialising one or more structs with mixed float data.)

Or converting a linear IL stack-based bytecode to C source; stack
elements are represented by a set of u64 locals.

A simple example is in generating ASM source code. You have a float
value representing 1/3 say that you could write out as :

dq 0.333333333333333

The problem is that the binary-to-text conversion might be lossy (how
many decimals will be used?), and converting text-to-binary then
assembling will do its own approximations.

One way to deal with that is to write out the bit-pattern as hex, which
will always have a fixed 16 digits (this is for float64):

dq 0x3FD5555555555555

Inside the assembler, it will now read the exact same bit-pattern as the
original.