Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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?

My guess is that the author of that code assumed that <stdint.h> defines
the macro __int8_t_defined. Obviously it's not required to do so, but
perhaps the assumption was valid on the systems the author had tried.

--
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 Wednesday, 9 August 2023 at 00:38:03 UTC+1, Keith Thompson wrote:
> David Brown <david...@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?
>
The MP3 decoder was written by Fabrice Bellard (of tcc fame) and incuded
in ffmpeg. Then it was taken out of ffmpeg by Martin J Fielder and "stripped down",
to turn it into what was essentially a single file decoder. However there were some
effiiciency hacks which were placed in libc.h. If you turn these off, effectively
libc.h just includes a few standard headers, and then defines the <stdint.h>
types.
The irony is that whoever chose to define the <stdint.h> types like that was
trying their best to make the code more portable, but in fact by so doing
they broke it.

On 8/6/23 10:07 AM, Malcolm McLean wrote:
> 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.
>

Except that for every type in stdint.h properly defined DOES have a
macros defined for it, the XXX_MAX macro.

Of course, some rogue header could define the type but not the macro,
but it can be argued that such a header is broken.

Richard Damon <Richard@Damon-Family.org> writes:

> On 8/6/23 10:07 AM, Malcolm McLean wrote:

[..working on code that uses [u]intN_t from <stdint.h>..]

>> 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.
>
> Except that for every type in stdint.h properly defined DOES have a
> macros defined for it, the XXX_MAX macro.
>
> Of course, some rogue header could define the type but not the
> macro, but it can be argued that such a header is broken.

Changing the code so it avoids the [u]intN_t types altogether
(and no longer needs <stdint.h>) is not hard. I did it in
about 30 minutes.