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 3 of 3 — ← Prev page 1 2 [3]

#171740

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

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

#171752

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.

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

#171755

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.

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

#171758

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.

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

#171766

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.

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

#171769

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. 

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

#171775

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.

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

#171726

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.

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

#171735

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.

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

#171685

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

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

If you have a windows machine, you have a linux machine, simply download
the free WSL.

https://learn.microsoft.com/en-us/windows/wsl/install

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

#171686

In article <P9tzM.486505$GMN3.64036@fx16.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>>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.
>>
>
>If you have a windows machine, you have a linux machine, simply
>download the free WSL.

From everything I've heard, WSL/WSL2 is whack.

Much better to install Virtual Box and go that route.

-- 
https://en.wikipedia.org/wiki/Mansplaining

    It describes comp.lang.c to a T!

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

#171690

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <P9tzM.486505$GMN3.64036@fx16.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>>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.
>>>
>>
>>If you have a windows machine, you have a linux machine, simply
>>download the free WSL.
>
>From everything I've heard, WSL/WSL2 is whack.

Well, if you're relying on the same "everything you've heard"
about Dijkstra, then perhaps you should evaluate WSL
yourself first.  :-)

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

#171693 — Blah, blah, blah (Was: Baby X resource compiler nearly ready)

In article <CWvzM.295629$U3w1.196231@fx09.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
...
>Well, if you're relying on the same "everything you've heard"
>about Dijkstra, ....

I think you have confused me with Malcolm.

(FWW, if Dijkstra was/is a "lefty", that would be all to the good)

-- 
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

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

#171723

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.

[toc] | [prev] | [standalone]

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

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

csiph-web