On 03/08/2023 17:37, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> There was a mistake in my test program:
>>
>>> long long:"long", \
>>
>> The string should have been "long long".
>>
>> So effectively, values between 2**31 and 2**63-1 inclusive have type
>> int64_t, and there was no conflict when using stdint.h. (This is more
>> sensible, but I would have expected a uint32_t type for values in [2**31
>> .. 2**32).)
>
> That's an odd expectation, but then you do hope that C is as bad as you
> can imagine!

Unfortunately, it is. Notice than when I said [2**31..2**32), I did not
specify a number base for those values. But the rules in C for the types
of integer constants vary between decimal and hex.

The program below shows sizes and types of 4 pairs of identical values.
In each case one is in hex, the other in decimal. The results from gcc
10.x on Windows are:

sizeof 0x7FFFFFFF is 4, type is int32_t
sizeof 2147483647 is 4, type is int32_t

sizeof 0x80000000 is 4, type is uint32_t
sizeof 2147483648 is 8, type is int64_t

sizeof 0x100000000 is 8, type is int64_t
sizeof 4294967296 is 8, type is int64_t

sizeof 0x7FFFFFFFFFFFFFFF is 8, type is uint64_t
sizeof 18446744073709551615 is 16, type is other

Take note of the second pair. This is bizarre. On the way from 0 to
2**64-1, the types of constants span int32_t, uint32_t and int64_t, if
hex is used, but skip uint32_t if decimal is used.

Decimal constants of 2**63 and above have their own issues: gcc says the
type is 'other'; zig cc (I believe that is a form of Clang incorporated
into Zig) says 'uint64_t', but both treat the value as uint64_t, since I
can assign it to 'double' and it ends up as the right value.

>
>> Your comment about long however would only be correct on systems where
>> 'long' is 64 bits.
>
> Indeed. Like the one I'm using to write this.

So in general you weren't right either; you made an assumption or forgot
that the size of 'long' varies.

>> The "other" type for the 18e18 integer constant is still shown, and
there
>> is still a conflict about its type when using 'zig cc'.
>
> I don't know what zic cc is, but gcc's treatment of 18000000000000000000
> is interesting. It says
>
> warning: integer constant is so large that it is unsigned
> 8 | 18000000000000000000;
> | ^~~~~~~~~~~~~~~~~~~~
>
> This warning about is good. Also, the fact that it's type does not
> match any in your list is also good since the standard says the constant
> should have no type.

This is also interesting. Surely if something is so wrong that a
constant has no type, it should give a hard error?

Maybe it's because it's not seen as serious, it's just a matter of
interpreting the bit-pattern.

So, let's give it something to think about; I added these two lines to
my program:

showsize(0x10000000000000000);
showsize(18446744073709551616);

gcc still only warns, it says 'too large for its type' (how does it know
what the type is?). But the output is peculiar:

sizeof 0x10000000000000000 is 4, type is int32_t
sizeof 18446744073709551616 is 4, type is int32_t

It assigns the type 'int32_t', not even 'other'! This is a much more
serious matter of overflowing the highest integer type, and it treats it
more lightly than omitting a -U suffix for a value that can still be
represented in 64 bits.

Note that 'zig cc' (ie. clang, I think, but online Clang does the same),
gives a hard error here. Of course, David Brown will forgive gcc and
just say it's my fault for not feeding it the right options!

(Maybe my 10.x version is old, but 13.2 on godbolt just gave warnings too.)

Here's one other quirky thing:

double x = 0x123p10;
printf("x=%f\n",x);

This a floating point constant using hexadecimal, supposedly. The output is:

x=297984.000000

To get that value, means that in '0x123p10':

* Only the '123' is actually HEXADECIMAL
* The '10' is actually DECIMAL 10 ...
* ... and it specifies the exponent in BINARY (p10 means *2**10)

All that's missing is a bit in OCTAL (maybe the '0' in '0x' will serve!)

---------------------------

#include <stdio.h>
#include <stdint.h>

#define typestr(x) \
_Generic(x, \
int8_t:"int8_t", \
int16_t:"int16_t", \
int32_t:"int32_t", \
int64_t:"int64_t", \
uint8_t:"uint8_t", \
uint16_t:"uint16_t", \
uint32_t:"uint32_t", \
uint64_t:"uint64_t", \
default:"other")

