On Sunday, 6 August 2023 at 13:53:05 UTC+1, Spiros Bousbouras wrote:
> On Sun, 6 Aug 2023 04:36:47 -0700 (PDT)
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > The a basic problem was that I am using a MP3 decoder written by someone else.
> > They wrote a file called clib.h which has various efficiency and portability hacks.
> > It includes this
> >
> > #if !NEED_MINILIBC
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #endif
> > #include <math.h>
> >
> > #ifndef __int8_t_defined
> > #define __int8_t_defined
> > typedef unsigned char uint8_t;
> > typedef signed char int8_t;
> > typedef unsigned short uint16_t;
> > typedef signed short int16_t;
> > typedef unsigned int uint32_t;
> > typedef signed int int32_t;
> > #ifdef _MSC_VER
> > typedef unsigned __int64 uint64_t;
> > typedef signed __int64 int64_t;
> > #else
> > typedef unsigned long long uint64_t;
> > typedef signed long long int64_t;
> > #endif
> > #endif
> >
> > Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> > So this breaks when compiled on Linux. By trying to be portable, they
> > managed to produce something which wasn't portable.
> >
> > It really confirms my view that it's best to write in a conservative subset
> > of C90 and the subsequent standards. otherwise you just get endless
> > trouble.
> My view is that it's best not to use code which has so many issues unless you
> fix them first. First , the code above has undefined behaviour because it
> uses reserved identifiers. Second , using __ in the beginning of
> identifiers with the hope of avoiding clashes is a bad design decision
> because so many C libraries make the same bad decision so it does not reduce
> the chances of having clashes. It is best to start identifiers in libraries
> which are for public usage with a prefix which isn't reserved by the standard
> and has a reasonable chance of being unique. So for example an MP3 decoder
> written by John Smith could start all public identifiers with JSMD_ (John
> Smith MP3 decoder).
>
It's hard to write an MP3 decoder and, if someone has already made a working
version available for free which fits in a single file, it's not a good use of my time.
But these relatively trivial problems break whole programs. Some Linux users
who download the Baby X resource compiler will be able to fix the compile errors
quite quickly. But may will say "Oh, it doesn't compile, obviously it doesn't work
on Linux".
The whole point of portable programming is that it should work on an unknown
target platform. But that's hard to achieve.

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

> The a basic problem was that I am using a MP3 decoder written by someone else.
> They wrote a file called clib.h which has various efficiency and
> portability hacks. It includes this
>
> #if !NEED_MINILIBC
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #endif
> #include <math.h>
>
> #ifndef __int8_t_defined
> #define __int8_t_defined

This would be a big red flag for me. I would be very cautious of using
this decoder.

> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned int uint32_t;
> typedef signed int int32_t;
> #ifdef _MSC_VER
> typedef unsigned __int64 uint64_t;
> typedef signed __int64 int64_t;
> #else
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
> #endif
> #endif
>
> Linux include <stdint.h> from the system headers.

I can't understand what you mean here. I see nothing here that includes
stdint.h. "Linux" doesn't.

> Windows and Mac doesn't. So this breaks when compiled on Linux. By
> trying to be portable, they managed to produce something which wasn't
> portable.

The code uses __int8_t_defined which has no predictable or well-defined
meaning.

> It really confirms my view that it's best to write in a conservative
> subset of C90 and the subsequent standards.

The above code looks to be using a conservative subset of C90. It's
guessing about __int8_t_defined but it's not using C99 or above.

You have not shown where the problem really comes from, other than some
code that is guessing on what __int8_t_defined might mean.

--
Ben.

In article <2f89490d-af9a-4cc8-ab08-80365edd6b52n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>It's hard to write an MP3 decoder and, if someone has already made a
>working version available for free which fits in a single file, it's not a
>good use of my time. But these relatively trivial problems break whole
>programs. Some Linux users who download the Baby X resource compiler will
>be able to fix the compile errors quite quickly. But may will say "Oh, it
>doesn't compile, obviously it doesn't work on Linux".
>
>The whole point of portable programming is that it should work on an unknown
>target platform. But that's hard to achieve.

I have to admit that I haven't dug deeply enough into it to know (or care),
but it seems like if you can say "It should be easy enough for the user to
be able to fix the compile errors quite quickly", then it should be easy
enough for you, the developer, to fix it so that they don't have to. Am I
wrong?

