Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #171661 > unrolled thread

Baby X resource compiler nearly ready

Back to article view | Back to comp.lang.c

Contents

  Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 02:59 -0700
    Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 03:20 -0700
      Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 03:28 -0700
        Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 03:42 -0700
      Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 03:41 -0700
        Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 03:46 -0700
          Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 03:57 -0700
            Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 05:28 -0700
              Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 06:01 -0700
        Re: Baby X resource compiler nearly ready fir <profesor.fir@gmail.com> - 2023-08-05 03:49 -0700
        Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 12:29 +0100
          Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 04:38 -0700
    Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 12:17 +0100
      Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 04:19 -0700
        Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 20:33 +0100
          Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 12:39 -0700
            Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 22:48 +0100
              Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-06 03:21 -0700
                Re: Baby X resource compiler nearly ready gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-06 11:01 +0000
                  Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-06 04:36 -0700
                    Re: Baby X resource compiler nearly ready Spiros Bousbouras <spibou@gmail.com> - 2023-08-06 12:52 +0000
                      Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-06 06:04 -0700
                        Re: Baby X resource compiler nearly ready gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-06 13:52 +0000
                          Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-06 07:07 -0700
                            Re: Baby X resource compiler nearly ready gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-06 14:47 +0000
                              Re: Baby X resource compiler nearly ready Bart <bc@freeuk.com> - 2023-08-06 16:18 +0100
                              Re: Baby X resource compiler nearly ready Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-06 16:29 +0000
                            Re: Baby X resource compiler nearly ready David Brown <david.brown@hesbynett.no> - 2023-08-08 16:52 +0200
                              Re: Baby X resource compiler nearly ready Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:37 -0700
                                Re: Baby X resource compiler nearly ready Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:41 -0700
                                Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 19:07 -0700
                            Re: Baby X resource compiler nearly ready Richard Damon <Richard@Damon-Family.org> - 2023-08-08 22:32 -0400
                              Re: Baby X resource compiler nearly ready Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 23:36 -0700
                        Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 16:02 +0100
                          Re: Baby X resource compiler nearly ready David Brown <david.brown@hesbynett.no> - 2023-08-08 16:57 +0200
                            Re: Baby X resource compiler nearly ready scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 15:09 +0000
                            Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 08:26 -0700
                              Re: Baby X resource compiler nearly ready scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 15:55 +0000
                      Re: Baby X resource compiler nearly ready Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 06:03 -0700
                    Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 14:36 +0100
                    Re: Baby X resource compiler nearly ready Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 14:03 -0700
                      Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 01:41 -0700
                        Re: Baby X resource compiler nearly ready jak <nospam@please.ty> - 2023-08-07 13:09 +0200
                          Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 04:59 -0700
                            Re: Baby X resource compiler nearly ready jak <nospam@please.ty> - 2023-08-07 16:53 +0200
                              Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 08:27 -0700
                                Re: Baby X resource compiler nearly ready Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 09:44 -0700
          Re: Baby X resource compiler nearly ready Bart <bc@freeuk.com> - 2023-08-06 16:44 +0100
            Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 17:56 +0100
    Re: Baby X resource compiler nearly ready scott@slp53.sl.home (Scott Lurndal) - 2023-08-05 14:38 +0000
      Re: Baby X resource compiler nearly ready gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-05 15:29 +0000
        Re: Baby X resource compiler nearly ready scott@slp53.sl.home (Scott Lurndal) - 2023-08-05 17:47 +0000
          Blah, blah, blah (Was: Baby X resource compiler nearly ready) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-05 18:44 +0000
    Re: Baby X resource compiler nearly ready Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 15:52 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#171715

On Sun, 6 Aug 2023 04:36:47 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@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).

-- 
vlaho.ninja/prog

[toc] | [prev] | [next] | [standalone]

#171716

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.

[toc] | [prev] | [next] | [standalone]

#171718

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

[toc] | [prev] | [next] | [standalone]

#171719

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. 

[toc] | [prev] | [next] | [standalone]

#171721

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.

[toc] | [prev] | [next] | [standalone]

#171725

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.

[toc] | [prev] | [next] | [standalone]

#171732

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

[toc] | [prev] | [next] | [standalone]

#171835

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.

[toc] | [prev] | [next] | [standalone]

#171892

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

[toc] | [prev] | [next] | [standalone]

#171893

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

[toc] | [prev] | [next] | [standalone]

#171905

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.

[toc] | [prev] | [next] | [standalone]

#171906

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.

[toc] | [prev] | [next] | [standalone]

#171910

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.

[toc] | [prev] | [next] | [standalone]

#171724

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.

[toc] | [prev] | [next] | [standalone]

#171837

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.

[toc] | [prev] | [next] | [standalone]

#171839

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;
    }
...

[toc] | [prev] | [next] | [standalone]

#171842

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.

[toc] | [prev] | [next] | [standalone]

#171849

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");

[toc] | [prev] | [next] | [standalone]

#171823

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.

[toc] | [prev] | [next] | [standalone]

#171717

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web