#define showsize(x) \
printf("sizeof " #x " is %zu, type is %s\n", sizeof(x), typestr(x))

int main(void) {
showsize(0x7FFFFFFF);
showsize(2147483647);
puts("");
showsize(0x80000000);
showsize(2147483648);
puts("");
showsize(0x100000000);
showsize(4294967296);
puts("");
showsize(0xFFFFFFFFFFFFFFFF);
showsize(18446744073709551615);
}

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I don't know what zic cc is, but gcc's treatment of 18000000000000000000
> is interesting. It says
>
> warning: integer constant is so large that it is unsigned
> 8 | 18000000000000000000;
> | ^~~~~~~~~~~~~~~~~~~~
>
> This warning about is good. Also, the fact that it's type does not
> match any in your list is also good since the standard says the constant
> should have no type. But those two together surprise me a bit -- no
> type, but it's unsigned.

(18000000000000000000 is larger than 2**63 and less than 2**64.)

That looks like an incorrect warning going back to the C90 rules.

In C90, the type of an unsuffixed decimal integer constant is the first
of (int, long int, unsigned long int) in which its value can be
represented. C99 and later editions changed that list to (int, long
int, long long int), so an unsuffixed decimal integer constant can never
be unsigned.

I speculate that the authors of C99 decided that (a) staying with signed
types would be more consistent and useful and (b) it's unlikely that a
programmer would actually write 9223372036854775808 or
18446744073709551615. (And of course if you want an unsigned value, you
can use a U, UL, or ULL suffix and/or hexadecimal, or use some other
more legible expression.)

gcc, as an extension, allows unsuffixed decimal integer constants in the
range LLONG_MAX+1 .. ULLONG_MAX (and gives that warning by default).
With "-pedantic-errors", it's a fatal error.

Now here's the weird part. Using _Generic, gcc on my system gives
18000000000000000000 type __int128, *not* unsigned long long, which is
inconsistent with the warning. (clang makes it unsigned long long.)
This could be valid if gcc treated __int128 as an *extended integer
type*, but it doesn't.

Both gcc and clang issue a diagnostic for that constant with
"-pedantic", which is all the standard requires, so this isn't a
conformance issue.

There's an existing bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788

(Just to mention, this is not a problem with the C language, which
clearly defines the semantics.)

--
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 03/08/2023 03:07, Bart wrote:
> On 02/08/2023 16:58, David Brown wrote:
>> On 01/08/2023 22:01, Bart wrote:
>
> [Type denotations]
>
>
>> The C world would have been much better off if the <stdint.h> types
>> had existed from the earliest days, so that everyone used the same
>> name for size-specific types.  Repeating that mistake by having
>> different options in a new language is daft.
>
> Having single-token aliases for the basic types is mild compared with
> what C actually allows:
>
>     int long static unsigned typedef long A;

(Others have pointed out that you can't have "static" and "typedef"
together.)

I'd guess that C allowed flexible ordering here because it made the
grammar easier to describe. But it may also have been because of
existing usage - C was in use long before it was standardised, and maybe
some programmers and/or compilers had fixed on one order, while others
used a different order.

I expect most programmers pretty much ignore the possibilities allowed
here, and stick to very similar orderings. It's really only compiler
writers that have to support them all.

>
>
> BTW in your link, a few languages have aliases for the same type. That
> includes 'int = int32_t' for Objective C.
>

I don't know if that is accurate or not - I am not familiar with
Objective C. (In C, it certainly is not accurate.)

> Under the column 'Word size' (I hadn't scrolled that far before!) under
> C (variable width) it has 'int', which is not correct; on most 64-bit
> platforms, 'int' is not the same size as a word. It also has 'long' as
> 32 bits, which is not always the case.
>

"Word" does not have a fixed definition. But if you think the page is
inaccurate (and I think you are justified in that), you can correct it.

>
>> I do, however, disagree that "int32" is /significantly/ "tidier" or
>> "snappier" than "int32_t".  I really don't think it matters.
>
> There is a pile of things wrong with 'int32_t', 'uint64_t' and so on as
> used in C. I've listed these before. Those types have simply been bolted
> on and are poorly integrated with the rest of the language, with lots of
> aliases across the multitude of types that shouldn't really exist.
>

I know you think that - and again, I think many (but not all) of your
points have some validity. But that's not the issue here. It is /only/
the "_t" that is at issue - nothing else about the types.

> And that _t is just hard to type, with that shifted underscore, I also
> keep doing int_32t instead.
>

I would suggest you get a better keyboard. Underscores are very common
in many programming languages, and in many programmers' choice of
identifiers. Difficulty typing an underscore is a ridiculous argument -
despite being your best argument against the spelling of "int32_t".

>> That was already common in C and POSIX programming.  This was in the
>> days before syntax highlighting, and there were no namespaces, and
>> fewer scopes in C.  When everything goes in one namespace, it is
>> helpful to have some distinguishing features or conventions.
>
> And yet, in every example I've found where people create their own suite
> of fixed-width integers, which you claim is because they predate C99,
> I've yet to see one use a _t suffix.
>

If they were using POSIX, _t suffix names are reserved for the
implementation, OS, system libraries, etc. People shouldn't be using
them themselves for POSIX application code. (It's not a rule people
follow very strictly.)

>> Languages like Ada, Java, D, Scala, Haskell, Eiffel, SQL ?  These are
>> everyday languages - you can easily get a job working with any of these.
>
> Java, D, Scala and Haskell were in my list of 14 languages that had got
> it right. SQL wasn't listed in your link.
>
>> You have yet to provide any evidence to suggest that there is anyone,
>> other than yourself, who would "go so far".
>
> What's the point? You will discard any examples as being just some guy
> on the internet.
>
poster, and, say, a researched and considered blog article. I'm not
looking for very much, but more than you've managed. However, I am also
not expecting you to go to a lot of effort here - you have no
justification or evidence for your claims easily available, so let's
leave it at that.

> So what, do you need, the say-so of a huge corporation?
>
> (A bit like Google backing Go which chose 'int32', and Mozilla backing
> Rust which chose 'i32'. Or Microsoft choosing 'int32' for F#.)
>
>>> Because 1234 in the generated C is a 32-bit int type, but it
>>> represents a 64-bit int type in the original source. It's unwise to
>>> leave it as the wrong type.
>>
>> OK, so you /don't/ need a precisely defined width here, you just think
>> you do.
>
> Why do you think that? I want 1234 and 3000000000 to have a 64-bit type
> so I don't have any surprises when interacting with other terms.
>

There won't be surprises when you know how C constants work. You don't
need casts to avoid surprises.

> In C, 1234 will have type 'int', and 3000000000 will have type 'unsigned
> int', both 32 bits.
>

As others have said, that's wrong.

> You really think my generated C code should leave them unadorned, while
> I just cross my fingers and hope it works?
>

No - I think you should learn how C works, and then you can generate
code that works the way you want. You only feel you need all these
casts because you misunderstand the rules (perhaps deliberately), and
then things don't work the way you thought they did.

>> I wouldn't expect generated C code to contain printf calls like that -
>> printf has a lot of weaknesses, and I would hope the newer language
>> has better formatting facilities.
>
> For a while I relied on sprintf. But my language allows FFI calls to
> functions in 10,000 libraries that may have variadic parameters; this
> can come up.
>

Variadic functions, outside of printf/scanf and friends, are rare. I
think they are a terrible idea and should never have been in the C
language, but that's just my opinion.

> I tell you what: when you write your own C transpiler, you can do what
> you like. Mine will keep in the casts to guarantee my literals have
> exactly the type I expect.
>
>

David Brown <david.brown@hesbynett.no> writes:
> On 03/08/2023 03:07, Bart wrote:
[...]
>> BTW in your link, a few languages have aliases for the same
>> type. That includes 'int = int32_t' for Objective C.
>
> I don't know if that is accurate or not - I am not familiar with
> Objective C. (In C, it certainly is not accurate.)

The link is
https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers

The row for Objective C is actually labeled "Objective-C (Cocoa)", which
may refer to a particular implementation of Objective-C. The
information is likely correct for that implementation.

There apparently is no standard document for Objective-C, but it's
intended to be a strict superset of C (which C++ is not). That would
imply that it must define int and int32_t the same way C does. There
may or may not be any Objective-C implementations where int32_t is not
defined as int, but there certainly could be. (But with Swift intended
to replace Objective-C, I wouldn't expect any new Objective-C
implementations.)

[...]

--
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 03/08/2023 22:42, David Brown wrote:
> On 03/08/2023 03:07, Bart wrote:
> "Word" does not have a fixed definition. But if you think the page is
> inaccurate (and I think you are justified in that), you can correct it.

TBH I would rewrite the whole thing. A lot of the information for
languages I know something about looks wrong, or makes assumptions.

In Ada, what's shown is general range syntax; it doesn't control the
machine types used. I believe there are other features that apply there.

It also includes too many unsuitable languages for a chart which is
supposed to show fixed-width integers.

> There won't be surprises when you know how C constants work. You don't
> need casts to avoid surprises.

As I showed in my other posts, C has quirks. For example, the same value
constant has different types depending on whether it's written as hex or
decimal. (If I'd known that before, I've forgotten.)

But C also allows you to control things with -U or -L suffixes. What are
those for? I achieve the same effects with casts. So if you see:

(int64_t)ddddd

then the int64_t type is guaranteed, whatever the magnitude of 'ddddd'
or the base it uses.

Similarly, all my binary operators uses parentheses to determine
grouping, rather than rely on complex precedence rules. (The algorithm
for deciding whether parentheses are needed is tricky anyway.)

> No - I think you should learn how C works, and then you can generate
> code that works the way you want.

> You only feel you need all these
> casts because you misunderstand the rules (perhaps deliberately),

C has lots of unnecessarily complicated and unintuitive rules for
integer constants, for type denotations, for operator precedences, for
mixed arithmetic ...

I don't agree with them, and don't wish to learn it. Why rely on a bunch
of arcane rules, have lots of complicated logic in the code generater,
and risk making some silly mistake?

Where's the benefit? You've already discounted making the output file
smaller as being a waste of time.

Using casts and using parentheses guarantees the results I expect. Why
do you have such a problem with that?

If you look at my generated code, you will see that every label is
written as 'L:;' with an extra semicolon. Because it was easier to do
that, than predict when a label might be followed by a '}', or a
declaration.

Another stupid limitation of the language; I know /that/ one! But
knowing about it doesn't help.

I mainly write C via machine code generators, and this nonsense just
gets in the way.

Bizarrely, it is easier to translate my language, which has far simpler
rules, into native code than it is to go via C.

On 04/08/2023 00:44, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 03/08/2023 03:07, Bart wrote:
> [...]
>>> BTW in your link, a few languages have aliases for the same
>>> type. That includes 'int = int32_t' for Objective C.
>>
>> I don't know if that is accurate or not - I am not familiar with
>> Objective C. (In C, it certainly is not accurate.)
>
> The link is
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>
> The row for Objective C is actually labeled "Objective-C (Cocoa)", which
> may refer to a particular implementation of Objective-C. The
> information is likely correct for that implementation.
>
> There apparently is no standard document for Objective-C, but it's
> intended to be a strict superset of C (which C++ is not). That would
> imply that it must define int and int32_t the same way C does. There
> may or may not be any Objective-C implementations where int32_t is not
> defined as int, but there certainly could be. (But with Swift intended
> to replace Objective-C, I wouldn't expect any new Objective-C
> implementations.)
>
> [...]
>

Sounds reasonable.

I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not
"int". (I don't know why, and I am curious if anyone else does - 32-bit
ARM is far and away the most popular architecture for embedded devices,
in terms of the number of developers and projects, so it is an important
target system.)

On 2023-08-04, David Brown <david.brown@hesbynett.no> wrote:
> On 04/08/2023 00:44, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 03/08/2023 03:07, Bart wrote:
>> [...]
>>>> BTW in your link, a few languages have aliases for the same
>>>> type. That includes 'int = int32_t' for Objective C.
>>>
>>> I don't know if that is accurate or not - I am not familiar with
>>> Objective C. (In C, it certainly is not accurate.)
>>
>> The link is
>> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>>
>> The row for Objective C is actually labeled "Objective-C (Cocoa)", which
>> may refer to a particular implementation of Objective-C. The
>> information is likely correct for that implementation.
>>
>> There apparently is no standard document for Objective-C, but it's
>> intended to be a strict superset of C (which C++ is not). That would
>> imply that it must define int and int32_t the same way C does. There
>> may or may not be any Objective-C implementations where int32_t is not
>> defined as int, but there certainly could be. (But with Swift intended
>> to replace Objective-C, I wouldn't expect any new Objective-C
>> implementations.)
>>
>> [...]
>>
>
> Sounds reasonable.
>
> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not
> "int". (I don't know why, and I am curious if anyone else does - 32-bit
> ARM is far and away the most popular architecture for embedded devices,
> in terms of the number of developers and projects, so it is an important
> target system.)

One implication is that pointers to int32_t and int are incompatible.

Then, if on a 64 bit platform int32_t is a typedef for int, pointers to
long and and int32_t are incompatible. (Possibly necessarily so if long
is 64 bits.)

When code is compiled for both targets, that will flush out situations
where code is assuming either of those bogus compatibilities.

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

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

[some whitespace editing done to avoid long lines]

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> Take this code
>
> Is this obviously not real code. That does not normally matter,
> but I think you've ended up with something that can't illustrate
> the problem you have in mind.
>
>> void filter(
>> float *out, const float *in, size_t N,
>> const float *filter, size_t Nf
>> ){
>> mysterytype_t index;
>> size_t i, j;
>>
>> for ( i =0; i < N; i=i++)
>
> The assignment to i is UB. Looks like a typo for either i=i+1 or
> i++.
>
>> {
>> out[i] = 0.0f;
>> for(j = 0, index = i - Nf/2; j < Nf; j++, index++)
>> {
>> if (index < 0 || index >= N)
>
> Here, it looks like index is supposed to be a signed type, but it
> gets assigned a value with (probable) unsigned type (i - Nf/2) and
> is only ever incremented.
>
>> contiue;
>
> typo
>
>> out[index] += in[i] * filter[j];
>> }
>> }
>> }
>>
>> What would you use for mysterytype_t?
>
> As the code stands (with the typos corrected) an unsigned type
> like size_t would work, but I don't think that's what you were
> asking. Something is wrong in the rest of the code.

I'm happy to see you gave a followup for this code. I was
hoping you would.

It looks like the code is trying (and failing) to perform a
convolution. It isn't hard to code a convolve function using
only unsigned index types, and the resulting code is simpler
than if signed types were used (because the range tests can
be folded into a single comparison). Something along these
lines:

typedef unsigned long Index;

void
convolve(
float *out, const float *in, Index N, const float *filter, Index Nf
){
Index i, j;

for( i = 0; i < N; i++ ){
float t = 0;
for( j = 0; j < Nf; j++ ){
Index k = i + j - Nf/2;
if( k >= N ) continue;
t += in[k] * filter[j];
}
out[i] = t;
}
}

On Thursday, 3 August 2023 at 10:42:53 UTC+1, David Brown wrote:
> On 03/08/2023 00:25, Malcolm McLean wrote:
> > On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote:
> >> On 02/08/2023 18:10, Malcolm McLean wrote:
> >>> On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>
> >>>>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
> >>>>>> On 02/08/2023 11:41, Malcolm McLean wrote:
> >>>>
> >>>>>>> Then there's exotica such as int_fast32 _t. Which is often what you
> >>>>>>> really want, but you seldom see it in real code.
> >>>>> I don't use any of them in the Baby X resource compiler. Audio samples
> >>>>> are saved as "short", UTF-16 values as "unsigned short". If short
> >>>>> isn't 16 bits, it might or might not work, but the chances it will
> >>>>> work are good. If I used int16_t, it would break if short isn't 16
> >>>>> bits.
> >>>> int16_t "breaks" if there is no such type, but I think such a type can
> >>>> exist even if short is not 16 bits.
> >>>>
> >>> CHAR_BIT would have to be sixteen.
> >> No, compilers can have extended integer types.
> >>>>> And it would break if stdint.h isn't available. So that was an easy
> >>>>> decision to make.
> >>>> That rules out the type you probably want -- one of the types you say is
> >>>> often what is really wanted (int_least16_t). No wonder they are rarely
> >>>> seen in "real code" if people won't use them even after nearly a quarter
> >>>> of a century. Are you really limiting yourself to writing C90?
> >>>>
> >>> It's best to restrict yourself to the conservative subset of C unless there is
> >>> really a pressing reason to do otherwise.
> >> Utter drivel.
> >>
> >> It's best to use the C version, and subset thereof, that is suitable for
> >> writing good, clean code that gives efficient results and is likely to
> >> work fine for all platforms for which the code is realistically going to
> >> be of interest. That pretty much /never/ means C90. All you do by
> >> choosing C90 is give worse quality source code, poorer efficiency in the
> >> generated code, and home-made half-arsed solutions for problems that
> >> were solved 25 years ago.
> >>
> > Efficiency in the resource compiler itself hardly matters. I tested the string
> > tag on a 100,000 word novel, and it came back instantly. The string also
> > compiled and printed out. Efficiency in the output code matters, but the vast
> > majority of it is static data.
> Quality of source code /always/ matters, unless this is a small
> throw-away program.
>
Quality matters. Efficiency often doesn't. For example I just encoded a function
to "make comment". This takes a string, checks if it already has enclosing
comment tags, if not adds them, then changes every internal closing comment
tag into "^/" instead of "*/" (what can you do?). It duplicates the string twice.
Of course it would be possible to add four bytes when loading the raw comment
data, and never duplicate the string at all. But that would complicate the program
condiderably, an dunless the user wants a comment several gigabytes long, on
a modern machine it will make not difference at all to execution time.
> >>> The Baby X resource compiler
> >>> is designed for use with Baby X, but it might also find a niche in the
> >>> toolchains of people writing for small embedded systems. Which
> >>> might come with old or restricted C compilers.
> >>>
> >> It will /never/ happen. So don't worry about it.
> >>
> >> And if you were /really/ interested in obscure and outdated embedded
> >> tools (and some of these are still in use), you might have tried to
> >> learn a little about them - or ask someone who knows. They'd have
> >> explained the difference between compilers for code running on the
> >> target devices, and compilers for code running on host systems.
> >>
> > The Baby X resource compiler, as the name implies, is primarily intended
> > for use with Baby X. Baby X uses int to represent integral values,
> > double to represent real values, unsigned char to represent arbitrary
> > binary data, and char * to represent strings. There's no advantage in
> > using other types, except that now I'm adding audio, the PCM data will
> > be represented by a short.
> >
> None of this will ever be of the slightest use on a platform that does
> not have a good C99 compiler.
>
There's a value in cutting down the number of types the Baby X API uses.
So we don't want some functions which take an integer taking :int", and
others "size_t" and others "uint32_t" unless of course there's a pressing
need for it. Which there is in a case of audio samples. Traditionally these are
16 bit, so I will use "short" for audio samples when audio is integrated into
Baby X. But that's the only case where there is a pressing need for the API
to take an integer type other than "int". (The other exception is BBX_RGBA
which represents 24-bit color values, that's typedefed so the underlying
type is opaque).
>
> > However I took the decision to separate the resource compiler from Baby X
> > so it could be used as an independent program by non-Baby X users.
> > Who those would be I don't know. The big platforms come with monolithic
> > buold systems which include resource compilers, and for various reasons
> > it's not easy to avoid the use of the resource compiler. So I'm guessing
> > small embedded systems. But I can't exactly take a job doing embedded
> > programming just to get more experience for building the resource
> > compiler. The output files from the Baby X resource compiler should
> > compile under pretty much any C compiler out there, however.
> >
> Don't base important design decisions on random guesses about things you
> are completely ignorant about. (Ignorance itself is not a problem -
> none of us know about all kinds of programming situations. It's basing
> decisions on ignorance that is the problem.)
>
> If you are running a shoe shop, you keep all your stock in pairs. You
> don't keep them in singles just in case one customer is missing a leg.
>
The Baby X resource compiler was developed was an anciliary program
to Baby X. Just as Windows compilers come with a "resource compiler"
which allow you to package images and other binaries, there's a need
for a program which does a similar thing for Baby X. However in the
event, the resource compiler is more popular than Baby X itself.
It can be used by non-Baby X programmers. But who those would be and
why they would wanrt it is a good question.
>
> > The Baby X resource compiler itself should also compile cleanly and easily
> > under any hosted system. That's also an important goal.
> >
> That is a completely pointless attitude.
>
> First, is there any indication that anyone has actually used the
> program? Does anyone who wants to use it, want to compile it? When I
> am looking for software, if I find a possible option and see it is
> written in ANSI C90, I assume it is some ancient and outdated tool. It
> /might/ still be useful, but I start with a big negative bias. (I am
> also biased against fad languages or obscure ones.)
>
There's regular traffic. Not huge. But obviously some people are
interested. The problem is that you don't get much feedback. Whether
these people are just aking the "loadimage" function for their own use,
(which I don't mind), or using the resource compiler itself, I don't know,
because they don't tell me.
>
> In reality, people are only ever going to use a "resource compiler" on
> two platforms - modern Linux, and modern Windows. And practically
> everyone who wants to use it would want a binary, not the source code
> (though having the source code available is also good). ".exe" format
> is more important to users than ANSI C format.
>
The users will be C programmers. But I took your advice and made a Windows
executable available. One download so far.

David Brown <david.brown@hesbynett.no> writes:
>On 04/08/2023 00:44, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 03/08/2023 03:07, Bart wrote:
>> [...]
>>>> BTW in your link, a few languages have aliases for the same
>>>> type. That includes 'int = int32_t' for Objective C.
>>>
>>> I don't know if that is accurate or not - I am not familiar with
>>> Objective C. (In C, it certainly is not accurate.)
>>
>> The link is
>> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>>
>> The row for Objective C is actually labeled "Objective-C (Cocoa)", which
>> may refer to a particular implementation of Objective-C. The
>> information is likely correct for that implementation.
>>
>> There apparently is no standard document for Objective-C, but it's
>> intended to be a strict superset of C (which C++ is not). That would
>> imply that it must define int and int32_t the same way C does. There
>> may or may not be any Objective-C implementations where int32_t is not
>> defined as int, but there certainly could be. (But with Swift intended
>> to replace Objective-C, I wouldn't expect any new Objective-C
>> implementations.)
>>
>> [...]
>>
>
>Sounds reasonable.
>
>I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not
>"int". (I don't know why, and I am curious if anyone else does - 32-bit
>ARM is far and away the most popular architecture for embedded devices,
>in terms of the number of developers and projects, so it is an important
>target system.)

It depends on how the platform ABI defines long.

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h:

#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ __int32_t;
#ifdef __UINT32_TYPE__
typedef __UINT32_TYPE__ __uint32_t;
#else
typedef unsigned __INT32_TYPE__ __uint32_t;
#endif
#define ___int32_t_defined 1
#elif __EXP(INT_MAX) == 0x7fffffffL
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
#define ___int32_t_defined 1
#elif __EXP(LONG_MAX) == 0x7fffffffL
typedef signed long __int32_t;
typedef unsigned long __uint32_t;
#define ___int32_t_defined 1
#elif __EXP(SHRT_MAX) == 0x7fffffffL
typedef signed short __int32_t;
typedef unsigned short __uint32_t;
#define ___int32_t_defined 1
#elif __EXP(SCHAR_MAX) == 0x7fffffffL
typedef signed char __int32_t;
typedef unsigned char __uint32_t;
#define ___int32_t_defined 1
#endif

>
>

On Thu, 3 Aug 2023 11:42:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
> When I
> am looking for software, if I find a possible option and see it is
> written in ANSI C90, I assume it is some ancient and outdated tool. It
> /might/ still be useful, but I start with a big negative bias.

That's a strange attitude. If it is written in "old" C then likely it
was written a long time ago but it certainly doesn't follow that it is
outdated. The venerable less pager is very much standard on Unix
systems and it doesn't even use function prototypes (at least it didn't
a few revisions ago , I haven't looked at the source code of the latest
versions). I can think of a few more likely examples but I haven't
looked at their source. Basically , if it works then hardly anyone will
make it a priority to modify it for a newer version of C.

--
Virtue, I discovered, in one way in which a human being may attempt to
diminish and insult others.
"Captive of Gor"

On 04/08/2023 14:56, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 04/08/2023 00:44, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 03/08/2023 03:07, Bart wrote:
>>> [...]
>>>>> BTW in your link, a few languages have aliases for the same
>>>>> type. That includes 'int = int32_t' for Objective C.
>>>>
>>>> I don't know if that is accurate or not - I am not familiar with
>>>> Objective C. (In C, it certainly is not accurate.)
>>>
>>> The link is
>>>
https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>>>
>>> The row for Objective C is actually labeled "Objective-C (Cocoa)",
which
>>> may refer to a particular implementation of Objective-C. The
>>> information is likely correct for that implementation.
>>>
>>> There apparently is no standard document for Objective-C, but it's
>>> intended to be a strict superset of C (which C++ is not). That would
>>> imply that it must define int and int32_t the same way C does. There
>>> may or may not be any Objective-C implementations where int32_t is not
>>> defined as int, but there certainly could be. (But with Swift intended
>>> to replace Objective-C, I wouldn't expect any new Objective-C
>>> implementations.)
>>>
>>> [...]
>>>
>>
>> Sounds reasonable.
>>
>> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not
>> "int". (I don't know why, and I am curious if anyone else does - 32-bit
>> ARM is far and away the most popular architecture for embedded devices,
>> in terms of the number of developers and projects, so it is an important
>> target system.)
>
> It depends on how the platform ABI defines long.
>
>
arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h:
>
> #ifdef __INT32_TYPE__
> typedef __INT32_TYPE__ __int32_t;
> #ifdef __UINT32_TYPE__
> typedef __UINT32_TYPE__ __uint32_t;
> #else
> typedef unsigned __INT32_TYPE__ __uint32_t;
> #endif
> #define ___int32_t_defined 1
> #elif __EXP(INT_MAX) == 0x7fffffffL
> typedef signed int __int32_t;
> typedef unsigned int __uint32_t;
> #define ___int32_t_defined 1
> #elif __EXP(LONG_MAX) == 0x7fffffffL
> typedef signed long __int32_t;
> typedef unsigned long __uint32_t;
> #define ___int32_t_defined 1
> #elif __EXP(SHRT_MAX) == 0x7fffffffL
> typedef signed short __int32_t;
> typedef unsigned short __uint32_t;
> #define ___int32_t_defined 1
> #elif __EXP(SCHAR_MAX) == 0x7fffffffL
> typedef signed char __int32_t;
> typedef unsigned char __uint32_t;
> #define ___int32_t_defined 1
> #endif

This is part of an implementation for, what, a compiler? You'd think a
compiler would know the sizes of its types!

Otherwise why is this code defining __int32_t? This is not even int32_t,
what will that __int32_t be used for, surely not int32_t at some later
point, and within what program?

It seems that this piece of code wants to define "__int32_t", but
doesn't know which standard type the underlying C compiler uses that
happens to be 32 bits. (It also looks like it will fail if there is no
such type.)

What's that __INT32_TYPE__ all about? Decades on since C99 and still
there are myriad aliases for such types lurking everywhere.

I've never seen so palaver defining a simple type.

On 04/08/2023 16:20, Spiros Bousbouras wrote:
> On Thu, 3 Aug 2023 11:42:36 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> When I
>> am looking for software, if I find a possible option and see it is
>> written in ANSI C90, I assume it is some ancient and outdated tool. It
>> /might/ still be useful, but I start with a big negative bias.
>
> That's a strange attitude. If it is written in "old" C then likely it
> was written a long time ago but it certainly doesn't follow that it is
> outdated.

True, of course. For some things, old software is just as good as new
software - if the task hasn't changed, the software does not need to
change. But for other kinds of software you want to be sure that it is
relatively modern, or at least well maintained. That might be for
supporting newer formats (in the case of a "resource compiler"), or
perhaps it is software for which security is a concern. The software
might also be written for older and weaker compilers - using "tricks"
that were popular before, but are undefined behaviour in C and can fail
with modern compilers. Being in an ancient C dialect does not guarantee
that it is outdated, but it is a pointer in that direction.

I would also have no interest in a "resource compiler" that generated C
files that did not use <stdint.h> or <stdbool.h> types when appropriate,
but perpetuated the inconvenience of home-made types.

On 04/08/2023 09:14, Kaz Kylheku wrote:
> On 2023-08-04, David Brown <david.brown@hesbynett.no> wrote:
>> On 04/08/2023 00:44, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 03/08/2023 03:07, Bart wrote:
>>> [...]
>>>>> BTW in your link, a few languages have aliases for the same
>>>>> type. That includes 'int = int32_t' for Objective C.
>>>>
>>>> I don't know if that is accurate or not - I am not familiar with
>>>> Objective C. (In C, it certainly is not accurate.)
>>>
>>> The link is
>>> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>>>
>>> The row for Objective C is actually labeled "Objective-C (Cocoa)", which
>>> may refer to a particular implementation of Objective-C. The
>>> information is likely correct for that implementation.
>>>
>>> There apparently is no standard document for Objective-C, but it's
>>> intended to be a strict superset of C (which C++ is not). That would
>>> imply that it must define int and int32_t the same way C does. There
>>> may or may not be any Objective-C implementations where int32_t is not
>>> defined as int, but there certainly could be. (But with Swift intended
>>> to replace Objective-C, I wouldn't expect any new Objective-C
>>> implementations.)
>>>
>>> [...]
>>>
>>
>> Sounds reasonable.
>>
>> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not
>> "int". (I don't know why, and I am curious if anyone else does - 32-bit
>> ARM is far and away the most popular architecture for embedded devices,
>> in terms of the number of developers and projects, so it is an important
>> target system.)
>
> One implication is that pointers to int32_t and int are incompatible.

Yes - that is the most important effect.

>
> Then, if on a 64 bit platform int32_t is a typedef for int, pointers to
> long and and int32_t are incompatible. (Possibly necessarily so if long
> is 64 bits.)
>
> When code is compiled for both targets, that will flush out situations
> where code is assuming either of those bogus compatibilities.
>

On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
> On 04/08/2023 16:20, Spiros Bousbouras wrote:
> > On Thu, 3 Aug 2023 11:42:36 +0200
> > David Brown <david...@hesbynett.no> wrote:
> >> When I
> >> am looking for software, if I find a possible option and see it is
> >> written in ANSI C90, I assume it is some ancient and outdated tool. It
> >> /might/ still be useful, but I start with a big negative bias.
> >
> > That's a strange attitude. If it is written in "old" C then likely it
> > was written a long time ago but it certainly doesn't follow that it is
> > outdated.
> True, of course. For some things, old software is just as good as new
> software - if the task hasn't changed, the software does not need to
> change. But for other kinds of software you want to be sure that it is
> relatively modern, or at least well maintained. That might be for
> supporting newer formats (in the case of a "resource compiler"), or
> perhaps it is software for which security is a concern. The software
> might also be written for older and weaker compilers - using "tricks"
> that were popular before, but are undefined behaviour in C and can fail
> with modern compilers. Being in an ancient C dialect does not guarantee
> that it is outdated, but it is a pointer in that direction.
>
> I would also have no interest in a "resource compiler" that generated C
> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
> but perpetuated the inconvenience of home-made types.
>
It doesn't output homemade types like "u8" for a char. But it doesn't use
<stdint.h> or <stdbool.h> types either. It outputs the basic C types.

That's because it was orignally designed for use with Baby X, which
doesn't use <stdint.h" or <stdbool.h> types in its API interface.
But I could add a flag to the resource compiler to output <stdint.h>
known width types if people think that that's important.

On 04/08/2023 17:20, Malcolm McLean wrote:
> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
>> On 04/08/2023 16:20, Spiros Bousbouras wrote:
>>> On Thu, 3 Aug 2023 11:42:36 +0200
>>> David Brown <david...@hesbynett.no> wrote:
>>>> When I
>>>> am looking for software, if I find a possible option and see it is
>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It
>>>> /might/ still be useful, but I start with a big negative bias.
>>>
>>> That's a strange attitude. If it is written in "old" C then likely it
>>> was written a long time ago but it certainly doesn't follow that it is
>>> outdated.
>> True, of course. For some things, old software is just as good as new
>> software - if the task hasn't changed, the software does not need to
>> change. But for other kinds of software you want to be sure that it is
>> relatively modern, or at least well maintained. That might be for
>> supporting newer formats (in the case of a "resource compiler"), or
>> perhaps it is software for which security is a concern. The software
>> might also be written for older and weaker compilers - using "tricks"
>> that were popular before, but are undefined behaviour in C and can fail
>> with modern compilers. Being in an ancient C dialect does not guarantee
>> that it is outdated, but it is a pointer in that direction.
>>
>> I would also have no interest in a "resource compiler" that generated C
>> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
>> but perpetuated the inconvenience of home-made types.
>>
> It doesn't output homemade types like "u8" for a char. But it doesn't use
> <stdint.h> or <stdbool.h> types either. It outputs the basic C types.

That would be useless. Few people doing embedded work have any interest
in something that turns resources (such as files to be embedded) into
arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or
whatever matches the resource type.

This can be done in a dozen lines of Python scripting, and I get exactly
what I need. I do so regularly for embedded bitmaps, or static files
for an embedded webserver, and that kind of thing.

>
> That's because it was orignally designed for use with Baby X, which
> doesn't use <stdint.h" or <stdbool.h> types in its API interface.
> But I could add a flag to the resource compiler to output <stdint.h>
> known width types if people think that that's important.
>

I think it is. But I doubt if it will be a big hit with embedded
programmers anyway.

On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote:
> On 04/08/2023 17:20, Malcolm McLean wrote:
> > On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
> >> On 04/08/2023 16:20, Spiros Bousbouras wrote:
> >>> On Thu, 3 Aug 2023 11:42:36 +0200
> >>> David Brown <david...@hesbynett.no> wrote:
> >>>> When I
> >>>> am looking for software, if I find a possible option and see it is
> >>>> written in ANSI C90, I assume it is some ancient and outdated tool. It
> >>>> /might/ still be useful, but I start with a big negative bias.
> >>>
> >>> That's a strange attitude. If it is written in "old" C then likely it
> >>> was written a long time ago but it certainly doesn't follow that it is
> >>> outdated.
> >> True, of course. For some things, old software is just as good as new
> >> software - if the task hasn't changed, the software does not need to
> >> change. But for other kinds of software you want to be sure that it is
> >> relatively modern, or at least well maintained. That might be for
> >> supporting newer formats (in the case of a "resource compiler"), or
> >> perhaps it is software for which security is a concern. The software
> >> might also be written for older and weaker compilers - using "tricks"
> >> that were popular before, but are undefined behaviour in C and can fail
> >> with modern compilers. Being in an ancient C dialect does not guarantee
> >> that it is outdated, but it is a pointer in that direction.
> >>
> >> I would also have no interest in a "resource compiler" that generated C
> >> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
> >> but perpetuated the inconvenience of home-made types.
> >>
> > It doesn't output homemade types like "u8" for a char. But it doesn't use
> > <stdint.h> or <stdbool.h> types either. It outputs the basic C types.
> That would be useless. Few people doing embedded work have any interest
> in something that turns resources (such as files to be embedded) into
> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or
> whatever matches the resource type.
>
> This can be done in a dozen lines of Python scripting, and I get exactly
> what I need. I do so regularly for embedded bitmaps, or static files
> for an embedded webserver, and that kind of thing.
>
Yes, pretty much every C programmer has written a scratch program
to read in a binary and output C source. I can't find a tool that allows you
to get away from that, except the Baby X resource compiler. Whether that
is bad thing, meaning there's no demand for such a tool, or a good thing,
meaning it has a niche no-one else has thought of, I don't know.
> >
> > That's because it was orignally designed for use with Baby X, which
> > doesn't use <stdint.h" or <stdbool.h> types in its API interface.
> > But I could add a flag to the resource compiler to output <stdint.h>
> > known width types if people think that that's important.
> >
> I think it is. But I doubt if it will be a big hit with embedded
> programmers anyway.
>
There's no reason for any of the data to be fixed size that I can think of.
But what do I know.

On 02/08/2023 16:58, David Brown wrote:
> I don't believe I have written many real C programs in which the name of
> the final executable matched the name of any of the C files that went
> into it.  Having "gcc prog.c" result in "prog" (or "prog.exe" for
> Windows) is as useless to me as having it result in "a.out".  Other
> people will have different ideas and needs - but that's the real point.
> gcc is made for lots of people, and cannot possibly suit everyone with
> its defaults.  Just because one person, such as yourself, imagines that
> their preferences are somehow near universal, does not make them so.

Way back in time I have. We had a number of utilities which consisted of
a single source file that compiled into a single binary. This was for
8086 class systems, so with a megabyte of RAM.

(sorry, the rest is too long)

Andy

On 03/08/2023 22:42, David Brown wrote:
> On 03/08/2023 03:07, Bart wrote:
>> What's the point? You will discard any examples as being just some guy
>> on the internet.
>>
> poster, and, say, a researched and considered blog article. I'm not
> looking for very much, but more than you've managed. However, I am also
> not expecting you to go to a lot of effort here - you have no
> justification or evidence for your claims easily available, so let's
> leave it at that.

What are my claims?

I'm saying lots of people do this, create new aliases that are more
appealing than what C provides. I've seen open source code that does it
(but I don't keep a record of every single site), I've seen people
talking about doing it on forurms, and talking about seeing others do
it, for example:

"I also see "uint8" on a regular basis. I also understand this to be an
unsigned 8 bit structure. Basically, it is a "byte". Again, why not use
a "byte"?"

This is in an Arduino forum. I didn't quite understand the remark about
'byte', but later in the thread:

"...I believe it is. Funnily enough it is defined (in Arduino.h) as:
typedef uint8_t byte;"

Sure enough here it is
(https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/Arduino.h):

typedef uint8_t byte;

You would not approve of course. Here is a tutorial:

https://www.tutorialspoint.com/cprogramming/c_typedef.htm

which shows typedef used to define BYTE an an alias for 'unsigned char'.

Although not mentioned, it is clear to me that BYTE is perceived as a
dandier type denotation for an 8-bit unsigned type than 'unsigned char'.
Why however didn't they choose 'uint8_t' instead; it's a mystery!

Here's another tutorial
(https://piratelearner.com/en/C/course/computer-science/c-programming/typedef-your-data-types/47/),
where it creates (scroll down) aliases with names like 'uint8' and
'int32'. Notice no '_t' prefixes.

That link is 7 years old and actually, if you scroll further, it defines
'int32' on top of 'int32_t'. Even where stdint.h is missing as it
suggests, someone could have chosen to define their own 'int32_t', but
chose 'int32'. Another mystery!

Here's a quote from a stack exchange question asking about why it is
'int32_t' and not 'int32':

"At the time the C99 Standard was ratified, there already existed
countless C programs that used int32 as an identifier. "

Note the word 'countless'. You asserted that _t was commonly by people
who had to make their own fixed-width typedefs. I've seen little
evidence of that.

This one is interesting: https://dox.ipxe.org/include_2stdint_8h_source.html

It defines a bunch of aliases for the stdint.h types, such as both 's32'
and 'int32' for 'int32_t'. It's a little unusual in using 's32' rather
than 'i32', although when you think about it, 's' for 'signed' makes sense.

(I don't do that because all my 'int' types are signed.)

Why these aliases? You tell me, since you just WILL NOT BELIEVE THAT
PEOPLE MIGHT PREFER them, so there must be another reason, right?

Basically, everybody is at it, because nobody is in love with what C
provides: the choice is between 'unsigned char', and '#include
<stdint.h> uint8_t', and both stink.

On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>
> Basically, everybody is at it, because nobody is in love with what C
> provides: the choice is between 'unsigned char', and '#include
> <stdint.h> uint8_t', and both stink.
>
There should be a keyword "byte". unsigned chars should not be character
data, so "char" is a misnomer. And uint8_t means that the data has to be
exactly 8 bits. Which is only the case if the program is using overflow as
a free modulus 256 operation. Which almost always is poor programming.
So it's hard to see where it has any place at all.

On 04/08/2023 18:00, Vir Campestris wrote:
> On 02/08/2023 16:58, David Brown wrote:
>> I don't believe I have written many real C programs in which the name
>> of the final executable matched the name of any of the C files that
>> went into it. Having "gcc prog.c" result in "prog" (or "prog.exe" for
>> Windows) is as useless to me as having it result in "a.out". Other
>> people will have different ideas and needs - but that's the real
>> point. gcc is made for lots of people, and cannot possibly suit
>> everyone with its defaults. Just because one person, such as
>> yourself, imagines that their preferences are somehow near universal,
>> does not make them so.
>
> Way back in time I have. We had a number of utilities which consisted of
> a single source file that compiled into a single binary. This was for
> 8086 class systems, so with a megabyte of RAM.

I'm sure you don't need to go that far back in time. I have loads of
smallish programs lying around that are a single module (eg. lisp.c,
minibasic.c, nano.c [a jpeg decoder]).

There are libraries (eg. bignum.c) and dozens of single file benchmarks.
Most challenges that have been done in this newsgroup will have suited a
single source file.

David Brown I'm sure has never even compiled 'hello.c'. Or maybe he
doesn't count single-module programs as 'real'. (Maybe he's one of those
who likes to put each function into a dedicated file.)

I used to distribute my programs as generated C, always comprising a
single source file, and requiring only a bare C compiler to build. So it
would have been nice if the instructions to build and run were something
like:

gcc prog.c
prog

Besides, with pretty much every other language with a command-line build
process, if you submit a single source file 'fred.lang', it will produce
a matching executable 'fred.exe` without needing to be told how.

On 2023-08-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> typedef unsigned long Index;
>
> void
> convolve(
> float *out, const float *in, Index N, const float *filter, Index Nf
> ){
> Index i, j;
>
> for( i = 0; i < N; i++ ){
> float t = 0;
> for( j = 0; j < Nf; j++ ){
> Index k = i + j - Nf/2;
> if( k >= N ) continue;
> t += in[k] * filter[j];
> }
> out[i] = t;
> }
> }

This looks like a (cross-)correlation, unless filter[] is assumed to be
prepared backwards; i.e. i and j are values map to the same domain (such
as time) where increasing values of j correspond to decreasing domain
values.

(Or it doesn't matter for some other reason, like filter[] being
a palindrome.)

On Friday, 4 August 2023 at 19:29:32 UTC+1, Kaz Kylheku wrote:
> On 2023-08-04, Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> > typedef unsigned long Index;
> >
> > void
> > convolve(
> > float *out, const float *in, Index N, const float *filter, Index Nf
> > ){
> > Index i, j;
> >
> > for( i = 0; i < N; i++ ){
> > float t = 0;
> > for( j = 0; j < Nf; j++ ){
> > Index k = i + j - Nf/2;
> > if( k >= N ) continue;
> > t += in[k] * filter[j];
> > }
> > out[i] = t;
> > }
> > }
> This looks like a (cross-)correlation, unless filter[] is assumed to be
> prepared backwards; i.e. i and j are values map to the same domain (such
> as time) where increasing values of j correspond to decreasing domain
> values.
>
> (Or it doesn't matter for some other reason, like filter[] being
> a palindrome.)
>
It gets very headachy because unless the sizes are very small, you usually
have to implement it in the frequency domain. Which has its own logic.

But naively, "filter" would take a signal and a filter going in the same direction.

On 04/08/2023 18:32, Malcolm McLean wrote:
> On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>>
>> Basically, everybody is at it, because nobody is in love with what C
>> provides: the choice is between 'unsigned char', and '#include
>> <stdint.h> uint8_t', and both stink.
>>
> There should be a keyword "byte". unsigned chars should not be character
> data, so "char" is a misnomer. And uint8_t means that the data has to be
> exactly 8 bits. Which is only the case if the program is using
overflow as
> a free modulus 256 operation. Which almost always is poor programming.
> So it's hard to see where it has any place at all.

Sorry, I can't make sense of that.

Are you saying there is a place for 'byte' or not? And as a keyword, or
a built-in type?

Clearly, 'uint8_t' is the type for an 8-bit unsigned value, obviously,
it will be 8 bits, that's the whole point! Since pretty much all
hardware will have 8-bit bytes and be byte-addressable, and it is what
UTF8 for example expects.

>Which is only the case if the program is using overflow as a free
modulus 256 operation.

You've lost me.

In C, you would tend to use 'signed or unsigned char' for small
integers, and plain 'char' where the values represent text. Partly
because the unspecified signedness of plain char causes problems.

Of course, sometimes you want to do calculations with character values,
or use them for indexing, then using plain char is fraught with danger.
But you can't just forget 'plain char', as strings use it, and is in
countless APIs.

C /should/ have had only 2 'char' types, signed and unsigned, with
strings being sequences of the 'unsigned' version.

Then, 'byte' could have been the name of the unsigned type (although
some languages use it for a signed version).

Nobody would care about module-256 wraparound, which anyway only happens
if you put a result back into a byte location.

On Friday, 4 August 2023 at 19:37:06 UTC+1, Bart wrote:
> On 04/08/2023 18:32, Malcolm McLean wrote:
> > On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
> >>
> >> Basically, everybody is at it, because nobody is in love with what C
> >> provides: the choice is between 'unsigned char', and '#include
> >> <stdint.h> uint8_t', and both stink.
> >>
> > There should be a keyword "byte". unsigned chars should not be character
> > data, so "char" is a misnomer. And uint8_t means that the data has to be
> > exactly 8 bits. Which is only the case if the program is using
> overflow as
> > a free modulus 256 operation. Which almost always is poor programming.
> > So it's hard to see where it has any place at all.
> Sorry, I can't make sense of that.
>
> Are you saying there is a place for 'byte' or not? And as a keyword, or
> a built-in type?
>
There's place for "byte". It could be either a keyword or it could be a typedef
for "unsigned char". The latter would be eaiser to implement but would mean
that any source file using it would have a dependency.
>
> Clearly, 'uint8_t' is the type for an 8-bit unsigned value, obviously,
> it will be 8 bits, that's the whole point! Since pretty much all
> hardware will have 8-bit bytes and be byte-addressable, and it is what
> UTF8 for example expects.
> >Which is only the case if the program is using overflow as a free
> modulus 256 operation.
> You've lost me.
>
If CHAR_BIT is greater than eight, then programs expecting data as
unsigned chars should still work, unless the programmer has elected
to use overflow as a free modulus 256 operation. (Of course you can
pass invalid data to the function if CHAR_BIT is over eight, which you
often can't if it is exactly eight. However almost every function allows
you to pass some bad values.)
Now it is very unlikely with current technology that a general-purpose
routine will ever have to tun on a platform where CHAR_BIT is not eight.
But why gratuitiously break things if it is larger? It doesn't make any
sort of sense.
>
> In C, you would tend to use 'signed or unsigned char' for small
> integers, and plain 'char' where the values represent text. Partly
> because the unspecified signedness of plain char causes problems.
>
> Of course, sometimes you want to do calculations with character values,
> or use them for indexing, then using plain char is fraught with danger.
> But you can't just forget 'plain char', as strings use it, and is in
> countless APIs.
>
> C /should/ have had only 2 'char' types, signed and unsigned, with
> strings being sequences of the 'unsigned' version.
>
The problem is that char is nearly but not quite an opaque type.
You do need to treat chars as small integers to implement functions
such as "itoa" effiiciently.
>
> Then, 'byte' could have been the name of the unsigned type (although
> some languages use it for a signed version).
>
> Nobody would care about module-256 wraparound, which anyway only happens
> if you put a result back into a byte location.
>
Yes, unsigned char shold be "byte". It's not holding character data. Character
data should be "char". A tiny signed integer, I'm not sure. You do occasionally
need these. But it's not a byte and it's not a character, and it's not necessarily
8 bits.