You should not have to re-write the whole MP3 decoder in order to
accomplish this (so that's kind of a red herring).

--
Adderall, pseudoephed, teleprompter

On Sunday, 6 August 2023 at 14:52:40 UTC+1, Kenny McCormack wrote:
> In article <2f89490d-af9a-4cc8...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> ...
> >It's hard to write an MP3 decoder and, if someone has already made a
> >working version available for free which fits in a single file, it's not a
> >good use of my time. But these relatively trivial problems break whole
> >programs. Some Linux users who download the Baby X resource compiler will
> >be able to fix the compile errors quite quickly. But may will say "Oh, it
> >doesn't compile, obviously it doesn't work on Linux".
> >
> >The whole point of portable programming is that it should work on an unknown
> >target platform. But that's hard to achieve.
> I have to admit that I haven't dug deeply enough into it to know (or care),
> but it seems like if you can say "It should be easy enough for the user to
> be able to fix the compile errors quite quickly", then it should be easy
> enough for you, the developer, to fix it so that they don't have to. Am I
> wrong?
>
> You should not have to re-write the whole MP3 decoder in order to
> accomplish this (so that's kind of a red herring).
>
I hacked it. It's possible to write an MP3 decoder without using any fixed-width
type (though you can forgive uint64_t). But to go through the code taking out
all the fixed width dependencies would be quite an undertaking and likely to
create errors. So I just included stdint.h and set the define. But it's not ideal.

The problem is that the preprocessor doesn't understand typedefs. And no-one
thought to make stdint.h's include guard part of its public specification.
So there's no way of knowing whether the types have been defined or not.

In article <9c9dee88-2625-4589-a85f-c2b03666a96an@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>The problem is that the preprocessor doesn't understand typedefs. And
>no-one thought to make stdint.h's include guard part of its public
>specification. So there's no way of knowing whether the types have been
>defined or not.

The big boys use autoconf. Have you considered that?

--
If the automobile had followed the same development cycle as the
computer, a Rolls-Royce today would cost $100, get a million miles to
the gallon, and explode once every few weeks, killing everyone inside.

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

> I've been working on the Baby X resource compiler for some time
> now. I've added in support for audio, unicode, and dataframes, plus a
> few minor enhancements such as the ability to add comments and write
> out a header as well as a C source file.
>
> I'm thinking of declaring a version shortly. Then I'll probably rest
> from my labours. Anything else anyone would want to see?
>
> I don't have a Linux machine. If someone would be kind enough to
> valgrind it to check for memory leaks or worse bugs, that would be a
> help.

The build now works, but the instructions don't work for me. I just
unzipped the code, changed to the created directory and ran cmake . and
the make. I see you fixed the "\n" for '\n' typo.

Audio test has memory write errors.

minimp3.c uses shifts recklessly giving undefined behaviour. These were
reported by compiling with gcc's -fsanitize=undefined option.

With strings.xml, valgrind reports memory access errors.

freetype/ttcalc.c has shift and negation errors.

nanosvgrast.h also shifts signed integers in a way undefined by C.

Valgrind reports that all the tests leak at least 8 bytes. I think this
is probably the first XML node allocation or something like that.
Trivial, but annoying if you want none.

The amino acid test leaks "2,536 bytes in 23 blocks".

Sorry for not posting the details, but I imagine you'll want to run
these tests yourself. I had to run each one by hand as there is no
automatic test script and there would be masses of copying and pasting of
text to give you all the details.

> The code is at
> https://github.com/MalcolmMcLean/babyxrc

--
Ben.

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

> It's hard to write an MP3 decoder and, if someone has already made a
> working version available for free which fits in a single file, it's
> not a good use of my time.

Just a side note... Packing all sorts of decoders and so on into one
program is probably a Windows thing. A Linux developer, using the Baby
X resource compiler, would, most likely, expect the various images and
sounds to be read, byte for byte, from a file already in the right
format. Linux offers all sorts of command-line conversion tools that
will be more capable, and offer more fine-grained control over the
conversion, than anything you can hope to keep up with. One more "make"
rule and the conversion becomes part of the build process.

--
Ben.

On 06/08/2023 15:47, Kenny McCormack wrote:
> In article <9c9dee88-2625-4589-a85f-c2b03666a96an@googlegroups.com>,
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> ...
>> The problem is that the preprocessor doesn't understand typedefs. And
>> no-one thought to make stdint.h's include guard part of its public
>> specification. So there's no way of knowing whether the types have been
>> defined or not.
>
> The big boys use autoconf. Have you considered that?
>

I've considered that it needs to be taken out and shot.

I've seen autoconf-generated scripts of 30,000 lines, taking minutes to
process, dwarfing the time it takes to build the actual app or library
(that's just an unimportant detail compared to its real work!).

It runs endless tests such as checking whether 'printf' is supported by
the C compiler. (And if it isn't, then what?)

Because, of course, C is so portable that you need to do 100 different
tests to see whether various features are supported by a particular
implementation

But even if all this was justified, you'd think such tests only need to
be done once when you install the compiler to be used, and not every
time you build a new program.

Worse than any of that, however, is when the autoconf-generated code,
which is a Bash script, is expected to be run under Windows. Then it is
your responsibility to create a Linux environment on your machine to
make it possible.

On 05/08/2023 20:33, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Saturday, 5 August 2023 at 12:17:46 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> I've been working on the Baby X resource compiler for some time now.
>>> ...
>>>> I don't have a Linux machine. If someone would be kind enough to
>>>> valgrind it to check for memory leaks or worse bugs, that would be a
>>>> help.
>>> The README has no build instructions. I'm happy to guess, but other
>>> users might not be.
>>>
>> Thanks.
>> Yes, one problem is that when you are both the developer and doumenter,
>> you're so close to the project that it's eay to miss the obvious.
>
> I get compile errors, but maybe this is not the right place to debug a
> build system...
>

I had a look to see what I could make of it. I did see build
instructions (maybe these have since been added), where it first
mentions Cmake (and here I thought, oh-oh!).

But then it said you can just do:

gcc *.c freetype/*.c samplerate/*.c -lm

from inside ./src. Translated to Windows (use \ not /, and forget -lm)
this worked.

I then tried it in WSL, and that worked too (or did after I added -lm -
one more annoyingly pointless and time-wasting detail of gcc).

The sources were days old so presumably these were the same ones you tried.

So I'd say the build system is one of the simplest I've seen,
considering that it produces a 2MB binary, a quite substantial program.

On 2023-08-06, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <9c9dee88-2625-4589-a85f-c2b03666a96an@googlegroups.com>,
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> ...
>>The problem is that the preprocessor doesn't understand typedefs. And
>>no-one thought to make stdint.h's include guard part of its public
>>specification. So there's no way of knowing whether the types have been
>>defined or not.
>
> The big boys use autoconf. Have you considered that?

Autoconf is more or less just a way of injecting a massive amount of
grotesque technical debt into your codebase for almost no benefit.

Any other way of achieving automated build configuration is better,
including:

- writing a script by hand.

- using canned configurations.

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

Bart <bc@freeuk.com> writes:

> On 05/08/2023 20:33, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Saturday, 5 August 2023 at 12:17:46 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> I've been working on the Baby X resource compiler for some time now.
>>>> ...
>>>>> I don't have a Linux machine. If someone would be kind enough to
>>>>> valgrind it to check for memory leaks or worse bugs, that would be a
>>>>> help.
>>>> The README has no build instructions. I'm happy to guess, but other
>>>> users might not be.
>>>>
>>> Thanks.
>>> Yes, one problem is that when you are both the developer and doumenter,
>>> you're so close to the project that it's eay to miss the obvious.
>>
>> I get compile errors, but maybe this is not the right place to debug a
>> build system...
>>
>
> I had a look to see what I could make of it. I did see build instructions
> (maybe these have since been added), where it first mentions Cmake (and
> here I thought, oh-oh!).
>
> But then it said you can just do:
>
> gcc *.c freetype/*.c samplerate/*.c -lm
>
> from inside ./src. Translated to Windows (use \ not /, and forget -lm) this
> worked.
>
> I then tried it in WSL, and that worked too (or did after I added -lm - one
> more annoyingly pointless and time-wasting detail of gcc).
>
> The sources were days old so presumably these were the same ones you
> tried.

Maybe. There's no version number that I can see but since I got compile
errors using the direct gcc command as well, I don't know what's going
on. Maybe my running cmake /broke/ the sources.

Anyway, it's fixed now. Running "cmake .; make" and the direct compile
build the binary, but there are a few things that need to be looked at.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The a basic problem was that I am using a MP3 decoder written by someone else.
> They wrote a file called clib.h which has various efficiency and portability hacks.
> It includes this
>
> #if !NEED_MINILIBC
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #endif
> #include <math.h>
>
> #ifndef __int8_t_defined
> #define __int8_t_defined
> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned int uint32_t;
> typedef signed int int32_t;
> #ifdef _MSC_VER
> typedef unsigned __int64 uint64_t;
> typedef signed __int64 int64_t;
> #else
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
> #endif
> #endif

This code assumes that the macro __int8_t_defined is defined if and only
if the fixed-width types from <stdint.h> are defined. There's no basis
for that assumption -- *unless* there's some other code we haven't seen
that sets __int8_t_defined appropriately. For example, there might be a
build step that write a small C source file that uses int8_t, then
writes a C header file whose contents depend on whether that source file
compiles or not. Perhaps the code that does that breaks on Linux.

Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
Some implementations might do so, but it's a bad assumption.

It's not guaranteed that int8_t exists even if <stdint.h> exists (if
CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
for that with `#ifdef INT8_MAX`.

If the code is intended to cater to pre-C99 implementations, the problem
is that the <stdint.h> header may not exist, and there's no way in C to
test whether a given header exists or not. (C23 adds __has_include(),
but of course if you have __has_include() you have <stdint.h> anyway.)

These days, it's likely safe enough to just assume that you have
<stdint.h>. Even a pre-C99 implementation is likely to provide it as an
extension. Or, if you really need it, you can look at Doug Gwyn's old
q8, which provides some C99 headers for use with C90 implementations:
https://www.lysator.liu.se/c/q8/index.html
Or you can check that __STDC_VERSION__ >= 199901L.

> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> So this breaks when compiled on Linux. By trying to be portable, they managed
> to produce something which wasn't portable.

What does that mean?

> It really confirms my view that it's best to write in a conservative subset of C90
> and the subsequent standards. otherwise you just get endless trouble. But writing
> my own MP3 decoder would be a huge job (I've written one before, but it was for
> work so of course I can't put it on the web).

It's likely that just assuming C99 or later would have avoided this
problem in the first place.

--
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 Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > The a basic problem was that I am using a MP3 decoder written by someone else.
> > They wrote a file called clib.h which has various efficiency and portability hacks.
> > It includes this
> >
> > #if !NEED_MINILIBC
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #endif
> > #include <math.h>
> >
> > #ifndef __int8_t_defined
> > #define __int8_t_defined
> > typedef unsigned char uint8_t;
> > typedef signed char int8_t;
> > typedef unsigned short uint16_t;
> > typedef signed short int16_t;
> > typedef unsigned int uint32_t;
> > typedef signed int int32_t;
> > #ifdef _MSC_VER
> > typedef unsigned __int64 uint64_t;
> > typedef signed __int64 int64_t;
> > #else
> > typedef unsigned long long uint64_t;
> > typedef signed long long int64_t;
> > #endif
> > #endif
> This code assumes that the macro __int8_t_defined is defined if and only
> if the fixed-width types from <stdint.h> are defined. There's no basis
> for that assumption -- *unless* there's some other code we haven't seen
> that sets __int8_t_defined appropriately. For example, there might be a
> build step that write a small C source file that uses int8_t, then
> writes a C header file whose contents depend on whether that source file
> compiles or not. Perhaps the code that does that breaks on Linux.
>
> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
> Some implementations might do so, but it's a bad assumption.
>
> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
> for that with `#ifdef INT8_MAX`.
>
> If the code is intended to cater to pre-C99 implementations, the problem
> is that the <stdint.h> header may not exist, and there's no way in C to
> test whether a given header exists or not. (C23 adds __has_include(),
> but of course if you have __has_include() you have <stdint.h> anyway.)
>
> These days, it's likely safe enough to just assume that you have
> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
> extension. Or, if you really need it, you can look at Doug Gwyn's old
> q8, which provides some C99 headers for use with C90 implementations:
> https://www.lysator.liu.se/c/q8/index.html
> Or you can check that __STDC_VERSION__ >= 199901L.
> > Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> > So this breaks when compiled on Linux. By trying to be portable, they managed
> > to produce something which wasn't portable.
> What does that mean?
> > It really confirms my view that it's best to write in a conservative subset of C90
> > and the subsequent standards. otherwise you just get endless trouble. But writing
> > my own MP3 decoder would be a huge job (I've written one before, but it was for
> > work so of course I can't put it on the web).
> It's likely that just assuming C99 or later would have avoided this
> problem in the first place.
>
Yes, but it's hard to write a MP3 decoder. So if someone makes one available
on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
(of course it is GNU LGPLed so Baby X can use it legally) which was back in
the days when Microsoft only supported C90, despite C99 having been out for
some time. So code written in 2013 does sometimes have to call code written
maybe a very long time ago.

Malcolm McLean ha scritto:
> On Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>>> The a basic problem was that I am using a MP3 decoder written by someone else.
>>> They wrote a file called clib.h which has various efficiency and portability hacks.
>>> It includes this
>>>
>>> #if !NEED_MINILIBC
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <string.h>
>>> #endif
>>> #include <math.h>
>>>
>>> #ifndef __int8_t_defined
>>> #define __int8_t_defined
>>> typedef unsigned char uint8_t;
>>> typedef signed char int8_t;
>>> typedef unsigned short uint16_t;
>>> typedef signed short int16_t;
>>> typedef unsigned int uint32_t;
>>> typedef signed int int32_t;
>>> #ifdef _MSC_VER
>>> typedef unsigned __int64 uint64_t;
>>> typedef signed __int64 int64_t;
>>> #else
>>> typedef unsigned long long uint64_t;
>>> typedef signed long long int64_t;
>>> #endif
>>> #endif
>> This code assumes that the macro __int8_t_defined is defined if and only
>> if the fixed-width types from <stdint.h> are defined. There's no basis
>> for that assumption -- *unless* there's some other code we haven't seen
>> that sets __int8_t_defined appropriately. For example, there might be a
>> build step that write a small C source file that uses int8_t, then
>> writes a C header file whose contents depend on whether that source file
>> compiles or not. Perhaps the code that does that breaks on Linux.
>>
>> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
>> Some implementations might do so, but it's a bad assumption.
>>
>> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
>> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
>> for that with `#ifdef INT8_MAX`.
>>
>> If the code is intended to cater to pre-C99 implementations, the problem
>> is that the <stdint.h> header may not exist, and there's no way in C to
>> test whether a given header exists or not. (C23 adds __has_include(),
>> but of course if you have __has_include() you have <stdint.h> anyway.)
>>
>> These days, it's likely safe enough to just assume that you have
>> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
>> extension. Or, if you really need it, you can look at Doug Gwyn's old
>> q8, which provides some C99 headers for use with C90 implementations:
>> https://www.lysator.liu.se/c/q8/index.html
>> Or you can check that __STDC_VERSION__ >= 199901L.
>>> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
>>> So this breaks when compiled on Linux. By trying to be portable, they managed
>>> to produce something which wasn't portable.
>> What does that mean?
>>> It really confirms my view that it's best to write in a conservative subset of C90
>>> and the subsequent standards. otherwise you just get endless trouble. But writing
>>> my own MP3 decoder would be a huge job (I've written one before, but it was for
>>> work so of course I can't put it on the web).
>> It's likely that just assuming C99 or later would have avoided this
>> problem in the first place.
>>
> Yes, but it's hard to write a MP3 decoder. So if someone makes one available
> on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
> (of course it is GNU LGPLed so Baby X can use it legally) which was back in
> the days when Microsoft only supported C90, despite C99 having been out for
> some time. So code written in 2013 does sometimes have to call code written
> maybe a very long time ago.
>

Many programs use 'ffmpeg' asking it to unpack the audio file and
broadcast it on the stream, then they take the raw data from the same
stream. You can find 'ffmpeg' for almost all systems.

On Monday, 7 August 2023 at 12:10:06 UTC+1, jak wrote:
> Malcolm McLean ha scritto:
> > On Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> [...]
> >>> The a basic problem was that I am using a MP3 decoder written by someone else.
> >>> They wrote a file called clib.h which has various efficiency and portability hacks.
> >>> It includes this
> >>>
> >>> #if !NEED_MINILIBC
> >>> #include <stdio.h>
> >>> #include <stdlib.h>
> >>> #include <string.h>
> >>> #endif
> >>> #include <math.h>
> >>>
> >>> #ifndef __int8_t_defined
> >>> #define __int8_t_defined
> >>> typedef unsigned char uint8_t;
> >>> typedef signed char int8_t;
> >>> typedef unsigned short uint16_t;
> >>> typedef signed short int16_t;
> >>> typedef unsigned int uint32_t;
> >>> typedef signed int int32_t;
> >>> #ifdef _MSC_VER
> >>> typedef unsigned __int64 uint64_t;
> >>> typedef signed __int64 int64_t;
> >>> #else
> >>> typedef unsigned long long uint64_t;
> >>> typedef signed long long int64_t;
> >>> #endif
> >>> #endif
> >> This code assumes that the macro __int8_t_defined is defined if and only
> >> if the fixed-width types from <stdint.h> are defined. There's no basis
> >> for that assumption -- *unless* there's some other code we haven't seen
> >> that sets __int8_t_defined appropriately. For example, there might be a
> >> build step that write a small C source file that uses int8_t, then
> >> writes a C header file whose contents depend on whether that source file
> >> compiles or not. Perhaps the code that does that breaks on Linux.
> >>
> >> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
> >> Some implementations might do so, but it's a bad assumption.
> >>
> >> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
> >> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
> >> for that with `#ifdef INT8_MAX`.
> >>
> >> If the code is intended to cater to pre-C99 implementations, the problem
> >> is that the <stdint.h> header may not exist, and there's no way in C to
> >> test whether a given header exists or not. (C23 adds __has_include(),
> >> but of course if you have __has_include() you have <stdint.h> anyway.)
> >>
> >> These days, it's likely safe enough to just assume that you have
> >> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
> >> extension. Or, if you really need it, you can look at Doug Gwyn's old
> >> q8, which provides some C99 headers for use with C90 implementations:
> >> https://www.lysator.liu.se/c/q8/index.html
> >> Or you can check that __STDC_VERSION__ >= 199901L.
> >>> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> >>> So this breaks when compiled on Linux. By trying to be portable, they managed
> >>> to produce something which wasn't portable.
> >> What does that mean?
> >>> It really confirms my view that it's best to write in a conservative subset of C90
> >>> and the subsequent standards. otherwise you just get endless trouble. But writing
> >>> my own MP3 decoder would be a huge job (I've written one before, but it was for
> >>> work so of course I can't put it on the web).
> >> It's likely that just assuming C99 or later would have avoided this
> >> problem in the first place.
> >>
> > Yes, but it's hard to write a MP3 decoder. So if someone makes one available
> > on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
> > (of course it is GNU LGPLed so Baby X can use it legally) which was back in
> > the days when Microsoft only supported C90, despite C99 having been out for
> > some time. So code written in 2013 does sometimes have to call code written
> > maybe a very long time ago.
> >
> Many programs use 'ffmpeg' asking it to unpack the audio file and
> broadcast it on the stream, then they take the raw data from the same
> stream. You can find 'ffmpeg' for almost all systems.
>
What happens is that you produce the project. Then you ship it and development
stops. But you don't throw it away. You archive it. Some years later, you might
need to dust it off. The people who worked on it might have left. And life will
have moved on. A lot of the dependencies might have broken. It might no longer
be true that most machines run ffmpeg. Or the interfaces might have changed.

So you lose most of the benefits of a resource compiler as soon as you start
using it as glue application for other applications.

Malcolm McLean ha scritto:
> On Monday, 7 August 2023 at 12:10:06 UTC+1, jak wrote:
>> Malcolm McLean ha scritto:
>>> On Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>> [...]
>>>>> The a basic problem was that I am using a MP3 decoder written by someone else.
>>>>> They wrote a file called clib.h which has various efficiency and portability hacks.
>>>>> It includes this
>>>>>
>>>>> #if !NEED_MINILIBC
>>>>> #include <stdio.h>
>>>>> #include <stdlib.h>
>>>>> #include <string.h>
>>>>> #endif
>>>>> #include <math.h>
>>>>>
>>>>> #ifndef __int8_t_defined
>>>>> #define __int8_t_defined
>>>>> typedef unsigned char uint8_t;
>>>>> typedef signed char int8_t;
>>>>> typedef unsigned short uint16_t;
>>>>> typedef signed short int16_t;
>>>>> typedef unsigned int uint32_t;
>>>>> typedef signed int int32_t;
>>>>> #ifdef _MSC_VER
>>>>> typedef unsigned __int64 uint64_t;
>>>>> typedef signed __int64 int64_t;
>>>>> #else
>>>>> typedef unsigned long long uint64_t;
>>>>> typedef signed long long int64_t;
>>>>> #endif
>>>>> #endif
>>>> This code assumes that the macro __int8_t_defined is defined if and only
>>>> if the fixed-width types from <stdint.h> are defined. There's no basis
>>>> for that assumption -- *unless* there's some other code we haven't seen
>>>> that sets __int8_t_defined appropriately. For example, there might be a
>>>> build step that write a small C source file that uses int8_t, then
>>>> writes a C header file whose contents depend on whether that source file
>>>> compiles or not. Perhaps the code that does that breaks on Linux.
>>>>
>>>> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
>>>> Some implementations might do so, but it's a bad assumption.
>>>>
>>>> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
>>>> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
>>>> for that with `#ifdef INT8_MAX`.
>>>>
>>>> If the code is intended to cater to pre-C99 implementations, the problem
>>>> is that the <stdint.h> header may not exist, and there's no way in C to
>>>> test whether a given header exists or not. (C23 adds __has_include(),
>>>> but of course if you have __has_include() you have <stdint.h> anyway.)
>>>>
>>>> These days, it's likely safe enough to just assume that you have
>>>> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
>>>> extension. Or, if you really need it, you can look at Doug Gwyn's old
>>>> q8, which provides some C99 headers for use with C90 implementations:
>>>> https://www.lysator.liu.se/c/q8/index.html
>>>> Or you can check that __STDC_VERSION__ >= 199901L.
>>>>> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
>>>>> So this breaks when compiled on Linux. By trying to be portable, they managed
>>>>> to produce something which wasn't portable.
>>>> What does that mean?
>>>>> It really confirms my view that it's best to write in a conservative subset of C90
>>>>> and the subsequent standards. otherwise you just get endless trouble. But writing
>>>>> my own MP3 decoder would be a huge job (I've written one before, but it was for
>>>>> work so of course I can't put it on the web).
>>>> It's likely that just assuming C99 or later would have avoided this
>>>> problem in the first place.
>>>>
>>> Yes, but it's hard to write a MP3 decoder. So if someone makes one available
>>> on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
>>> (of course it is GNU LGPLed so Baby X can use it legally) which was back in
>>> the days when Microsoft only supported C90, despite C99 having been out for
>>> some time. So code written in 2013 does sometimes have to call code written
>>> maybe a very long time ago.
>>>
>> Many programs use 'ffmpeg' asking it to unpack the audio file and
>> broadcast it on the stream, then they take the raw data from the same
>> stream. You can find 'ffmpeg' for almost all systems.
>>
> What happens is that you produce the project. Then you ship it and development
> stops. But you don't throw it away. You archive it. Some years later, you might
> need to dust it off. The people who worked on it might have left. And life will
> have moved on. A lot of the dependencies might have broken. It might no longer
> be true that most machines run ffmpeg. Or the interfaces might have changed.
>
> So you lose most of the benefits of a resource compiler as soon as you start
> using it as glue application for other applications.
>

I absolutely agree with you. Maybe I hurt the thread, where I believed
that the basic idea was to make the resource compiler available quickly.
For this reason I suggested this idea that it would be faster than
writing a decoder which can be done later.

On Monday, 7 August 2023 at 15:53:50 UTC+1, jak wrote:
> Malcolm McLean ha scritto:
> > On Monday, 7 August 2023 at 12:10:06 UTC+1, jak wrote:
> >> Malcolm McLean ha scritto:
> >>> On Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>> [...]
> >>>>> The a basic problem was that I am using a MP3 decoder written by someone else.
> >>>>> They wrote a file called clib.h which has various efficiency and portability hacks.
> >>>>> It includes this
> >>>>>
> >>>>> #if !NEED_MINILIBC
> >>>>> #include <stdio.h>
> >>>>> #include <stdlib.h>
> >>>>> #include <string.h>
> >>>>> #endif
> >>>>> #include <math.h>
> >>>>>
> >>>>> #ifndef __int8_t_defined
> >>>>> #define __int8_t_defined
> >>>>> typedef unsigned char uint8_t;
> >>>>> typedef signed char int8_t;
> >>>>> typedef unsigned short uint16_t;
> >>>>> typedef signed short int16_t;
> >>>>> typedef unsigned int uint32_t;
> >>>>> typedef signed int int32_t;
> >>>>> #ifdef _MSC_VER
> >>>>> typedef unsigned __int64 uint64_t;
> >>>>> typedef signed __int64 int64_t;
> >>>>> #else
> >>>>> typedef unsigned long long uint64_t;
> >>>>> typedef signed long long int64_t;
> >>>>> #endif
> >>>>> #endif
> >>>> This code assumes that the macro __int8_t_defined is defined if and only
> >>>> if the fixed-width types from <stdint.h> are defined. There's no basis
> >>>> for that assumption -- *unless* there's some other code we haven't seen
> >>>> that sets __int8_t_defined appropriately. For example, there might be a
> >>>> build step that write a small C source file that uses int8_t, then
> >>>> writes a C header file whose contents depend on whether that source file
> >>>> compiles or not. Perhaps the code that does that breaks on Linux.
> >>>>
> >>>> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
> >>>> Some implementations might do so, but it's a bad assumption.
> >>>>
> >>>> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
> >>>> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
> >>>> for that with `#ifdef INT8_MAX`.
> >>>>
> >>>> If the code is intended to cater to pre-C99 implementations, the problem
> >>>> is that the <stdint.h> header may not exist, and there's no way in C to
> >>>> test whether a given header exists or not. (C23 adds __has_include(),
> >>>> but of course if you have __has_include() you have <stdint.h> anyway.)
> >>>>
> >>>> These days, it's likely safe enough to just assume that you have
> >>>> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
> >>>> extension. Or, if you really need it, you can look at Doug Gwyn's old
> >>>> q8, which provides some C99 headers for use with C90 implementations:
> >>>> https://www.lysator.liu.se/c/q8/index.html
> >>>> Or you can check that __STDC_VERSION__ >= 199901L.
> >>>>> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> >>>>> So this breaks when compiled on Linux. By trying to be portable, they managed
> >>>>> to produce something which wasn't portable.
> >>>> What does that mean?
> >>>>> It really confirms my view that it's best to write in a conservative subset of C90
> >>>>> and the subsequent standards. otherwise you just get endless trouble. But writing
> >>>>> my own MP3 decoder would be a huge job (I've written one before, but it was for
> >>>>> work so of course I can't put it on the web).
> >>>> It's likely that just assuming C99 or later would have avoided this
> >>>> problem in the first place.
> >>>>
> >>> Yes, but it's hard to write a MP3 decoder. So if someone makes one available
> >>> on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
> >>> (of course it is GNU LGPLed so Baby X can use it legally) which was back in
> >>> the days when Microsoft only supported C90, despite C99 having been out for
> >>> some time. So code written in 2013 does sometimes have to call code written
> >>> maybe a very long time ago.
> >>>
> >> Many programs use 'ffmpeg' asking it to unpack the audio file and
> >> broadcast it on the stream, then they take the raw data from the same
> >> stream. You can find 'ffmpeg' for almost all systems.
> >>
> > What happens is that you produce the project. Then you ship it and development
> > stops. But you don't throw it away. You archive it. Some years later, you might
> > need to dust it off. The people who worked on it might have left. And life will
> > have moved on. A lot of the dependencies might have broken. It might no longer
> > be true that most machines run ffmpeg. Or the interfaces might have changed.
> >
> > So you lose most of the benefits of a resource compiler as soon as you start
> > using it as glue application for other applications.
> >
> I absolutely agree with you. Maybe I hurt the thread, where I believed
> that the basic idea was to make the resource compiler available quickly.
> For this reason I suggested this idea that it would be faster than
> writing a decoder which can be done later.
>
I want to declare a version of the Baby X resource compiler quite quickly.
That means a feature freeze to get the bugs out. Unfortunately the MP3 decoder
appears to be a buggy component - it works fine on Mac and Windows, but
Linux is reporting errors. It's also hard to debug - I didn't write it myself which
makes things harder, and it's quite dense code that does a lot of low level
bit manipulation. So I'm not quite sure what to do, but the obvious thing is to
have a go at it. If that isn't sucessful, it's a bit of a hard decision. Whilst it
appears to work fine on Windows, that might be an illusion.

On Monday, 7 August 2023 at 16:27:41 UTC+1, Malcolm McLean wrote:
> On Monday, 7 August 2023 at 15:53:50 UTC+1, jak wrote:
> > Malcolm McLean ha scritto:
> > > On Monday, 7 August 2023 at 12:10:06 UTC+1, jak wrote:
> > >> Malcolm McLean ha scritto:
> > >>> On Sunday, 6 August 2023 at 22:03:21 UTC+1, Keith Thompson wrote:
> > >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > >>>> [...]
> > >>>>> The a basic problem was that I am using a MP3 decoder written by someone else.
> > >>>>> They wrote a file called clib.h which has various efficiency and portability hacks.
> > >>>>> It includes this
> > >>>>>
> > >>>>> #if !NEED_MINILIBC
> > >>>>> #include <stdio.h>
> > >>>>> #include <stdlib.h>
> > >>>>> #include <string.h>
> > >>>>> #endif
> > >>>>> #include <math.h>
> > >>>>>
> > >>>>> #ifndef __int8_t_defined
> > >>>>> #define __int8_t_defined
> > >>>>> typedef unsigned char uint8_t;
> > >>>>> typedef signed char int8_t;
> > >>>>> typedef unsigned short uint16_t;
> > >>>>> typedef signed short int16_t;
> > >>>>> typedef unsigned int uint32_t;
> > >>>>> typedef signed int int32_t;
> > >>>>> #ifdef _MSC_VER
> > >>>>> typedef unsigned __int64 uint64_t;
> > >>>>> typedef signed __int64 int64_t;
> > >>>>> #else
> > >>>>> typedef unsigned long long uint64_t;
> > >>>>> typedef signed long long int64_t;
> > >>>>> #endif
> > >>>>> #endif
> > >>>> This code assumes that the macro __int8_t_defined is defined if and only
> > >>>> if the fixed-width types from <stdint.h> are defined. There's no basis
> > >>>> for that assumption -- *unless* there's some other code we haven't seen
> > >>>> that sets __int8_t_defined appropriately. For example, there might be a
> > >>>> build step that write a small C source file that uses int8_t, then
> > >>>> writes a C header file whose contents depend on whether that source file
> > >>>> compiles or not. Perhaps the code that does that breaks on Linux.
> > >>>>
> > >>>> Or perhaps it assume that <stdint.h> defines a macro __int8_t_defined.
> > >>>> Some implementations might do so, but it's a bad assumption.
> > >>>>
> > >>>> It's not guaranteed that int8_t exists even if <stdint.h> exists (if
> > >>>> CHAR_BIT==8 or signed char doesn't use two's-complement). You can check
> > >>>> for that with `#ifdef INT8_MAX`.
> > >>>>
> > >>>> If the code is intended to cater to pre-C99 implementations, the problem
> > >>>> is that the <stdint.h> header may not exist, and there's no way in C to
> > >>>> test whether a given header exists or not. (C23 adds __has_include(),
> > >>>> but of course if you have __has_include() you have <stdint.h> anyway.)
> > >>>>
> > >>>> These days, it's likely safe enough to just assume that you have
> > >>>> <stdint.h>. Even a pre-C99 implementation is likely to provide it as an
> > >>>> extension. Or, if you really need it, you can look at Doug Gwyn's old
> > >>>> q8, which provides some C99 headers for use with C90 implementations:
> > >>>> https://www.lysator.liu.se/c/q8/index.html
> > >>>> Or you can check that __STDC_VERSION__ >= 199901L.
> > >>>>> Linux include <stdint.h> from the system headers. Windows and Mac doesn't.
> > >>>>> So this breaks when compiled on Linux. By trying to be portable, they managed
> > >>>>> to produce something which wasn't portable.
> > >>>> What does that mean?
> > >>>>> It really confirms my view that it's best to write in a conservative subset of C90
> > >>>>> and the subsequent standards. otherwise you just get endless trouble. But writing
> > >>>>> my own MP3 decoder would be a huge job (I've written one before, but it was for
> > >>>>> work so of course I can't put it on the web).
> > >>>> It's likely that just assuming C99 or later would have avoided this
> > >>>> problem in the first place.
> > >>>>
> > >>> Yes, but it's hard to write a MP3 decoder. So if someone makes one available
> > >>> on the web for free, it makes sense to use it. The bulk of it is copyright 2001,
> > >>> (of course it is GNU LGPLed so Baby X can use it legally) which was back in
> > >>> the days when Microsoft only supported C90, despite C99 having been out for
> > >>> some time. So code written in 2013 does sometimes have to call code written
> > >>> maybe a very long time ago.
> > >>>
> > >> Many programs use 'ffmpeg' asking it to unpack the audio file and
> > >> broadcast it on the stream, then they take the raw data from the same
> > >> stream. You can find 'ffmpeg' for almost all systems.
> > >>
> > > What happens is that you produce the project. Then you ship it and development
> > > stops. But you don't throw it away. You archive it. Some years later, you might
> > > need to dust it off. The people who worked on it might have left. And life will
> > > have moved on. A lot of the dependencies might have broken. It might no longer
> > > be true that most machines run ffmpeg. Or the interfaces might have changed.
> > >
> > > So you lose most of the benefits of a resource compiler as soon as you start
> > > using it as glue application for other applications.
> > >
> > I absolutely agree with you. Maybe I hurt the thread, where I believed
> > that the basic idea was to make the resource compiler available quickly.
> > For this reason I suggested this idea that it would be faster than
> > writing a decoder which can be done later.
> >
> I want to declare a version of the Baby X resource compiler quite quickly.
> That means a feature freeze to get the bugs out. Unfortunately the MP3 decoder
> appears to be a buggy component - it works fine on Mac and Windows, but
> Linux is reporting errors. It's also hard to debug - I didn't write it myself which
> makes things harder, and it's quite dense code that does a lot of low level
> bit manipulation. So I'm not quite sure what to do, but the obvious thing is to
> have a go at it. If that isn't sucessful, it's a bit of a hard decision. Whilst it
> appears to work fine on Windows, that might be an illusion.
>
I managed to find the bug reported by Ben, and it's in my own code, not the MP3
decoder itself. Which is a big relief.

Spiros Bousbouras <spibou@gmail.com> writes:

> On Sun, 6 Aug 2023 04:36:47 -0700 (PDT)
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

>> #ifndef __int8_t_defined
>> #define __int8_t_defined
>> typedef unsigned char uint8_t;
>> typedef signed char int8_t;
>> typedef unsigned short uint16_t;
>> typedef signed short int16_t;
>> typedef unsigned int uint32_t;
>> typedef signed int int32_t;
>> #ifdef _MSC_VER
>> typedef unsigned __int64 uint64_t;
>> typedef signed __int64 int64_t;
>> #else
>> typedef unsigned long long uint64_t;
>> typedef signed long long int64_t;
>> #endif
>> #endif

> [...] the code above has undefined behaviour because it uses
> reserved identifiers. [...]

This code does have undefined behavior, but only because it
/defines/ a reserved identifier. Simply /using/ a reserved
identifier is not undefined behavior, only declaring or
defining one.

On 06/08/2023 16:07, Malcolm McLean wrote:
> The problem is that the preprocessor doesn't understand typedefs. And no-one
> thought to make stdint.h's include guard part of its public specification.
> So there's no way of knowing whether the types have been defined or not.
>

There is an extremely simple answer to all this:

#include <stdint.h>

There. Done. All your <stdint.h> types are defined and ready to use.

On 06/08/2023 17:02, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> It's hard to write an MP3 decoder and, if someone has already made a
>> working version available for free which fits in a single file, it's
>> not a good use of my time.
>
> Just a side note... Packing all sorts of decoders and so on into one
> program is probably a Windows thing. A Linux developer, using the Baby
> X resource compiler, would, most likely, expect the various images and
> sounds to be read, byte for byte, from a file already in the right
> format. Linux offers all sorts of command-line conversion tools that
> will be more capable, and offer more fine-grained control over the
> conversion, than anything you can hope to keep up with. One more "make"
> rule and the conversion becomes part of the build process.
>

Of course. But that is surely so obvious that Malcolm has thought about
it. Presumably his users find it helpful to be able to convert from a
few formats using a decoder of unknown quality, rather than using
high-quality and flexible tools like ImageMagick, FFmpeg, or others to
convert to standard uncompressed formats.

David Brown <david.brown@hesbynett.no> writes:
>On 06/08/2023 17:02, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> It's hard to write an MP3 decoder and, if someone has already made a
>>> working version available for free which fits in a single file, it's
>>> not a good use of my time.
>>
>> Just a side note... Packing all sorts of decoders and so on into one
>> program is probably a Windows thing. A Linux developer, using the Baby
>> X resource compiler, would, most likely, expect the various images and
>> sounds to be read, byte for byte, from a file already in the right
>> format. Linux offers all sorts of command-line conversion tools that
>> will be more capable, and offer more fine-grained control over the
>> conversion, than anything you can hope to keep up with. One more "make"
>> rule and the conversion becomes part of the build process.
>>
>
>Of course. But that is surely so obvious that Malcolm has thought about
>it. Presumably his users find it helpful to be able to convert from a
>few formats using a decoder of unknown quality, rather than using
>high-quality and flexible tools like ImageMagick, FFmpeg, or others to
>convert to standard uncompressed formats.
>

Indeed, it is not uncommon to see sequences like this:

FILE *infile = NULL;
char buffer[PATH_MAX];
if (strstr(argv[1], ".lzo")) {
snprintf(buffer, sizeof(buffer), "lzop -d < %s", argv[1]);
buffer[sizeof(buffer)-1] = '\0';
infile = popen(buffer, "r");
} else if (strstr(argv[1], ".gz")) {
snprintf(buffer, sizeof(buffer), "zcat %s", argv[1]);
buffer[sizeof(buffer)-1] = '\0';
infile = popen(buffer, "r");
} else if (strstr(argv[1], ".xz")) {
snprintf(buffer, sizeof(buffer), "xz -d < %s", argv[1]);
buffer[sizeof(buffer)-1] = '\0';
infile = popen(buffer, "r");
} else {
infile = fopen(argv[1], "r");
}

if (infile == NULL) {
fprintf(stderr, "%s: Unable to open '%s': %s\n", argv[0], argv[1], strerror(errno));
return false;
}
....

On Tuesday, 8 August 2023 at 15:57:48 UTC+1, David Brown wrote:
> On 06/08/2023 17:02, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >
> >> It's hard to write an MP3 decoder and, if someone has already made a
> >> working version available for free which fits in a single file, it's
> >> not a good use of my time.
> >
> > Just a side note... Packing all sorts of decoders and so on into one
> > program is probably a Windows thing. A Linux developer, using the Baby
> > X resource compiler, would, most likely, expect the various images and
> > sounds to be read, byte for byte, from a file already in the right
> > format. Linux offers all sorts of command-line conversion tools that
> > will be more capable, and offer more fine-grained control over the
> > conversion, than anything you can hope to keep up with. One more "make"
> > rule and the conversion becomes part of the build process.
> >
> Of course. But that is surely so obvious that Malcolm has thought about
> it. Presumably his users find it helpful to be able to convert from a
> few formats using a decoder of unknown quality, rather than using
> high-quality and flexible tools like ImageMagick, FFmpeg, or others to
> convert to standard uncompressed formats.
>
The MP3 decoder I am using was written by Fabrice Bellard, who is the same
person who wrote the ffmpeg audio decoder. Things might have forked
since, but basically its the same decoder as in ffmpeg.

But I think you're confusing an MP3 decoder with an MP3 encoder. MP3 is
designed so that the decoder is relatively simple to write. It fits in a single
C source file, after all. Writing an encoder is a different proposition, and
encoder can vary a food deal in quality.

I want an MP3 encoder in the Baby X resource compiler so that people can
store raw resources as .wavs and embed them as MP3. But getting one that
integrates nicely is hard, and not for v1.2. However if anyone wants to help
out, this is high on the wishlist.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 8 August 2023 at 15:57:48 UTC+1, David Brown wrote:
>> On 06/08/2023 17:02, Ben Bacarisse wrote:
>> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >
>> >> It's hard to write an MP3 decoder and, if someone has already made a
>> >> working version available for free which fits in a single file, it's
>> >> not a good use of my time.
>> >
>> > Just a side note... Packing all sorts of decoders and so on into one
>> > program is probably a Windows thing. A Linux developer, using the Baby
>> > X resource compiler, would, most likely, expect the various images and
>> > sounds to be read, byte for byte, from a file already in the right
>> > format. Linux offers all sorts of command-line conversion tools that
>> > will be more capable, and offer more fine-grained control over the
>> > conversion, than anything you can hope to keep up with. One more "make"
>> > rule and the conversion becomes part of the build process.
>> >
>> Of course. But that is surely so obvious that Malcolm has thought about
>> it. Presumably his users find it helpful to be able to convert from a
>> few formats using a decoder of unknown quality, rather than using
>> high-quality and flexible tools like ImageMagick, FFmpeg, or others to
>> convert to standard uncompressed formats.
>>
>The MP3 decoder I am using was written by Fabrice Bellard, who is the same
>person who wrote the ffmpeg audio decoder. Things might have forked
>since, but basically its the same decoder as in ffmpeg.
>
>But I think you're confusing an MP3 decoder with an MP3 encoder. MP3 is
>designed so that the decoder is relatively simple to write. It fits in a single
>C source file, after all. Writing an encoder is a different proposition, and
>encoder can vary a food deal in quality.
>
>I want an MP3 encoder in the Baby X resource compiler so that people can
>store raw resources as .wavs and embed them as MP3. But getting one that
>integrates nicely is hard, and not for v1.2. However if anyone wants to help
>out, this is high on the wishlist.

char buffer[PATH_MAX];
snprintf(buffer, sizeof(buffer), "lame -b 320 -m s -h %s -", mp3filename);
FILE *encoded_mp3 = popen(buffer, "r");

David Brown <david.brown@hesbynett.no> writes:
> On 06/08/2023 16:07, Malcolm McLean wrote:
>> The problem is that the preprocessor doesn't understand typedefs. And no-one
>> thought to make stdint.h's include guard part of its public specification.
>> So there's no way of knowing whether the types have been defined or not.
>>
>
> There is an extremely simple answer to all this:
>
> #include <stdint.h>
>
> There. Done. All your <stdint.h> types are defined and ready to use.

Which is basically what Malcolm did to fix the problem. Here's the
relevant change he made (commit 51f9819 in
https://github.com/MalcolmMcLean/babyxrc):

#if !NEED_MINILIBC
+ #include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+ #define __int8_t_defined
#endif

Defining __int8_t_defined causes the code that conditionally defines
int8_t et al to skip those definitions.

Apparently src/libc.h was copied from some other project. I can't tell
where it came from.

Malcolm, can you tell us where that code originated?

--
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 */