4 ms·

Note that: #define OUTPUTS 0 char outputs[OUTPUTS] = { }; is not valid C (or C++) - zero length arrays are not a thing in either language,

jacquesm 7y ago
(base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cc -c -Wall x.c (base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cat x.c #define OUTPUTS 0 char outputs[OUTPUTS] = { }; Looks like you're wrong about that; at least for GNU C. It's not official C but if it works and generates no warnings it will be used too. Long HN thread about this subject: https://news.ycombinator.com/item?id=11674374 https://news.ycombinator.com/item?id=11674374 Zero length arrays are one of those things that C is renowned and notorious for: something that is useful at times but unpredictable because it is flirting with undefined behavior. I usually compare C with a Formula 1 race car. It works well as long as you don't cut too many corners and when you do you end up plastered all over the road.
- zabzonk 7y ago
  [neilb@Miranda temp]$ gcc -Wall -Wextra -pedantic a.c a.c:2:6: warning: ISO C forbids zero-size array 'outputs' [-Wpedantic] char outputs[OUTPUTS] = { };
  - jacquesm 7y ago
    Yes, the -pedantic is what will trigger that. See linked post. But that's not on by default (fortunately!). ISO C is so restrictive ;)
    - zabzonk 7y ago
      > (fortunately!) Unfortunately. All warnings and errors should be on by default. That they are not is one of the things about GCC that really pisses me off.
      - jacquesm 7y ago
        Still not getting the joke. Yes, they should be on, in fact GCC should not do this, 'extensions' to a language that invite undefined behavior are not in line with solid software development practices. Neither is brainfuck...
        mikepurvis 7y ago
        I feel obliged to point out that some of those extensions a) are pretty important for large scale projects, and b) end up standardized later on anyway— eg variadic macros being added in C99. Definitely a case to be made that the default behaviour should be what the standard says, with extensions as an opt-in. But experimental extensions also move the language forward.
        codetrotter 7y ago
        I guess what jacquesm was getting at was that instead of extending C, the world should have left C behind a long time ago and transitioned to other, safer languages. These days there are excellent alternatives to C, but of course we also have vast codebases written in C that would be too big of an undertaking and too much of a risk to rewrite in a safer language. There may not have been any sufficiently widespread alternative in the past in terms of developer mindshare, and sufficiently performant considering how limited the hardware was in terms of both speed and memory and storage. There is also the issue of portability and of embedded platforms, and that remains problematic to this day in some cases but in other cases the possibilities for using safer languages are already really good. Even in cases where an alternative was known and suitable, people in the past had legacy codebases that they were working with too that they didn't want to risk rewriting in any other language. So they just kept adding to the code that they had. The legacy-code that we are sitting on now is so many lines of code that one might wonder, was it even justified that they didn't want to take on the risk of rewriting the code in the past, while there still was a chance to do it all in one go? Maybe, maybe not. Either way, we can do nothing about the past, but if we keep growing the legacy codebases, the problem only gets bigger in the future. We should not strive to rewrite it all at once, but we should use safer languages when we extend our codebases, and we should use safer languages when we start new projects. Every line of code that we write today adds to the amount of code that will make up the legacy code of tomorrow. Let's strive to make the legacy code of the future safer, so that our children may run their societies on safer software!
- james_s_tayler 7y ago
  Isn't countering the G-force when cornering to keep your head straight the equivalent of lifting 25kgs with your neck? C sounds like one hell of a ride.
- dsfyu404ed 7y ago
  >one of those things that C is renowned and notorious for: something that is useful at times but unpredictable because it is flirting with undefined behavior. This describes all the stuff that makes C useful.
deleted 7y ago
[deleted]
shultays 7y ago
what it is being used for? I can't figure what that fwrite part does
- YSFEJ4SWJUVU6 7y ago
  That fwrite writes the contents of output to stdout. output probably contains all the output that doesn't depend on input (which this program doesn't have).

jacquesm 7y ago

(base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cc -c -Wall x.c (base) jam@jam-XPS-8500:~/svn/src/music/mp3tomidi$ cat x.c #define OUTPUTS 0 char outputs[OUTPUTS] = { }; Looks like you're wrong about that; at least for GNU C. It's not official C but if it works and generates no warnings it will be used too. Long HN thread about this subject: https://news.ycombinator.com/item?id=11674374 https://news.ycombinator.com/item?id=11674374 Zero length arrays are one of those things that C is renowned and notorious for: something that is useful at times but unpredictable because it is flirting with undefined behavior. I usually compare C with a Formula 1 race car. It works well as long as you don't cut too many corners and when you do you end up plastered all over the road.

zabzonk 7y ago
[neilb@Miranda temp]$ gcc -Wall -Wextra -pedantic a.c a.c:2:6: warning: ISO C forbids zero-size array 'outputs' [-Wpedantic] char outputs[OUTPUTS] = { };
- jacquesm 7y ago
  Yes, the -pedantic is what will trigger that. See linked post. But that's not on by default (fortunately!). ISO C is so restrictive ;)
  - zabzonk 7y ago
    > (fortunately!) Unfortunately. All warnings and errors should be on by default. That they are not is one of the things about GCC that really pisses me off.
    - jacquesm 7y ago
      Still not getting the joke. Yes, they should be on, in fact GCC should not do this, 'extensions' to a language that invite undefined behavior are not in line with solid software development practices. Neither is brainfuck...
      - mikepurvis 7y ago
        I feel obliged to point out that some of those extensions a) are pretty important for large scale projects, and b) end up standardized later on anyway— eg variadic macros being added in C99. Definitely a case to be made that the default behaviour should be what the standard says, with extensions as an opt-in. But experimental extensions also move the language forward.
        codetrotter 7y ago
        I guess what jacquesm was getting at was that instead of extending C, the world should have left C behind a long time ago and transitioned to other, safer languages. These days there are excellent alternatives to C, but of course we also have vast codebases written in C that would be too big of an undertaking and too much of a risk to rewrite in a safer language. There may not have been any sufficiently widespread alternative in the past in terms of developer mindshare, and sufficiently performant considering how limited the hardware was in terms of both speed and memory and storage. There is also the issue of portability and of embedded platforms, and that remains problematic to this day in some cases but in other cases the possibilities for using safer languages are already really good. Even in cases where an alternative was known and suitable, people in the past had legacy codebases that they were working with too that they didn't want to risk rewriting in any other language. So they just kept adding to the code that they had. The legacy-code that we are sitting on now is so many lines of code that one might wonder, was it even justified that they didn't want to take on the risk of rewriting the code in the past, while there still was a chance to do it all in one go? Maybe, maybe not. Either way, we can do nothing about the past, but if we keep growing the legacy codebases, the problem only gets bigger in the future. We should not strive to rewrite it all at once, but we should use safer languages when we extend our codebases, and we should use safer languages when we start new projects. Every line of code that we write today adds to the amount of code that will make up the legacy code of tomorrow. Let's strive to make the legacy code of the future safer, so that our children may run their societies on safer software!
james_s_tayler 7y ago
Isn't countering the G-force when cornering to keep your head straight the equivalent of lifting 25kgs with your neck? C sounds like one hell of a ride.
dsfyu404ed 7y ago
>one of those things that C is renowned and notorious for: something that is useful at times but unpredictable because it is flirting with undefined behavior. This describes all the stuff that makes C useful.

deleted 7y ago

[deleted]

shultays 7y ago

what it is being used for? I can't figure what that fwrite part does

YSFEJ4SWJUVU6 7y ago
That fwrite writes the contents of output to stdout. output probably contains all the output that doesn't depend on input (which this program doesn't have).