Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #397990 > unrolled thread
| Started by | John Forkosh <forkosh@panix.com> |
|---|---|
| First post | 2026-04-26 13:59 +0000 |
| Last post | 2026-04-26 16:56 +0000 |
| Articles | 20 on this page of 122 — 16 participants |
Back to article view | Back to comp.lang.c
function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 13:59 +0000
Re: function declaration without args no longer works Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-04-26 16:24 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:29 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-04 19:36 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 00:15 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 09:10 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-05-05 11:17 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 11:07 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 02:24 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 11:20 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 18:09 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-07 12:52 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 14:51 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 11:41 +0200
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 10:03 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-07 12:35 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 07:36 -0700
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-05-08 18:39 +0000
Re: function declaration without args no longer works richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-04-26 14:32 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:35 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:43 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:39 +0200
Re: function declaration without args no longer works Michael S <already5chosen@yahoo.com> - 2026-04-26 17:50 +0300
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:39 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-27 00:30 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-27 08:30 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-28 07:02 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 10:16 +0200
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-04-28 15:33 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 20:24 +0200
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-04-28 20:22 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-29 06:22 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 09:15 +0200
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-29 10:06 +0200
Re: function declaration without args no longer works Michael S <already5chosen@yahoo.com> - 2026-04-29 11:25 +0300
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 11:26 +0200
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 20:07 -0400
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 00:14 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-29 17:57 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-30 03:09 +0200
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 00:48 -0700
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 20:18 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-01 04:12 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 23:29 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-01 19:31 +0200
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-01 13:49 -0400
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 12:49 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-01 22:31 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 00:13 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 19:27 -0700
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 19:28 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 03:07 +0000
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-05-02 16:16 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 01:39 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 00:38 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 03:07 -0700
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 05:54 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:32 -0700
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-30 09:45 -0400
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 12:48 -0700
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-29 11:05 +0100
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:32 -0700
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 01:22 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-29 10:42 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 14:31 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:42 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-30 13:17 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:40 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 22:14 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-29 18:55 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-29 21:19 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:46 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 14:25 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 13:13 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 15:48 +0200
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-28 15:05 +0100
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 16:37 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-28 14:02 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 09:29 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 02:49 -0700
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 20:06 -0400
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 17:13 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 00:45 +0000
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 21:11 -0400
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 01:40 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 20:09 -0700
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-04-30 14:57 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 15:07 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-30 16:20 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 16:10 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-30 17:48 +0100
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 22:31 +0200
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 22:18 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 00:25 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 00:08 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 01:24 +0100
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 17:46 -0700
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 01:55 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 10:48 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 11:20 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 20:23 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-05-01 10:32 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:43 -0700
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 22:34 +0000
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-01 13:32 -0400
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-05-01 18:12 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-30 03:50 +0200
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:52 +0200
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-28 14:56 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-28 15:41 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-29 21:20 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 17:14 +0200
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 17:31 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 19:06 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 21:44 +0200
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 17:06 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 19:23 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-26 17:35 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:50 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:52 -0700
Re: function declaration without args no longer works Andrey Tarasevich <noone@noone.net> - 2026-04-26 08:38 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:56 +0000
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-26 13:59 +0000 |
| Subject | function declaration without args no longer works |
| Message-ID | <10sl5na$5ov$1@reader1.panix.com> |
New slackware install with gcc --version 15.2.0 throws
errors like
typer.c:9:3: error: too many arguments to function typer; expected 0, have 1
9 | typer(input);
| ^~~~~ ~~~~~
when compiling a program that used to compile without warnings
(even when using --pedantic) on earlier versions.
Here's a "minimum working example"...
#include <stdio.h>
int main ( int argc, char *argv[] ) {
char *input = (argc<2? "no input" : argv[1]);
#if defined(WORKS)
int typer(char *);
#else
int typer();
#endif
typer(input);
return(0); }
int typer ( char *input ) {
printf("Your input was: %s\n",input);
return(0); }
Note that typer() takes one char * arg,
but is declared as int typer() in main()
with no args when compiled as gcc typer.c -o typer
And that worked fine on earlier gcc versions.
But now it throws those errors.
However, when compiled as gcc -DWORKS typer.c -o typer
which declares int typer(char *) with its arg,
then it works, of course.
I've got lots of code that declares functions
without their args, and that compiled fine for
years and years, but now throws those errors.
Is there some gcc -switch (or --switch or whatever)
that will ignore that "error" without rewriting
anything? Thanks,
--
John Forkosh
[toc] | [next] | [standalone]
| From | Michael Bäuerle <michael.baeuerle@gmx.net> |
|---|---|
| Date | 2026-04-26 16:24 +0200 |
| Message-ID | <AABp7iAw8kQAAAp3.A3.flnews@WStation7.micha.freeshell.org> |
| In reply to | #397990 |
John Forkosh wrote: > > New slackware install with gcc --version 15.2.0 throws > errors like > typer.c:9:3: error: too many arguments to function typer; expected 0, have 1 > 9 | typer(input); > | ^~~~~ ~~~~~ > when compiling a program that used to compile without warnings > (even when using --pedantic) on earlier versions. > > Here's a "minimum working example"... > [...] > > Note that typer() takes one char * arg, > but is declared as int typer() in main() > with no args when compiled as gcc typer.c -o typer > And that worked fine on earlier gcc versions. > But now it throws those errors. > However, when compiled as gcc -DWORKS typer.c -o typer > which declares int typer(char *) with its arg, > then it works, of course. > > I've got lots of code that declares functions > without their args, and that compiled fine for > years and years, but now throws those errors. > Is there some gcc -switch (or --switch or whatever) > that will ignore that "error" without rewriting > anything? Thanks, Have you tried "-std=c99" (or whatever standard your code was written for)?
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-26 16:29 +0000 |
| Message-ID | <10slehr$mho$1@reader1.panix.com> |
| In reply to | #397991 |
Michael B?uerle <michael.baeuerle@gmx.net> wrote: > John Forkosh wrote: > > Have you tried "-std=c99" (or whatever standard > your code was written for)? Thanks, Michael. I've tried it now:) Indeed, as soon as I saw your "-std=" I vaguely recalled that switch. Unfortunately, I hadn't noticed it while munging through the man gcc page before posting this question. And, yeah, both -std=c99 and (as also suggested) -std=gnu17 ignore the problem, and compile just fine (i.e., compile my actual programs, as well as the posted mwe).... at least for now <insert ominous music> Guess I'll eventually have to go back and clean up all that stuff. Not looking forward to it. And (as mentioned elsewheres) explicitly saying -std=gnu23 reproduces all errors, as expected. Thanks again. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-04 19:36 +0000 |
| Message-ID | <10tasgg$7nu$1@reader1.panix.com> |
| In reply to | #398000 |
John Forkosh <forkosh@panix.com> wrote: > Michael B?uerle <michael.baeuerle@gmx.net> wrote: >> John Forkosh wrote: >> >> Have you tried "-std=c99" (or whatever standard >> your code was written for)? > > Thanks, Michael. I've tried it now:) Indeed, as soon > as I saw your "-std=" I vaguely recalled that switch. > And, yeah, both -std=c99 and (as also suggested) > -std=gnu17 ignore the problem, and compile just fine > Thanks again. Update: While subsequently trying to compile some even older code, written circa 1991, I had to go back even further, to -std=c89 (or equivalently -ansi as per the man cc page). And then, no errors, no warnings, not even with -pedantic. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-05 00:15 -0700 |
| Message-ID | <86zf2ewcm8.fsf@linuxsc.com> |
| In reply to | #398308 |
John Forkosh <forkosh@panix.com> writes: > John Forkosh <forkosh@panix.com> wrote: > >> Michael B?uerle <michael.baeuerle@gmx.net> wrote: >> >>> John Forkosh wrote: >>> >>> Have you tried "-std=c99" (or whatever standard >>> your code was written for)? >> >> Thanks, Michael. I've tried it now:) Indeed, as soon >> as I saw your "-std=" I vaguely recalled that switch. >> And, yeah, both -std=c99 and (as also suggested) >> -std=gnu17 ignore the problem, and compile just fine >> Thanks again. > > Update: While subsequently trying to compile some even older > code, written circa 1991, I had to go back even further, > to -std=c89 (or equivalently -ansi as per the man cc page). > And then, no errors, no warnings, not even with -pedantic. What were the sorts of things that caused diagnostics when compiled under -std=c99?
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-05 09:10 +0000 |
| Message-ID | <10tcc5j$e45$1@reader1.panix.com> |
| In reply to | #398342 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> John Forkosh <forkosh@panix.com> writes:
>> John Forkosh <forkosh@panix.com> wrote:
>>> Michael B?uerle <michael.baeuerle@gmx.net> wrote:
>>>> John Forkosh wrote:
>>>>
>>>> Have you tried "-std=c99" (or whatever standard
>>>> your code was written for)?
>>>
>>> Thanks, Michael. I've tried it now:) Indeed, as soon
>>> as I saw your "-std=" I vaguely recalled that switch.
>>> And, yeah, both -std=c99 and (as also suggested)
>>> -std=gnu17 ignore the problem, and compile just fine
>>> Thanks again.
>>
>> Update: While subsequently trying to compile some even older
>> code, written circa 1991, I had to go back even further,
>> to -std=c89 (or equivalently -ansi as per the man cc page).
>> And then, no errors, no warnings, not even with -pedantic.
>
> What were the sorts of things that caused diagnostics when
> compiled under -std=c99?
Three errors (identical with or without -pedantic)...
bash-5.3$ cc -DTESTDRIVE -DNOTMSDOS -std=c99 -pedantic -lm treelib.c -o treelib
treelib.c: In function 'talloc':
treelib.c:205:11: error: implicit declaration of function 'tallchk' [-Wimplicit-function-declaration]
205 | if ( !tallchk() ) tree=(double *)NULL; /* set error if corrupt */
| ^~~~~~~
treelib.c: At top level:
treelib.c:1986:1: error: return type defaults to 'int' [-Wimplicit-int]
1986 | main ( argc, argv )
| ^~~~
treelib.c: In function 'main':
treelib.c:2149:29: error: implicit declaration of function 'close'; did you mean 'fclose'? [-Wimplicit-function-declaration]
2149 | if ( fp != (FILE *)NULL ) close(fp); /* close output file */
| ^~~~~
| fclose
... at line 205, I indeed used tallchk() without declaring it
within the talloc() function where it's used.
at line 1986, I indeed wrote main() instead of int main().
at line 2149, I indeed meant fclose().
A little sloppier of me than I usually am (or maybe than I like
to think I usually am). But code has a good deal of slop and
#ifdef stuff because it had to simultaneously compile and run
on PCs under msdos, DECstation 5000 and Apollo 10000 under Unix,
and VAX 11/780 under VMS. And it was even expected to give
identical results.
That last one might have caused problems, but never did.
treelib.c only compiles main() when compiled with cc -DTESTDRIVE,
and then output goes to stdout unless you explicitly tell it
a filename when running it, i.e., ./treelib #periods [outputfile]
I typically tested onscreen, but, hmmm, when testing it now
with a filename, it nevertheless works fine, without throwing
any errors at eoj when it calls close(). And the code
doesn't #include <unistd.h> and it does call close() with
a FILE *fp rather than an int fd.
--
John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-05 11:17 +0200 |
| Message-ID | <10tccjt$7oav$8@dont-email.me> |
| In reply to | #398354 |
On 05/05/2026 11:10, John Forkosh wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> John Forkosh <forkosh@panix.com> writes: >>> John Forkosh <forkosh@panix.com> wrote: >>>> Michael B?uerle <michael.baeuerle@gmx.net> wrote: >>>>> John Forkosh wrote: >>>>> >>>>> Have you tried "-std=c99" (or whatever standard >>>>> your code was written for)? >>>> >>>> Thanks, Michael. I've tried it now:) Indeed, as soon >>>> as I saw your "-std=" I vaguely recalled that switch. >>>> And, yeah, both -std=c99 and (as also suggested) >>>> -std=gnu17 ignore the problem, and compile just fine >>>> Thanks again. >>> >>> Update: While subsequently trying to compile some even older >>> code, written circa 1991, I had to go back even further, >>> to -std=c89 (or equivalently -ansi as per the man cc page). >>> And then, no errors, no warnings, not even with -pedantic. >> >> What were the sorts of things that caused diagnostics when >> compiled under -std=c99? > > Three errors (identical with or without -pedantic)... > > bash-5.3$ cc -DTESTDRIVE -DNOTMSDOS -std=c99 -pedantic -lm treelib.c -o treelib > treelib.c: In function 'talloc': > treelib.c:205:11: error: implicit declaration of function 'tallchk' [-Wimplicit-function-declaration] > 205 | if ( !tallchk() ) tree=(double *)NULL; /* set error if corrupt */ > | ^~~~~~~ > treelib.c: At top level: > treelib.c:1986:1: error: return type defaults to 'int' [-Wimplicit-int] > 1986 | main ( argc, argv ) > | ^~~~ > treelib.c: In function 'main': > treelib.c:2149:29: error: implicit declaration of function 'close'; did you mean 'fclose'? [-Wimplicit-function-declaration] > 2149 | if ( fp != (FILE *)NULL ) close(fp); /* close output file */ > | ^~~~~ > | fclose > > ... at line 205, I indeed used tallchk() without declaring it > within the talloc() function where it's used. > at line 1986, I indeed wrote main() instead of int main(). > at line 2149, I indeed meant fclose(). > A little sloppier of me than I usually am (or maybe than I like > to think I usually am). But code has a good deal of slop and > #ifdef stuff because it had to simultaneously compile and run > on PCs under msdos, DECstation 5000 and Apollo 10000 under Unix, > and VAX 11/780 under VMS. And it was even expected to give > identical results. > > That last one might have caused problems, but never did. > treelib.c only compiles main() when compiled with cc -DTESTDRIVE, > and then output goes to stdout unless you explicitly tell it > a filename when running it, i.e., ./treelib #periods [outputfile] > I typically tested onscreen, but, hmmm, when testing it now > with a filename, it nevertheless works fine, without throwing > any errors at eoj when it calls close(). And the code > doesn't #include <unistd.h> and it does call close() with > a FILE *fp rather than an int fd. These should be easy to correct, if they are the only occurrences. Implicit int (as a function return type, or as a type for variables) and implicit function declaration were both deprecated or obsolescent in C90 (I don't remember which). Neither of them have ever been a good idea to have in code. But if you want to compile with -std=c99 without changing your code, you can just add "-Wno-implicit-int -Wno-implicit-function-declaration" to disable these warnings. (I don't recommend it - I'd encourage fixing the code - but only you can decide what suits your needs best.)
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-05 11:07 +0000 |
| Message-ID | <10tcj0l$fo3$1@reader1.panix.com> |
| In reply to | #398356 |
David Brown <david.brown@hesbynett.no> wrote: > > These should be easy to correct, Indeed. I could do it with my eyes closed. > if they are the only occurrences. Indeed not. That one project alone, where the binomial (not binary) tree library was the only program file I illustrated, actually consists of... -rw-r--r-- 1 forkosh users 8593 Dec 23 1991 cashflow.c -rw-r--r-- 1 forkosh users 5198 Jan 29 1992 cpricer.c -rw-r--r-- 1 forkosh users 47323 Aug 29 1992 datelib.c -rw-r--r-- 1 forkosh users 3699 Sep 28 1991 dosheap.c -rw-r--r-- 1 forkosh users 5473 Feb 20 1992 fpricer.c -rw-r--r-- 1 forkosh users 15869 Jan 29 1992 getfndat.c -rw-r--r-- 1 forkosh users 110145 Nov 9 1992 gettoken.c -rw-r--r-- 1 forkosh users 38165 Mar 13 1992 gettrdat.c -rw-r--r-- 1 forkosh users 7070 Apr 15 1992 interp.c -rw-r--r-- 1 forkosh users 42538 Oct 22 1991 isbusday.c -rw-r--r-- 1 forkosh users 16496 Aug 29 1992 mortdata.c -rw-r--r-- 1 forkosh users 5478 Oct 31 1991 mtools.c -rw-r--r-- 1 forkosh users 14356 May 21 1992 oasfnma.c -rw-r--r-- 1 forkosh users 26498 Oct 7 1992 pipefe.c -rw-r--r-- 1 forkosh users 20792 May 29 1999 pipeline.c -rw-r--r-- 1 forkosh users 60081 Aug 28 1992 poolflow.c -rw-r--r-- 1 forkosh users 108486 Oct 11 1992 poollib.c -rw-r--r-- 1 forkosh users 35869 Aug 29 1992 prcdeal.c -rw-r--r-- 1 forkosh users 10232 Apr 15 1992 prcfnma.c -rw-r--r-- 1 forkosh users 13555 May 21 1992 prconly.c -rw-r--r-- 1 forkosh users 16960 Mar 27 1992 prctree.c -rw-r--r-- 1 forkosh users 17063 Jan 29 1992 prczero.c -rw-r--r-- 1 forkosh users 50159 Feb 27 1992 preptree.c -rw-r--r-- 1 forkosh users 13476 Mar 31 1992 rateconv.c -rw-r--r-- 1 forkosh users 5011 Jan 16 1992 rb.c -rw-r--r-- 1 forkosh users 6236 Oct 31 1991 rbyvc.c -rw-r--r-- 1 forkosh users 2085 Oct 31 1991 secant.c -rw-r--r-- 1 forkosh users 7993 Sep 21 1991 setsmm.c -rw-r--r-- 1 forkosh users 8039 Jan 29 1992 skedflow.c -rw-r--r-- 1 forkosh users 15095 Jan 29 1992 srembal.c -rw-r--r-- 1 forkosh users 5871 Jan 14 1992 timelib.c -rw-r--r-- 1 forkosh users 10556 Mar 31 1992 toasdisc.c -rw-r--r-- 1 forkosh users 3042 Oct 8 1992 toktest.c -rw-r--r-- 1 forkosh users 24814 Aug 29 1992 treeinit.c -rw-r--r-- 1 forkosh users 102048 Feb 14 2015 treelib.c -rw-r--r-- 1 forkosh users 16047 Jan 29 1992 twings.c -rw-r--r-- 1 forkosh users 35669 Jul 22 1992 varparse.c -rw-r--r-- 1 forkosh users 785 Jul 23 1992 vbktest.c -rw-r--r-- 1 forkosh users 10240 Oct 31 1991 yc.c -rw-r--r-- 1 forkosh users 37167 Oct 9 1992 zerotree.c -rw-r--r-- 1 forkosh users 4674 Mar 4 1992 gettoken.h -rw-r--r-- 1 forkosh users 547 Sep 18 1991 interp.h -rw-r--r-- 1 forkosh users 2253 Sep 16 1991 mortdat.h -rw-r--r-- 1 forkosh users 5020 Apr 15 1992 msglevel.h -rw-r--r-- 1 forkosh users 1330 Dec 19 1991 mtools.h -rw-r--r-- 1 forkosh users 5947 Oct 7 1992 pooldata.h -rw-r--r-- 1 forkosh users 2056 Oct 31 1991 rb.h -rw-r--r-- 1 forkosh users 2733 Sep 18 1991 rberr.h -rw-r--r-- 1 forkosh users 1365 Sep 18 1991 rbyvc.h -rw-r--r-- 1 forkosh users 636 Sep 18 1991 secant.h -rw-r--r-- 1 forkosh users 3340 May 29 1999 treelib.h -rw-r--r-- 1 forkosh users 3634 Jul 22 1992 varparse.h -rw-r--r-- 1 forkosh users 3611 Oct 31 1991 yc.h -rw-r--r-- 1 forkosh users 1885 Oct 31 1991 yctimes.h ...and seems to be working, reproducing test data results from original 1990's testing. Want to see those data files, too?... -rw-r--r-- 1 forkosh users 1112 Feb 6 1992 aa.dat -rw-r--r-- 1 forkosh users 243 Feb 6 1992 aa_assum.dat -rw-r--r-- 1 forkosh users 4208 Mar 5 1992 adolfo.dat -rw-r--r-- 1 forkosh users 2728 Mar 16 1992 adolfo2.dat -rw-r--r-- 1 forkosh users 5196 Oct 16 1991 datefile.dat -rw-r--r-- 1 forkosh users 350 May 7 1992 deal.dat -rw-r--r-- 1 forkosh users 660 May 7 1992 deal1.dat -rw-r--r-- 1 forkosh users 577 May 7 1992 deal2.dat -rw-r--r-- 1 forkosh users 350 May 7 1992 dealf117.dat -rw-r--r-- 1 forkosh users 4792 Nov 1 1999 f117.dat -rw-r--r-- 1 forkosh users 623 Mar 17 1992 fallout.dat -rw-r--r-- 1 forkosh users 623 Mar 17 1992 fallouta.dat -rw-r--r-- 1 forkosh users 1174 Mar 18 1992 falloutr.dat -rw-r--r-- 1 forkosh users 1090 Mar 17 1992 falloutt.dat -rw-r--r-- 1 forkosh users 274 Apr 23 1992 fnma.dat -rw-r--r-- 1 forkosh users 660 Mar 13 1992 fnma1.dat -rw-r--r-- 1 forkosh users 913 Mar 9 1992 fnma2.dat -rw-r--r-- 1 forkosh users 199 Sep 10 1991 fnma_age.dat -rw-r--r-- 1 forkosh users 2328 Oct 7 1991 fnma_spr.dat -rw-r--r-- 1 forkosh users 274 Apr 23 1992 fnmaf117.dat -rw-r--r-- 1 forkosh users 1052 Mar 18 1992 frm1.dat -rw-r--r-- 1 forkosh users 803 Dec 5 1991 gettoken.dat -rw-r--r-- 1 forkosh users 2041 Oct 7 1991 gnma_spr.dat -rw-r--r-- 1 forkosh users 7055 Mar 20 1992 locked.dat -rw-r--r-- 1 forkosh users 1575 May 21 1992 pip1992g.dat -rw-r--r-- 1 forkosh users 1498 May 28 1992 pip1992h.dat -rw-r--r-- 1 forkosh users 17462 Oct 11 1992 pip1992l.dat -rw-r--r-- 1 forkosh users 1923 Oct 8 1992 piptest1.dat -rw-r--r-- 1 forkosh users 7602 Oct 11 1992 piptest2.dat -rw-r--r-- 1 forkosh users 701 May 7 1992 pool.dat -rw-r--r-- 1 forkosh users 1558 May 7 1992 pool1.dat -rw-r--r-- 1 forkosh users 3528 May 7 1992 pool2.dat -rw-r--r-- 1 forkosh users 701 May 7 1992 poolf117.dat -rw-r--r-- 1 forkosh users 601 Feb 6 1992 prodinp.dat -rw-r--r-- 1 forkosh users 117 Feb 6 1992 progopts.dat -rw-r--r-- 1 forkosh users 10442 Mar 3 1992 sample.dat -rw-r--r-- 1 forkosh users 535 Jan 28 1992 tr010292.dat -rw-r--r-- 1 forkosh users 466 May 21 1992 tr041392.dat -rw-r--r-- 1 forkosh users 466 Nov 26 1991 tr041591.dat -rw-r--r-- 1 forkosh users 513 Apr 23 1992 tr042192.dat -rw-r--r-- 1 forkosh users 466 Nov 26 1991 tr073191.dat -rw-r--r-- 1 forkosh users 466 Sep 18 1991 tr091791.dat -rw-r--r-- 1 forkosh users 466 Oct 5 1992 tr092892.dat -rw-r--r-- 1 forkosh users 638 Mar 10 1992 tr110691.dat So, no, I'm not going to mess around with it any more than necessary to keep it sensible. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-05 02:24 -0700 |
| Message-ID | <10tcd0u$a3j4$1@kst.eternal-september.org> |
| In reply to | #398354 |
John Forkosh <forkosh@panix.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>> John Forkosh <forkosh@panix.com> wrote:
>>>> Michael B?uerle <michael.baeuerle@gmx.net> wrote:
>>>>> Have you tried "-std=c99" (or whatever standard
>>>>> your code was written for)?
>>>>
>>>> Thanks, Michael. I've tried it now:) Indeed, as soon
>>>> as I saw your "-std=" I vaguely recalled that switch.
>>>> And, yeah, both -std=c99 and (as also suggested)
>>>> -std=gnu17 ignore the problem, and compile just fine
>>>> Thanks again.
>>>
>>> Update: While subsequently trying to compile some even older
>>> code, written circa 1991, I had to go back even further,
>>> to -std=c89 (or equivalently -ansi as per the man cc page).
>>> And then, no errors, no warnings, not even with -pedantic.
>>
>> What were the sorts of things that caused diagnostics when
>> compiled under -std=c99?
>
> Three errors (identical with or without -pedantic)...
>
> bash-5.3$ cc -DTESTDRIVE -DNOTMSDOS -std=c99 -pedantic -lm treelib.c -o treelib
> treelib.c: In function 'talloc':
> treelib.c:205:11: error: implicit declaration of function 'tallchk' [-Wimplicit-function-declaration]
> 205 | if ( !tallchk() ) tree=(double *)NULL; /* set error if corrupt */
> | ^~~~~~~
> treelib.c: At top level:
> treelib.c:1986:1: error: return type defaults to 'int' [-Wimplicit-int]
> 1986 | main ( argc, argv )
> | ^~~~
> treelib.c: In function 'main':
> treelib.c:2149:29: error: implicit declaration of function 'close'; did you mean 'fclose'? [-Wimplicit-function-declaration]
> 2149 | if ( fp != (FILE *)NULL ) close(fp); /* close output file */
> | ^~~~~
> | fclose
>
> ... at line 205, I indeed used tallchk() without declaring it
> within the talloc() function where it's used.
> at line 1986, I indeed wrote main() instead of int main().
> at line 2149, I indeed meant fclose().
> A little sloppier of me than I usually am (or maybe than I like
> to think I usually am). But code has a good deal of slop and
> #ifdef stuff because it had to simultaneously compile and run
> on PCs under msdos, DECstation 5000 and Apollo 10000 under Unix,
> and VAX 11/780 under VMS. And it was even expected to give
> identical results.
>
> That last one might have caused problems, but never did.
> treelib.c only compiles main() when compiled with cc -DTESTDRIVE,
> and then output goes to stdout unless you explicitly tell it
> a filename when running it, i.e., ./treelib #periods [outputfile]
> I typically tested onscreen, but, hmmm, when testing it now
> with a filename, it nevertheless works fine, without throwing
> any errors at eoj when it calls close(). And the code
> doesn't #include <unistd.h> and it does call close() with
> a FILE *fp rather than an int fd.
If the code were going to be maintained, I suggest that upgrading it
to C99 would make it more stable (modulo the instability if making
any changes at all to existing code).
Missing return types and implicit declarations are easy enough to
fix, and the code is still compatible with C90.
The close() error is interesting.
close(), a POSIX function, takes an int argument, a small integer
value that's a file descriptor. If you declare it incorrectly
(or not at all) and call it with a FILE* argument, it's likely the
pointer value will be interpreted as a very large integer which
will not be a valid file descriptor. I just tried it, and close()
returned -1 and set errno to EBADF. If you don't check the return
value, most likely the close() call will do nothing and the file
will be closed when the program terminates. Other than output not
being flushed immediately, it might not cause any real problems.
But it's still an error worth fixing (again, assuming that the
program is still worth maintaining; otherwise let it rest in peace).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-05 11:20 +0000 |
| Message-ID | <10tcjp4$iaa$1@reader1.panix.com> |
| In reply to | #398357 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > If the code were going to be maintained, I suggest that upgrading it > to C99 would make it more stable (modulo the instability if making > any changes at all to existing code). Maintained, yes. Upgrading, no -- see preceding followup to David Brown. > The close() error is interesting. > [...] it's likely the pointer value will be interpreted as > a very large integer which will not be a valid file descriptor. > I just tried it, and close() returned -1 and set errno to EBADF. > If you don't check the return value, most likely the close() call > will do nothing and the file will be closed when the program terminates. Yup, sounds/looks/feels like that's precisely what happened. > Other than output not being flushed immediately, it might not cause > any real problems. But it's still an error worth fixing (again, > assuming that the program is still worth maintaining; otherwise > let it rest in peace). Still needs to work, but fixing that kind of problem, where that piece of code is never even executed (unless that module is compiled by itself with -DTESTDRIVE) not going to happen. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-05 18:09 +0000 |
| Message-ID | <10tdbor$5uj$2@reader1.panix.com> |
| In reply to | #398357 |
In article <10tcd0u$a3j4$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >John Forkosh <forkosh@panix.com> writes: >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> John Forkosh <forkosh@panix.com> writes: >>>> John Forkosh <forkosh@panix.com> wrote: >>>>> Michael B?uerle <michael.baeuerle@gmx.net> wrote: >>>>>> Have you tried "-std=c99" (or whatever standard >>>>>> your code was written for)? >>>>> >>>>> Thanks, Michael. I've tried it now:) Indeed, as soon >>>>> as I saw your "-std=" I vaguely recalled that switch. >>>>> And, yeah, both -std=c99 and (as also suggested) >>>>> -std=gnu17 ignore the problem, and compile just fine >>>>> Thanks again. >>>> >>>> Update: While subsequently trying to compile some even older >>>> code, written circa 1991, I had to go back even further, >>>> to -std=c89 (or equivalently -ansi as per the man cc page). >>>> And then, no errors, no warnings, not even with -pedantic. >>> >>> What were the sorts of things that caused diagnostics when >>> compiled under -std=c99? >> >> Three errors (identical with or without -pedantic)... >> >> bash-5.3$ cc -DTESTDRIVE -DNOTMSDOS -std=c99 -pedantic -lm treelib.c -o treelib >> treelib.c: In function 'talloc': >> treelib.c:205:11: error: implicit declaration of function 'tallchk' [-Wimplicit-function-declaration] >> 205 | if ( !tallchk() ) tree=(double *)NULL; /* set error if corrupt */ >> | ^~~~~~~ >> treelib.c: At top level: >> treelib.c:1986:1: error: return type defaults to 'int' [-Wimplicit-int] >> 1986 | main ( argc, argv ) >> | ^~~~ >> treelib.c: In function 'main': >> treelib.c:2149:29: error: implicit declaration of function 'close'; did you mean 'fclose'? [-Wimplicit-function-declaration] >> 2149 | if ( fp != (FILE *)NULL ) close(fp); /* close output file */ >> | ^~~~~ >> | fclose >> >> ... at line 205, I indeed used tallchk() without declaring it >> within the talloc() function where it's used. >> at line 1986, I indeed wrote main() instead of int main(). >> at line 2149, I indeed meant fclose(). >> A little sloppier of me than I usually am (or maybe than I like >> to think I usually am). But code has a good deal of slop and >> #ifdef stuff because it had to simultaneously compile and run >> on PCs under msdos, DECstation 5000 and Apollo 10000 under Unix, >> and VAX 11/780 under VMS. And it was even expected to give >> identical results. >> >> That last one might have caused problems, but never did. >> treelib.c only compiles main() when compiled with cc -DTESTDRIVE, >> and then output goes to stdout unless you explicitly tell it >> a filename when running it, i.e., ./treelib #periods [outputfile] >> I typically tested onscreen, but, hmmm, when testing it now >> with a filename, it nevertheless works fine, without throwing >> any errors at eoj when it calls close(). And the code >> doesn't #include <unistd.h> and it does call close() with >> a FILE *fp rather than an int fd. > >If the code were going to be maintained, I suggest that upgrading it >to C99 would make it more stable (modulo the instability if making >any changes at all to existing code). > >Missing return types and implicit declarations are easy enough to >fix, and the code is still compatible with C90. > >The close() error is interesting. > >close(), a POSIX function, takes an int argument, a small integer >value that's a file descriptor. If you declare it incorrectly >(or not at all) and call it with a FILE* argument, it's likely the >pointer value will be interpreted as a very large integer which >will not be a valid file descriptor. I just tried it, and close() >returned -1 and set errno to EBADF. If you don't check the return >value, most likely the close() call will do nothing and the file >will be closed when the program terminates. Other than output not >being flushed immediately, it might not cause any real problems. It's a resource leak. Likely harmless in this case, since this code is (apparently?) in a test harness and this is the only file pointer in question, but more generally file descriptors are a scarce resource compared to, say, RAM, and a bug like this could have real consequences if too many are open at one time. >But it's still an error worth fixing (again, assuming that the >program is still worth maintaining; otherwise let it rest in peace). Amen. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-07 12:52 +0000 |
| Message-ID | <10ti1tr$99t$1@reader1.panix.com> |
| In reply to | #398384 |
Dan Cross <cross@spitfire.i.gajendra.net> wrote: [...] > It's a resource leak. Likely harmless in this case, since this > code is (apparently?) in a test harness and this is the only > file pointer in question, but more generally file descriptors > are a scarce resource compared to, say, RAM, and a bug like this > could have real consequences if too many are open at one time. None were open. close(fp) at eoj (mis-)matched earlier fp=fopen(argv[2],"w"). close rather than fclose was just a typo. I haven't even bothered to fix it (though I will, along with any actual functional change, if that's ever needed or requested -- not very likely). >>But it's still an error worth fixing (again, assuming that the >>program is still worth maintaining; otherwise let it rest in peace). > > Amen. - Dan C. Suggestion: find some better stuff to pray about. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-07 14:51 +0000 |
| Message-ID | <10ti8tl$252$2@reader1.panix.com> |
| In reply to | #398442 |
In article <10ti1tr$99t$1@reader1.panix.com>, John Forkosh <forkosh@panix.com> wrote: >Dan Cross <cross@spitfire.i.gajendra.net> wrote: >[...] >> It's a resource leak. Likely harmless in this case, since this >> code is (apparently?) in a test harness and this is the only >> file pointer in question, but more generally file descriptors >> are a scarce resource compared to, say, RAM, and a bug like this >> could have real consequences if too many are open at one time. > >None were open. close(fp) at eoj (mis-)matched earlier fp=fopen(argv[2],"w"). >close rather than fclose was just a typo. I haven't even bothered to >fix it (though I will, along with any actual functional change, if >that's ever needed or requested -- not very likely). Yeah, it was clear you had simply made a typo. We've all done it. It's not a big deal. My response wasn't targeted at your thing specifically, but touching on the potential effects of not closing files more generally. That is, the, "bug generally..." wasn't specifically about your program. >>>But it's still an error worth fixing (again, assuming that the >>>program is still worth maintaining; otherwise let it rest in peace). >> >> Amen. - Dan C. > >Suggestion: find some better stuff to pray about. Nah, I'm good. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-06 11:41 +0200 |
| Message-ID | <10tf2cu$1gsnu$18@dont-email.me> |
| In reply to | #398357 |
On 2026-05-05 11:24, Keith Thompson wrote:
> [...]
>
> The close() error is interesting.
>
> close(), a POSIX function, takes an int argument, a small integer
> value that's a file descriptor. If you declare it incorrectly
> (or not at all) and call it with a FILE* argument, it's likely the
> pointer value will be interpreted as a very large integer which
> will not be a valid file descriptor.
Or if it's a null-pointer closing "stdin" ('STDIN_FILENO')?
> I just tried it, and close()
> returned -1 and set errno to EBADF. If you don't check the return
> value, most likely the close() call will do nothing and the file
> will be closed when the program terminates. Other than output not
> being flushed immediately, it might not cause any real problems.
> But it's still an error worth fixing (again, assuming that the
> program is still worth maintaining; otherwise let it rest in peace).
Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-05 10:03 -0700 |
| Message-ID | <86ecjpwzye.fsf@linuxsc.com> |
| In reply to | #398354 |
John Forkosh <forkosh@panix.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> John Forkosh <forkosh@panix.com> writes: >> >>> John Forkosh <forkosh@panix.com> wrote: >>> >>>> Michael B?uerle <michael.baeuerle@gmx.net> wrote: >>>> >>>>> John Forkosh wrote: >>>>> >>>>> Have you tried "-std=c99" (or whatever standard >>>>> your code was written for)? >>>> >>>> Thanks, Michael. I've tried it now:) Indeed, as soon >>>> as I saw your "-std=" I vaguely recalled that switch. >>>> And, yeah, both -std=c99 and (as also suggested) >>>> -std=gnu17 ignore the problem, and compile just fine >>>> Thanks again. >>> >>> Update: While subsequently trying to compile some even older >>> code, written circa 1991, I had to go back even further, >>> to -std=c89 (or equivalently -ansi as per the man cc page). >>> And then, no errors, no warnings, not even with -pedantic. >> >> What were the sorts of things that caused diagnostics when >> compiled under -std=c99? > > Three errors (identical with or without -pedantic)... > > bash-5.3$ cc -DTESTDRIVE -DNOTMSDOS -std=c99 -pedantic -lm \ > treelib.c -o treelib > treelib.c: In function 'talloc': > treelib.c:205:11: error: implicit declaration of function 'tallchk' > [-Wimplicit-function-declaration] > 205 | if ( !tallchk() ) tree=(double *)NULL; /* set error if corrupt */ > | ^~~~~~~ > treelib.c: At top level: > treelib.c:1986:1: error: return type defaults to 'int' [-Wimplicit-int] > 1986 | main ( argc, argv ) > | ^~~~ > treelib.c: In function 'main': > treelib.c:2149:29: error: implicit declaration of function 'close'; > did you mean 'fclose'? [-Wimplicit-function-declaration] > 2149 | if ( fp != (FILE *)NULL ) close(fp); /* close output file */ > | ^~~~~ > | fclose > > ... at line 205, I indeed used tallchk() without declaring it > within the talloc() function where it's used. > at line 1986, I indeed wrote main() instead of int main(). > at line 2149, I indeed meant fclose(). > [...] None of these problems is difficult to remedy. Is that also true for the diagnostics you see for other sources? Or are some of them harder to correct? Do you have a breakdown of all the types of flagged constructs in all of the source files (i.e., those that you mention in a later posting)? It would be interesting to know how many bugs would be turned up (e.g., like the close()/fclose() confusion) by compiling with C99 rather than C89/C90.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-05-07 12:35 +0000 |
| Message-ID | <10ti0uk$97m$1@reader1.panix.com> |
| In reply to | #398381 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: [...] > None of these problems is difficult to remedy. Adding two one-digit decimal numbers is easy. Doing it a million times, not so much. > Is that also true for the diagnostics you see for other sources? > Or are some of them harder to correct? All sources that I've looked at used to compile without any errors or -pedantic warnings. I made sure of that when writing them. And now -ansi reproduces that behavior. The problems are themselves all easy, but the fix is often quite laborious. > Do you have a breakdown of all the types of > flagged constructs in all of the source files > (i.e., those that you mention in a later posting)? > > It would be interesting to know how many bugs would be turned up > (e.g., like the close()/fclose() confusion) by compiling with C99 > rather than C89/C90. So many sources, so little time. Don't have enough of the latter to enumerate and document all that. (btw, close/fclose wasn't a confusion; I knew all about that stuff. It must've been a typo.) -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-08 07:36 -0700 |
| Message-ID | <86tssit1co.fsf@linuxsc.com> |
| In reply to | #398441 |
John Forkosh <forkosh@panix.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > [...] > >> Do you have a breakdown of all the types of >> flagged constructs in all of the source files >> (i.e., those that you mention in a later posting)? >> >> It would be interesting to know how many bugs would be turned up >> (e.g., like the close()/fclose() confusion) by compiling with C99 >> rather than C89/C90. > > So many sources, so little time. Don't have enough of the latter > to enumerate and document all that. [...] You should at least be able to compile under C99 and discover the number of errors or warnings in each file. That would be worth knowing. And probably will take 10 minutes or less.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-08 18:39 +0000 |
| Message-ID | <10tlakm$11i9f$2@paganini.bofh.team> |
| In reply to | #398441 |
John Forkosh <forkosh@panix.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> [...]
>> None of these problems is difficult to remedy.
>
> Adding two one-digit decimal numbers is easy.
> Doing it a million times, not so much.
Well, once you can handle single item it is just a loop.
Compute power is now cheap enough that million iterations is
not a problem.
>> Is that also true for the diagnostics you see for other sources?
>> Or are some of them harder to correct?
>
> All sources that I've looked at used to compile without any
> errors or -pedantic warnings. I made sure of that when writing them.
> And now -ansi reproduces that behavior. The problems are themselves
> all easy, but the fix is often quite laborious.
Hmm, there was a tool called 'protoize' which would take program
with K&R declarations and produce a version with ANSI prototypes.
If you needed to compile both with ANSI compiler and pre-ANSI
one it could produce code like:
int
#ifdef _NO_PROTO
addtopath(dir)
char *dir;
#else
addtopath(char *dir)
#endif
{
...
and similar for header file. If you have done this at right
time there would be very little work.
>> Do you have a breakdown of all the types of
>> flagged constructs in all of the source files
>> (i.e., those that you mention in a later posting)?
>>
>> It would be interesting to know how many bugs would be turned up
>> (e.g., like the close()/fclose() confusion) by compiling with C99
>> rather than C89/C90.
>
> So many sources, so little time. Don't have enough of the latter
> to enumerate and document all that. (btw, close/fclose wasn't a
> confusion; I knew all about that stuff. It must've been a typo.)
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2026-04-26 14:32 +0000 |
| Message-ID | <10sl7m8$3du1$1@artemis.inf.ed.ac.uk> |
| In reply to | #397990 |
In article <10sl5na$5ov$1@reader1.panix.com>, John Forkosh <forkosh@panix.com> wrote: >New slackware install with gcc --version 15.2.0 throws >errors like > typer.c:9:3: error: too many arguments to function typer; expected 0, have 1 > 9 | typer(input); > | ^~~~~ ~~~~~ >when compiling a program that used to compile without warnings >(even when using --pedantic) on earlier versions. K&R style function declarations have long been deprecated, and C23 has now disallowed them and re-purposed empty argument lists to mean no arguments. Try specifying some earlier C standard to the compiler. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-26 16:35 +0000 |
| Message-ID | <10slern$mho$2@reader1.panix.com> |
| In reply to | #397993 |
Richard Tobin <richard@cogsci.ed.ac.uk> wrote: > > K&R style function declarations have long been deprecated, and C23 has > now disallowed them and re-purposed empty argument lists to mean no > arguments. Try specifying some earlier C standard to the compiler. > -- Richard Thanks, Richard. As mentioned, that indeed solves the immediate problem. If only I'd been smart enough to avoid stepping into it from the beginning. -- John Forkosh
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web