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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-29 16:43 -0700 |
| Message-ID | <867bpp1gf2.fsf@linuxsc.com> |
| In reply to | #397993 |
richard@cogsci.ed.ac.uk (Richard Tobin) writes: > 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, [...] No, they haven't. Earlier editions of the C standard designated such declarations (and hence also definitions) as obsolescent, not deprecated, and the meaning is very different. In particular, the C standard defines "obsolescent" as "may be considered for removal in a future standard" (wording quoted from memory only). Not "will be removed" but "may be /considered for removal/". And indeed some items designated as obsolescent in earlier standards had their obsolescence-ness removed in a later standard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-30 08:39 +0200 |
| Message-ID | <10sutea$fb9e$1@dont-email.me> |
| In reply to | #398100 |
On 30/04/2026 01:43, Tim Rentsch wrote:
> richard@cogsci.ed.ac.uk (Richard Tobin) writes:
>
>> 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, [...]
>
> No, they haven't. Earlier editions of the C standard designated
> such declarations (and hence also definitions) as obsolescent,
> not deprecated, and the meaning is very different. In particular,
> the C standard defines "obsolescent" as "may be considered for
> removal in a future standard" (wording quoted from memory only).
> Not "will be removed" but "may be /considered for removal/". And
> indeed some items designated as obsolescent in earlier standards
> had their obsolescence-ness removed in a later standard.
In Annex M "Change History", the changes for C99 include "remove the
deprecation of aliased array parameters". The distinction between
"obsolescent" and "deprecated" is not as clear as you suggest. Neither
marking is irrevocable. The difference is a matter of estimated
timeframe ("deprecated" usually means a plan to remove the feature in
the next standard version, "obsolescent" is without concrete plans).
For practical purposes, the distinction makes no difference to people
writing new code - if a feature is marked "obsolescent" or "deprecated",
you know it is not recommended as good coding practice and that the
feature will likely be removed at some point in the future. It may,
however, influence how you think about updating old code.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-26 17:50 +0300 |
| Message-ID | <20260426175044.000062ff@yahoo.com> |
| In reply to | #397990 |
On Sun, 26 Apr 2026 13:59:06 -0000 (UTC)
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.
>
> 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,
-std=gnu17 will compile your case while retaining majority of modern
language extensions.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-26 16:39 +0000 |
| Message-ID | <10slf3h$mho$3@reader1.panix.com> |
| In reply to | #397994 |
Michael S <already5chosen@yahoo.com> wrote: > > -std=gnu17 will compile your case while retaining majority of modern > language extensions. Yup, compiles fine now. And, as much as possible, I try to write code consistent with K&R2, so don't usually need "modern language extensions". -- John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-27 00:30 +0000 |
| Message-ID | <10smamp$1vlj2$2@dont-email.me> |
| In reply to | #398002 |
On Sun, 26 Apr 2026 16:39:13 -0000 (UTC), John Forkosh wrote: > And, as much as possible, I try to write code consistent with K&R2, > so don't usually need "modern language extensions". That’s just creating work for yourself.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-27 08:30 +0200 |
| Message-ID | <10smvq5$25a7q$2@dont-email.me> |
| In reply to | #398016 |
On 27/04/2026 02:30, Lawrence D’Oliveiro wrote: > On Sun, 26 Apr 2026 16:39:13 -0000 (UTC), John Forkosh wrote: > >> And, as much as possible, I try to write code consistent with K&R2, >> so don't usually need "modern language extensions". > > That’s just creating work for yourself. People can have good and bad reasons for choosing to write to older C standards, though it is unusual to refer specifically to "K&R2". Most often, people say "ANSI C" - inaccurately thinking that means the original ANSI C standard, or basically C90. I have no idea why John chooses K&R2 - I assume he has good reasons for that choice. In my work I see a lot of libraries and code bases that claim "ANSI C" as though it were a badge of merit. I think in many cases, what they are really saying is that someone wrote the code a generation ago, and the current guys don't really understand how it works so they don't dare change things. Typically such code is horrible. It is painfully structured, full of home-made pseudo-standard types like "MY_LIB_UINT32", or "i16", or even "ULONG". "int" instead of bool. Macros instead of static inline functions. #define'd constants instead of enums. Long functions with variables declared at the top. (C90 code does not /have/ to be bad, but it very often is.) And then, in the field of embedded systems, there is often piles of assembly mixed in because the code was written in a time when compilers were weak. (Some assembly can be unavoidable.) IMHO, C99 made C programming a lot nicer - it's easier to write, easier to read, and lets you get more efficient results. C11 adds a few nice things, though nothing too critical (for my usage), and then C23 adds some other convenient features. I can appreciate people not bothering to use C11 onwards, especially if they are writing code that should be usable on a wide variety of compilers, but I find it hard to understand why anyone would actively choose C90 over C99.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-28 07:02 +0000 |
| Message-ID | <10spm2q$5fq$1@reader1.panix.com> |
| In reply to | #398026 |
David Brown <david.brown@hesbynett.no> wrote:
> Lawrence D?Oliveiro wrote:
>> John Forkosh wrote:
>>
>>> And, as much as possible, I try to write code consistent with K&R2,
>>> so don't usually need "modern language extensions".
>>
>> That's just creating work for yourself.
>
> People can have good and bad reasons for choosing to write to older C
> standards, though it is unusual to refer specifically to "K&R2". Most
> often, people say "ANSI C" - inaccurately thinking that means the
> original ANSI C standard, or basically C90. I have no idea why John
> chooses K&R2 - I assume he has good reasons for that choice.
No particular reason for "K&R2" versus "ANSI C". But overall reason
for "older C standard" was (but pretty much no longer is) contract
work on a variety of slightly-weird systems, particularly, for
example, VMS, which can require, e.g., a variety of very non-standard
stuff like
#include <descrip.h>
...
char tabbuf[64]; /* usual declarations */
char *tabnam;
struct dsc$descriptor_s /* required descriptor declarations */
tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
And I found it easier to stick to an older C standard whenever
possible, just to ensure compliance among as many OSs as possible,
across as many different platforms as possible.
Even one-line // comments rather than /* comments */ can be
a problem.
> In my work I see a lot of libraries and code bases that claim "ANSI C"
> as though it were a badge of merit. I think in many cases, what they
> are really saying is that someone wrote the code a generation ago, and
> the current guys don't really understand how it works so they don't dare
> change things.
Yeah, a lot of it is old or very old code, but all of the stuff
I'm talking about was written by me, so I presumably unserstand it.
It's not that I "don't dare change things", it's that things still
work (modulo that -std=gnu17 fix in this case -- thanks again, guys)
and required changes would involve lots and lots of trivial work
with no observable benefit, whereas I'd rather spend my time
more profitably (both $-wise and benefit-wise).
> Typically such code is horrible. It is painfully structured, full of
> home-made pseudo-standard types like "MY_LIB_UINT32", or "i16", or even
> "ULONG". "int" instead of bool. Macros instead of static inline
> functions. #define'd constants instead of enums. Long functions with
> variables declared at the top. (C90 code does not /have/ to be bad, but
> it very often is.)
Personally, I always use int rather than bool, e.g., sometimes I need
a three- or many-valued logic (undetermined typically a third value),
and sometimes not sure what will be needed as development progresses,
even when there's a detailed design document to begin with.
And I'd never #define a name like MY_LIB_UINT32, but often do
#define types, again typically because it's not clear what will
be needed. Indeed, several times what started out as some scalar
type, evolved into a struct, or more simply, sometimes from
a three-component vector into a four-component quaternion.
#define'd types can be very, very, very useful for a wide, wide
variety of reasons. It's always possible to point out a few
silly misuses of anything, but not always helpful in general.
> And then, in the field of embedded systems, there is often piles of
> assembly mixed in because the code was written in a time when compilers
> were weak. (Some assembly can be unavoidable.)
I did a lot of "mixed" assembly & Fortran coding on the IBM/360 series,
simply to speed up heavy numerical work back when computers were slow
and compiler optimization pretty much non-existent. Also some assembly
on PDP-10s and on PDP lab8/es (so the lab8/es could upload collected
laboratory data to the PDP 10 for processing). And also some assembly
on DG MV/8000 and C/330 Nova and Eclipse.
Besides C, Fortran, and several assembly languages, I've also done
some programming in PL/1, Cobol, Basic, and one or two others --
every hear of Jovial (Jules' Own Version of the International
Algorithmic Language)? C does seem to have survived the longest
(Fortran notwithstanding), but I think that focusing solely on
its place in the programming language environment might be too
one-dimensional.
> IMHO, C99 made C programming a lot nicer - it's easier to write, easier
> to read, and lets you get more efficient results. C11 adds a few nice
> things, though nothing too critical (for my usage), and then C23 adds
> some other convenient features. I can appreciate people not bothering
> to use C11 onwards, especially if they are writing code that should be
> usable on a wide variety of compilers, but I find it hard to understand
> why anyone would actively choose C90 over C99.
"Passively", so to speak, chosen, at least by me. So the original post
refers to a lot of old code, and it would be a big pain in the fingers
to go back and fix all the int typer(); kind of stuff just to get it
to compile. -std=gnu17 is a much kinder and gentler (to my fingers)
solution. And having done that, note that everything now compiles and
runs correctly with no further change whatsoever.
--
John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-28 10:16 +0200 |
| Message-ID | <10spqdr$2vs2g$1@dont-email.me> |
| In reply to | #398051 |
On 28/04/2026 09:02, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Lawrence D?Oliveiro wrote:
>>> John Forkosh wrote:
>>>
>>>> And, as much as possible, I try to write code consistent with K&R2,
>>>> so don't usually need "modern language extensions".
>>>
>>> That's just creating work for yourself.
>>
>> People can have good and bad reasons for choosing to write to older C
>> standards, though it is unusual to refer specifically to "K&R2". Most
>> often, people say "ANSI C" - inaccurately thinking that means the
>> original ANSI C standard, or basically C90. I have no idea why John
>> chooses K&R2 - I assume he has good reasons for that choice.
>
> No particular reason for "K&R2" versus "ANSI C". But overall reason
> for "older C standard" was (but pretty much no longer is) contract
> work on a variety of slightly-weird systems, particularly, for
> example, VMS, which can require, e.g., a variety of very non-standard
> stuff like
> #include <descrip.h>
> ...
> char tabbuf[64]; /* usual declarations */
> char *tabnam;
> struct dsc$descriptor_s /* required descriptor declarations */
> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
> And I found it easier to stick to an older C standard whenever
> possible, just to ensure compliance among as many OSs as possible,
> across as many different platforms as possible.
> Even one-line // comments rather than /* comments */ can be
> a problem.
>
Sometimes work situations (or other special circumstances) require
working with really old stuff - that's fair enough. But are you really
required to write new code for compilation on such an old VMS system
that you can't use C99? You can use gcc with C23 on a VMS target (as
far as I can figure out from the gcc manual - my real-world experience
of VMS consists of a single afternoon with remote access to a P-system
PASCAL compiler as a teenager, so I am not an expert!).
>> In my work I see a lot of libraries and code bases that claim "ANSI C"
>> as though it were a badge of merit. I think in many cases, what they
>> are really saying is that someone wrote the code a generation ago, and
>> the current guys don't really understand how it works so they don't dare
>> change things.
>
> Yeah, a lot of it is old or very old code, but all of the stuff
> I'm talking about was written by me, so I presumably unserstand it.
> It's not that I "don't dare change things", it's that things still
> work (modulo that -std=gnu17 fix in this case -- thanks again, guys)
> and required changes would involve lots and lots of trivial work
> with no observable benefit, whereas I'd rather spend my time
> more profitably (both $-wise and benefit-wise).
>
>> Typically such code is horrible. It is painfully structured, full of
>> home-made pseudo-standard types like "MY_LIB_UINT32", or "i16", or even
>> "ULONG". "int" instead of bool. Macros instead of static inline
>> functions. #define'd constants instead of enums. Long functions with
>> variables declared at the top. (C90 code does not /have/ to be bad, but
>> it very often is.)
>
> Personally, I always use int rather than bool, e.g., sometimes I need
> a three- or many-valued logic (undetermined typically a third value),
> and sometimes not sure what will be needed as development progresses,
> even when there's a detailed design document to begin with.
enum qbool { false, true, maybe, i_really_mean_it, definitely_not };
There are many advantages of bool (or _Bool, pre-C23) over int. And if
you have a reason not to use bool, then an enumeration is nicer than an
int (even though in C the enumeration constants are of type int).
> And I'd never #define a name like MY_LIB_UINT32, but often do
> #define types, again typically because it's not clear what will
> be needed.
For modern (i.e., this century) programming, don't #define types -
typedef them. But of course it is a good idea to define type names that
suit their usage, both to make the coding clearer and to make things
easier to change. Have "typedef uint16_t user_id;" and then use
"user_id" in the main code. And if you get more users, you can change
it to "uint32_t", or pick a different underlying type according to
updated requirements.
It's the types that give you nothing (in either functionality or in
name) over the standard types that I dislike.
> Indeed, several times what started out as some scalar
> type, evolved into a struct, or more simply, sometimes from
> a three-component vector into a four-component quaternion.
> #define'd types can be very, very, very useful for a wide, wide
> variety of reasons. It's always possible to point out a few
> silly misuses of anything, but not always helpful in general.
>
>> And then, in the field of embedded systems, there is often piles of
>> assembly mixed in because the code was written in a time when compilers
>> were weak. (Some assembly can be unavoidable.)
>
> I did a lot of "mixed" assembly & Fortran coding on the IBM/360 series,
> simply to speed up heavy numerical work back when computers were slow
> and compiler optimization pretty much non-existent. Also some assembly
> on PDP-10s and on PDP lab8/es (so the lab8/es could upload collected
> laboratory data to the PDP 10 for processing). And also some assembly
> on DG MV/8000 and C/330 Nova and Eclipse.
> Besides C, Fortran, and several assembly languages, I've also done
> some programming in PL/1, Cobol, Basic, and one or two others --
> every hear of Jovial (Jules' Own Version of the International
> Algorithmic Language)? C does seem to have survived the longest
> (Fortran notwithstanding), but I think that focusing solely on
> its place in the programming language environment might be too
> one-dimensional.
There's nothing wrong with a bit of assembly when it is essential
(things like task switching in an OS) or make a big difference to the
efficiency. But there is a lot wrong with a library (or in my current
situation, an RTOS) that is full of assembly for simple tasks that would
not only be far clearer in C, but almost certainly much more efficient.
>
>> IMHO, C99 made C programming a lot nicer - it's easier to write, easier
>> to read, and lets you get more efficient results. C11 adds a few nice
>> things, though nothing too critical (for my usage), and then C23 adds
>> some other convenient features. I can appreciate people not bothering
>> to use C11 onwards, especially if they are writing code that should be
>> usable on a wide variety of compilers, but I find it hard to understand
>> why anyone would actively choose C90 over C99.
>
> "Passively", so to speak, chosen, at least by me. So the original post
> refers to a lot of old code, and it would be a big pain in the fingers
> to go back and fix all the int typer(); kind of stuff just to get it
> to compile. -std=gnu17 is a much kinder and gentler (to my fingers)
> solution. And having done that, note that everything now compiles and
> runs correctly with no further change whatsoever.
It's easier if you write in a better style from the start :-) "int
typer();" was already obsolescent in C90 (though I don't know if the
term was used in the K&R2 book - my copy is in a box in the loft somewhere).
I appreciate your dilemma, and why "-std=gnu17" (or similar) is the best
solution for you. That's why compilers have these flags - people's
needs and preferences are different. And I'm sure all new code you
write will use function prototypes !
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-04-28 15:33 +0000 |
| Message-ID | <10sqjvh$1jlnb$1@paganini.bofh.team> |
| In reply to | #398052 |
David Brown <david.brown@hesbynett.no> wrote:
> On 28/04/2026 09:02, John Forkosh wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> Lawrence D?Oliveiro wrote:
>>>> John Forkosh wrote:
>>>>
>>>>> And, as much as possible, I try to write code consistent with K&R2,
>>>>> so don't usually need "modern language extensions".
>>>>
>>>> That's just creating work for yourself.
>>>
>>> People can have good and bad reasons for choosing to write to older C
>>> standards, though it is unusual to refer specifically to "K&R2". Most
>>> often, people say "ANSI C" - inaccurately thinking that means the
>>> original ANSI C standard, or basically C90. I have no idea why John
>>> chooses K&R2 - I assume he has good reasons for that choice.
>>
>> No particular reason for "K&R2" versus "ANSI C". But overall reason
>> for "older C standard" was (but pretty much no longer is) contract
>> work on a variety of slightly-weird systems, particularly, for
>> example, VMS, which can require, e.g., a variety of very non-standard
>> stuff like
>> #include <descrip.h>
>> ...
>> char tabbuf[64]; /* usual declarations */
>> char *tabnam;
>> struct dsc$descriptor_s /* required descriptor declarations */
>> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
>> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
>> And I found it easier to stick to an older C standard whenever
>> possible, just to ensure compliance among as many OSs as possible,
>> across as many different platforms as possible.
>> Even one-line // comments rather than /* comments */ can be
>> a problem.
>>
>
> Sometimes work situations (or other special circumstances) require
> working with really old stuff - that's fair enough. But are you really
> required to write new code for compilation on such an old VMS system
> that you can't use C99? You can use gcc with C23 on a VMS target (as
> far as I can figure out from the gcc manual - my real-world experience
> of VMS consists of a single afternoon with remote access to a P-system
> PASCAL compiler as a teenager, so I am not an expert!).
AFAICS you can not use modern gcc on VMS. Big part of gcc is coded in
C++ and gcc c++ targeting VMS failed to build for very long time.
If you stick to C you can use cross compiler targeting VMS. But
even C looks fleaky.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-28 20:24 +0200 |
| Message-ID | <10squ1g$3bo61$1@dont-email.me> |
| In reply to | #398071 |
On 28/04/2026 17:33, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 28/04/2026 09:02, John Forkosh wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> Lawrence D?Oliveiro wrote:
>>>>> John Forkosh wrote:
>>>>>
>>>>>> And, as much as possible, I try to write code consistent with K&R2,
>>>>>> so don't usually need "modern language extensions".
>>>>>
>>>>> That's just creating work for yourself.
>>>>
>>>> People can have good and bad reasons for choosing to write to older C
>>>> standards, though it is unusual to refer specifically to "K&R2". Most
>>>> often, people say "ANSI C" - inaccurately thinking that means the
>>>> original ANSI C standard, or basically C90. I have no idea why John
>>>> chooses K&R2 - I assume he has good reasons for that choice.
>>>
>>> No particular reason for "K&R2" versus "ANSI C". But overall reason
>>> for "older C standard" was (but pretty much no longer is) contract
>>> work on a variety of slightly-weird systems, particularly, for
>>> example, VMS, which can require, e.g., a variety of very non-standard
>>> stuff like
>>> #include <descrip.h>
>>> ...
>>> char tabbuf[64]; /* usual declarations */
>>> char *tabnam;
>>> struct dsc$descriptor_s /* required descriptor declarations */
>>> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
>>> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
>>> And I found it easier to stick to an older C standard whenever
>>> possible, just to ensure compliance among as many OSs as possible,
>>> across as many different platforms as possible.
>>> Even one-line // comments rather than /* comments */ can be
>>> a problem.
>>>
>>
>> Sometimes work situations (or other special circumstances) require
>> working with really old stuff - that's fair enough. But are you really
>> required to write new code for compilation on such an old VMS system
>> that you can't use C99? You can use gcc with C23 on a VMS target (as
>> far as I can figure out from the gcc manual - my real-world experience
>> of VMS consists of a single afternoon with remote access to a P-system
>> PASCAL compiler as a teenager, so I am not an expert!).
>
> AFAICS you can not use modern gcc on VMS. Big part of gcc is coded in
> C++ and gcc c++ targeting VMS failed to build for very long time.
> If you stick to C you can use cross compiler targeting VMS. But
> even C looks fleaky.
>
You could perhaps do a Canadian Cross build - use gcc on x86-64 Linux to
build gcc hosted on VMS and targeting VMS. But I have no idea about the
state of gcc on VMS - I merely know that VMS is a target for gcc.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-04-28 20:22 +0000 |
| Message-ID | <10sr4v1$1kghd$1@paganini.bofh.team> |
| In reply to | #398073 |
David Brown <david.brown@hesbynett.no> wrote:
> On 28/04/2026 17:33, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 28/04/2026 09:02, John Forkosh wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> Lawrence D?Oliveiro wrote:
>>>>>> John Forkosh wrote:
>>>>>>
>>>>>>> And, as much as possible, I try to write code consistent with K&R2,
>>>>>>> so don't usually need "modern language extensions".
>>>>>>
>>>>>> That's just creating work for yourself.
>>>>>
>>>>> People can have good and bad reasons for choosing to write to older C
>>>>> standards, though it is unusual to refer specifically to "K&R2". Most
>>>>> often, people say "ANSI C" - inaccurately thinking that means the
>>>>> original ANSI C standard, or basically C90. I have no idea why John
>>>>> chooses K&R2 - I assume he has good reasons for that choice.
>>>>
>>>> No particular reason for "K&R2" versus "ANSI C". But overall reason
>>>> for "older C standard" was (but pretty much no longer is) contract
>>>> work on a variety of slightly-weird systems, particularly, for
>>>> example, VMS, which can require, e.g., a variety of very non-standard
>>>> stuff like
>>>> #include <descrip.h>
>>>> ...
>>>> char tabbuf[64]; /* usual declarations */
>>>> char *tabnam;
>>>> struct dsc$descriptor_s /* required descriptor declarations */
>>>> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
>>>> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
>>>> And I found it easier to stick to an older C standard whenever
>>>> possible, just to ensure compliance among as many OSs as possible,
>>>> across as many different platforms as possible.
>>>> Even one-line // comments rather than /* comments */ can be
>>>> a problem.
>>>>
>>>
>>> Sometimes work situations (or other special circumstances) require
>>> working with really old stuff - that's fair enough. But are you really
>>> required to write new code for compilation on such an old VMS system
>>> that you can't use C99? You can use gcc with C23 on a VMS target (as
>>> far as I can figure out from the gcc manual - my real-world experience
>>> of VMS consists of a single afternoon with remote access to a P-system
>>> PASCAL compiler as a teenager, so I am not an expert!).
>>
>> AFAICS you can not use modern gcc on VMS. Big part of gcc is coded in
>> C++ and gcc c++ targeting VMS failed to build for very long time.
>> If you stick to C you can use cross compiler targeting VMS. But
>> even C looks fleaky.
>>
>
> You could perhaps do a Canadian Cross build - use gcc on x86-64 Linux to
> build gcc hosted on VMS and targeting VMS. But I have no idea about the
> state of gcc on VMS - I merely know that VMS is a target for gcc.
No, for reason I gave it does not work.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-29 06:22 +0000 |
| Message-ID | <10ss83f$c4t$1@reader1.panix.com> |
| In reply to | #398052 |
David Brown <david.brown@hesbynett.no> wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> Lawrence D?Oliveiro wrote:
>>>> John Forkosh wrote:
>>>>
>>>>> And, as much as possible, I try to write code consistent with K&R2,
>>>>> so don't usually need "modern language extensions".
>>>>
>>>> That's just creating work for yourself.
>>>
>>> People can have good and bad reasons for choosing to write to older C
>>> standards, though it is unusual to refer specifically to "K&R2". Most
>>> often, people say "ANSI C" - inaccurately thinking that means the
>>> original ANSI C standard, or basically C90. I have no idea why John
>>> chooses K&R2 - I assume he has good reasons for that choice.
>>
>> No particular reason for "K&R2" versus "ANSI C". But overall reason
>> for "older C standard" was (but pretty much no longer is) contract
>> work on a variety of slightly-weird systems, particularly, for
>> example, VMS, which can require, e.g., a variety of very non-standard
>> stuff like
>> #include <descrip.h>
>> ...
>> char tabbuf[64]; /* usual declarations */
>> char *tabnam;
>> struct dsc$descriptor_s /* required descriptor declarations */
>> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
>> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
>> And I found it easier to stick to an older C standard whenever
>> possible, just to ensure compliance among as many OSs as possible,
>> across as many different platforms as possible.
>> Even one-line // comments rather than /* comments */ can be
>> a problem.
>
> Sometimes work situations (or other special circumstances) require
> working with really old stuff - that's fair enough. But are you really
> required to write new code for compilation on such an old VMS system
> that you can't use C99? You can use gcc with C23 on a VMS target (as
> far as I can figure out from the gcc manual - my real-world experience
> of VMS consists of a single afternoon with remote access to a P-system
> PASCAL compiler as a teenager, so I am not an expert!).
Note that VMS was only one example. I also had contracts requiring
C development on Stratus computers under VOS, on Tandem "nonstop"
(n.b., true, the hardware pretty much never went down, but the
nonstop OS crashed regularly:), and various other lost-to-posterity
platforms. So I simply tried to develop coding habits/style that
would work across them all, and that would remain working for
the then-forseeable future. Clients/customers knew (and still know)
pretty much nothing about programming, and could care even less.
The just want their stuff to work. And >>that's<< what keeps you
on their approved vendor list. Not squabbling over syntax.
As far as new code today? If it were for VAX (or Alpha) VMS,
then I'd continue to be as conservative as possible given my
history with and understanding of that platform, but all my
once-upon-a-time VMS clients have long since migrated.
As far as new code for now-prevalent Unix/C is concerned,
yeah, I'd most likely "update" my coding habits/style
(e.g., your remarks regarding typedef and enum), but it's
always situation-dependent, e.g., when interfacing with
(or just updating) an existing code base, try to maintain
its style if that style is halfway-or-better decent.
Otherwise, explain (as best as possible) the situation to
the client, and see if they're willing to spend the time
and money to update the legacy code.
This endless squabbling that I'm now seeing about
using the $ char in variable names is utterly ridiculous.
I'd never do it, but anybody else can do whatever they like.
End of story, as far as I'm concerned.
>>> In my work I see a lot of libraries and code bases that claim "ANSI C"
>>> as though it were a badge of merit. I think in many cases, what they
>>> are really saying is that someone wrote the code a generation ago, and
>>> the current guys don't really understand how it works so they don't dare
>>> change things.
>>
>> Yeah, a lot of it is old or very old code, but all of the stuff
>> I'm talking about was written by me, so I presumably unserstand it.
>> It's not that I "don't dare change things", it's that things still
>> work (modulo that -std=gnu17 fix in this case -- thanks again, guys)
>> and required changes would involve lots and lots of trivial work
>> with no observable benefit, whereas I'd rather spend my time
>> more profitably (both $-wise and benefit-wise).
>>
>>> Typically such code is horrible. It is painfully structured, full of
>>> home-made pseudo-standard types like "MY_LIB_UINT32", or "i16", or even
>>> "ULONG". "int" instead of bool. Macros instead of static inline
>>> functions. #define'd constants instead of enums. Long functions with
>>> variables declared at the top. (C90 code does not /have/ to be bad, but
>>> it very often is.)
>>
>> Personally, I always use int rather than bool, e.g., sometimes I need
>> a three- or many-valued logic (undetermined typically a third value),
>> and sometimes not sure what will be needed as development progresses,
>> even when there's a detailed design document to begin with.
>
> enum qbool { false, true, maybe, i_really_mean_it, definitely_not };
>
> There are many advantages of bool (or _Bool, pre-C23) over int. And if
> you have a reason not to use bool, then an enumeration is nicer than an
> int (even though in C the enumeration constants are of type int).
>
>> And I'd never #define a name like MY_LIB_UINT32, but often do
>> #define types, again typically because it's not clear what will
>> be needed.
>
> For modern (i.e., this century) programming, don't #define types -
> typedef them. But of course it is a good idea to define type names that
> suit their usage, both to make the coding clearer and to make things
> easier to change. Have "typedef uint16_t user_id;" and then use
> "user_id" in the main code. And if you get more users, you can change
> it to "uint32_t", or pick a different underlying type according to
> updated requirements.
>
> It's the types that give you nothing (in either functionality or in
> name) over the standard types that I dislike.
>
>> Indeed, several times what started out as some scalar
>> type, evolved into a struct, or more simply, sometimes from
>> a three-component vector into a four-component quaternion.
>> #define'd types can be very, very, very useful for a wide, wide
>> variety of reasons. It's always possible to point out a few
>> silly misuses of anything, but not always helpful in general.
>>
>>> And then, in the field of embedded systems, there is often piles of
>>> assembly mixed in because the code was written in a time when compilers
>>> were weak. (Some assembly can be unavoidable.)
>>
>> I did a lot of "mixed" assembly & Fortran coding on the IBM/360 series,
>> simply to speed up heavy numerical work back when computers were slow
>> and compiler optimization pretty much non-existent. Also some assembly
>> on PDP-10s and on PDP lab8/es (so the lab8/es could upload collected
>> laboratory data to the PDP 10 for processing). And also some assembly
>> on DG MV/8000 and C/330 Nova and Eclipse.
>> Besides C, Fortran, and several assembly languages, I've also done
>> some programming in PL/1, Cobol, Basic, and one or two others --
>> every hear of Jovial (Jules' Own Version of the International
>> Algorithmic Language)? C does seem to have survived the longest
>> (Fortran notwithstanding), but I think that focusing solely on
>> its place in the programming language environment might be too
>> one-dimensional.
>
> There's nothing wrong with a bit of assembly when it is essential
> (things like task switching in an OS) or make a big difference to the
> efficiency. But there is a lot wrong with a library (or in my current
> situation, an RTOS) that is full of assembly for simple tasks that would
> not only be far clearer in C, but almost certainly much more efficient.
Absolutely. That's one thing we agree on that 110% (or better).
I've always liked the description of C as "a portable assembly language".
You can pretty much look at C code and see more-or-less what an
assembler will do with it. And nowadays cc -O3, or whatever,
frequently does a better job than I would/could if programming
exactly the same thing directly in assembly.
>>> IMHO, C99 made C programming a lot nicer - it's easier to write, easier
>>> to read, and lets you get more efficient results. C11 adds a few nice
>>> things, though nothing too critical (for my usage), and then C23 adds
>>> some other convenient features. I can appreciate people not bothering
>>> to use C11 onwards, especially if they are writing code that should be
>>> usable on a wide variety of compilers, but I find it hard to understand
>>> why anyone would actively choose C90 over C99.
>>
>> "Passively", so to speak, chosen, at least by me. So the original post
>> refers to a lot of old code, and it would be a big pain in the fingers
>> to go back and fix all the int typer(); kind of stuff just to get it
>> to compile. -std=gnu17 is a much kinder and gentler (to my fingers)
>> solution. And having done that, note that everything now compiles and
>> runs correctly with no further change whatsoever.
>
> It's easier if you write in a better style from the start :-) "int
> typer();" was already obsolescent in C90 (though I don't know if the
> term was used in the K&R2 book - my copy is in a box in the loft somewhere).
>
> I appreciate your dilemma, and why "-std=gnu17" (or similar) is the best
> solution for you. That's why compilers have these flags - people's
> needs and preferences are different. And I'm sure all new code you
> write will use function prototypes !
Yeah, as above, prototypes as well as various other stuff you
suggested, for completely new code destined to remain on Unix/C.
But situations are frequently more complicated than just "new code".
Some of your (and others') remarks sound (to me) like you're coding
in a blissful vacuum. But the world I see is full of pre-existing
complications that frequently can't be precisely predicted, and
that often can affect your choice of coding style. Better to be
conservative and safe than flamboyant and sorry. (Not saying
your suggestions are flamboyant, but the sentence sounded
cuter that way:)
--
John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-29 09:15 +0200 |
| Message-ID | <10ssb73$3mum2$1@dont-email.me> |
| In reply to | #398085 |
On 29/04/2026 08:22, John Forkosh wrote: > David Brown <david.brown@hesbynett.no> wrote: >>> David Brown <david.brown@hesbynett.no> wrote: >>>> Lawrence D?Oliveiro wrote: >>>>> John Forkosh wrote: >>>>> > This endless squabbling that I'm now seeing about > using the $ char in variable names is utterly ridiculous. > I'd never do it, but anybody else can do whatever they like. > End of story, as far as I'm concerned. The code you posted /had/ a $ character in its identifiers - you /do/ use it! Presumably you used it following the conventions for VMS naming. People here (at least speaking for myself) can generally distinguish between discussions that are about the details of the standards - what's allowed or not allowed in fully portable C code - and what is practical for real programming. Some people here are required to write code that is fully standards conforming, but most C programming has at least limits on the portability it requires. Most people's code will only ever be compiled on tools that support $ in identifiers - if they choose to use them, that's up to them (or their employer, project manager, coding standard, whatever). >> >> There's nothing wrong with a bit of assembly when it is essential >> (things like task switching in an OS) or make a big difference to the >> efficiency. But there is a lot wrong with a library (or in my current >> situation, an RTOS) that is full of assembly for simple tasks that would >> not only be far clearer in C, but almost certainly much more efficient. > > Absolutely. That's one thing we agree on that 110% (or better). > I've always liked the description of C as "a portable assembly language". That is not /remotely/ what I said. C is not a "portable assembly language". It never has been, and never will be - despite regular misunderstandings. (And this has been discussed in c.l.c. far more than dollars in identifiers.) One of C's most important aims was "to reduce the amount of assembly code required". That is the key phrase here. I dislike the way the RTOS (and some other libraries and code) I am currently using is written, because it has large amounts of assembly that would have been better written in C. The code in question should have been in C because C is better for the job, and assembly is not needed - /not/ because C is a "portable assembly". And C cannot replace all the assembly in an RTOS - there are things that C cannot do. > You can pretty much look at C code and see more-or-less what an > assembler will do with it. You can make an estimate, but you will almost certainly get details of the implementation wrong. More importantly, if you start thinking like that when you are programming in C, you are likely to make serious mistakes because you assume semantics that are not there in the C. C describes the actions that lead to particular results - "observable behaviour". Compilers use the C code to understand what those results should be, and generate assembly that gives those results. This is totally different from an assembler language. > And nowadays cc -O3, or whatever, > frequently does a better job than I would/could if programming > exactly the same thing directly in assembly. > That is the case for almost everyone, on almost all platforms. Sometimes a processor has particular instructions that are ideal for a situation, but the compiler can't generate them. Sometimes you can take advantage of information the compiler doesn't know in order to write faster assembly for a bit of code - though there might be ways to give the compiler that information. And modern compilers, while good, are not perfect. But compilers are much better than humans at tracking lifetimes and usages of registers (especially on RISC cpus), instruction scheduling and pipelining, etc. They are much better at re-arranging code, inlining functions, cloning functions, etc. If you add in the requirement that hand-written assembly needs to be readable, maintainable, and well structured, it is usually very hard to beat compilers in real-world code. >>>> IMHO, C99 made C programming a lot nicer - it's easier to write, easier >>>> to read, and lets you get more efficient results. C11 adds a few nice >>>> things, though nothing too critical (for my usage), and then C23 adds >>>> some other convenient features. I can appreciate people not bothering >>>> to use C11 onwards, especially if they are writing code that should be >>>> usable on a wide variety of compilers, but I find it hard to understand >>>> why anyone would actively choose C90 over C99. >>> >>> "Passively", so to speak, chosen, at least by me. So the original post >>> refers to a lot of old code, and it would be a big pain in the fingers >>> to go back and fix all the int typer(); kind of stuff just to get it >>> to compile. -std=gnu17 is a much kinder and gentler (to my fingers) >>> solution. And having done that, note that everything now compiles and >>> runs correctly with no further change whatsoever. >> >> It's easier if you write in a better style from the start :-) "int >> typer();" was already obsolescent in C90 (though I don't know if the >> term was used in the K&R2 book - my copy is in a box in the loft somewhere). >> >> I appreciate your dilemma, and why "-std=gnu17" (or similar) is the best >> solution for you. That's why compilers have these flags - people's >> needs and preferences are different. And I'm sure all new code you >> write will use function prototypes ! > > Yeah, as above, prototypes as well as various other stuff you > suggested, for completely new code destined to remain on Unix/C. > But situations are frequently more complicated than just "new code". Yes. Not much code is truly written from scratch - most is based on something else. > Some of your (and others') remarks sound (to me) like you're coding > in a blissful vacuum. Other people have been using function prototypes for the last 30 years of C programming. You don't need to be working in a vacuum to see C99 code. And while consistency of coding style and standard level is absolutely an important consideration when maintaining or modifying existing code, it is a /consideration/ - not an absolute. If I am making small changes to a piece of old C90 code, I'll use C90, but if I am spending a lot of time working on a big modification, and there are no other overriding requirements, I'll write the new stuff in a better style. > But the world I see is full of pre-existing > complications that frequently can't be precisely predicted, and > that often can affect your choice of coding style. Better to be > conservative and safe than flamboyant and sorry. (Not saying > your suggestions are flamboyant, but the sentence sounded > cuter that way:) Modern C lets you write better C - clearer, safer, more efficient. C90 is "conservative and safe" compared to C99 in the same way that cars from the 1950's are "conservative and safe" compared to modern designs. (Of course you can write good C90 and bad C99 - it's the driver that makes the biggest difference to safety.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-29 10:06 +0200 |
| Message-ID | <10sse58$3kni0$13@dont-email.me> |
| In reply to | #398086 |
On 2026-04-29 09:15, David Brown wrote: > [...] > > Modern C lets you write better C - clearer, safer, more efficient. C90 > is "conservative and safe" compared to C99 in the same way that cars > from the 1950's are "conservative and safe" compared to modern designs. > > (Of course you can write good C90 and bad C99 - it's the driver that > makes the biggest difference to safety.) Nicely said. :-) Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-29 11:25 +0300 |
| Message-ID | <20260429112553.00006835@yahoo.com> |
| In reply to | #398086 |
On Wed, 29 Apr 2026 09:15:47 +0200
David Brown <david.brown@hesbynett.no> wrote:
>
> Other people have been using function prototypes for the last 30
> years of C programming. You don't need to be working in a vacuum to
> see C99 code. And while consistency of coding style and standard
> level is absolutely an important consideration when maintaining or
> modifying existing code, it is a /consideration/ - not an absolute.
> If I am making small changes to a piece of old C90 code, I'll use
> C90, but if I am spending a lot of time working on a big
> modification, and there are no other overriding requirements, I'll
> write the new stuff in a better style.
>
> > But the world I see is full of pre-existing
> > complications that frequently can't be precisely predicted, and
> > that often can affect your choice of coding style. Better to be
> > conservative and safe than flamboyant and sorry. (Not saying
> > your suggestions are flamboyant, but the sentence sounded
> > cuter that way:)
>
> Modern C lets you write better C - clearer, safer, more efficient.
> C90 is "conservative and safe" compared to C99 in the same way that
> cars from the 1950's are "conservative and safe" compared to modern
> designs.
>
> (Of course you can write good C90 and bad C99 - it's the driver that
> makes the biggest difference to safety.)
>
The text above sound as if function prototypes were invented for C99.
Of course, they are not.
In practice there are only 3 features that make difference between C90
and C99 for majority of coders and all three are "nice to have" rather
than make a major difference.
1. // comments
2. declaration does not have to be at the beginning of {} block
3. 'long long' integer types and <stdint.h>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-29 11:26 +0200 |
| Message-ID | <10ssit3$3pds0$1@dont-email.me> |
| In reply to | #398089 |
On 29/04/2026 10:25, Michael S wrote:
> On Wed, 29 Apr 2026 09:15:47 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> Other people have been using function prototypes for the last 30
>> years of C programming. You don't need to be working in a vacuum to
>> see C99 code. And while consistency of coding style and standard
>> level is absolutely an important consideration when maintaining or
>> modifying existing code, it is a /consideration/ - not an absolute.
>> If I am making small changes to a piece of old C90 code, I'll use
>> C90, but if I am spending a lot of time working on a big
>> modification, and there are no other overriding requirements, I'll
>> write the new stuff in a better style.
>>
>>> But the world I see is full of pre-existing
>>> complications that frequently can't be precisely predicted, and
>>> that often can affect your choice of coding style. Better to be
>>> conservative and safe than flamboyant and sorry. (Not saying
>>> your suggestions are flamboyant, but the sentence sounded
>>> cuter that way:)
>>
>> Modern C lets you write better C - clearer, safer, more efficient.
>> C90 is "conservative and safe" compared to C99 in the same way that
>> cars from the 1950's are "conservative and safe" compared to modern
>> designs.
>>
>> (Of course you can write good C90 and bad C99 - it's the driver that
>> makes the biggest difference to safety.)
>>
>
> The text above sound as if function prototypes were invented for C99.
> Of course, they are not.
>
Correct - they have been around from pre-standard C versions that were
standardised into what became ANSI C / C89 / C90. But reading over my
post, I agree with you that it sounds like I associated them strongly
with C99. I was trying to say that writing in more modern style is
usually a good thing, with C99 having definite benefits over C90, and
that using function prototypes is an example of more modern style that
would directly benefit the OP. Of course in the case of function
prototypes, that would mean merely modernising to C90 - or to K&R2 C.
(The same applies to a few other outdated styles of coding I mentioned
seeing in some C90 code, such as lists of #define'd constants where an
enum would make sense - enums were in C90 too.)
> In practice there are only 3 features that make difference between C90
> and C99 for majority of coders and all three are "nice to have" rather
> than make a major difference.
> 1. // comments
> 2. declaration does not have to be at the beginning of {} block
> 3. 'long long' integer types and <stdint.h>
>
I would agree on these being the most important three changes. In
particular, mixing declarations and statements means you can move to a
style where almost all local variables are only declared when you have
an initial value for them, keeping their scopes smaller and virtually
eliminating bugs due to usage of uninitialised variables.
I'd add <stdbool.h> to the list, but I don't know if it is fair to say
"the majority" of coders see them as a major difference.
And I think "inline" functions were a major improvement - you can use
"static inline" functions in many situations where previously
function-like macros would have been used.
I also think the removal of implicit int and implicit function
declarations was a very important step for C99. However, it would make
relatively little difference to programmers - people who already
declared function prototypes and types in C90 code would not notice, and
compilers were often far too lax about accepting code with these
mistakes even in C99+ standards modes.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-04-29 20:07 -0400 |
| Message-ID | <10su6fn$9qef$2@dont-email.me> |
| In reply to | #398090 |
On 2026-04-29 05:26, David Brown wrote:
> On 29/04/2026 10:25, Michael S wrote:
...
>> On Wed, 29 Apr 2026 09:15:47 +0200
>> In practice there are only 3 features that make difference between C90
>> and C99 for majority of coders and all three are "nice to have" rather
>> than make a major difference.
>> 1. // comments
>> 2. declaration does not have to be at the beginning of {} block
>> 3. 'long long' integer types and <stdint.h>
>>
> I would agree on these being the most important three changes. In
> particular, mixing declarations and statements means you can move to a
> style where almost all local variables are only declared when you have
> an initial value for them, keeping their scopes smaller and virtually
> eliminating bugs due to usage of uninitialised variables.
>
> I'd add <stdbool.h> to the list, but I don't know if it is fair to say
> "the majority" of coders see them as a major difference.
>
> And I think "inline" functions were a major improvement - you can use
> "static inline" functions in many situations where previously
> function-like macros would have been used.
>
>
> I also think the removal of implicit int and implicit function
> declarations was a very important step for C99. However, it would make
> relatively little difference to programmers - people who already
> declared function prototypes and types in C90 code would not notice,
> and compilers were often far too lax about accepting code with these
> mistakes even in C99+ standards modes.\
I'm in full agreement with those assessments. However, for those of us
using C for scientific and engineering purposes (however misguided you
might think our choice of language is), support for complex math, being
able to check for __STDC__IEC__ISO665__, <tgmath.h>, <env.h> and the
many additions to <math.h> and <float.h> were also very welcome. I've
known Fortran programmers who said that it was the only really good
language for such purposes, who changed their mind when C99 came out. I
know we are niche programmers - but in some sense almost everyone is a
niche programmer in many different niches.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-30 00:14 +0000 |
| Message-ID | <10su6t5$a7c6$2@dont-email.me> |
| In reply to | #398103 |
On Wed, 29 Apr 2026 20:07:19 -0400, James Kuyper wrote: > I've known Fortran programmers who said that it was the only really > good language for such purposes, who changed their mind when C99 > came out. I think Fortran still has the edge in its coarrays and support for expressing massively-parallel computations. And it actually has a type-parameterization system, too.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-29 17:57 -0700 |
| Message-ID | <10su9d9$auae$1@dont-email.me> |
| In reply to | #398105 |
On 4/29/2026 5:14 PM, Lawrence D’Oliveiro wrote: > On Wed, 29 Apr 2026 20:07:19 -0400, James Kuyper wrote: > >> I've known Fortran programmers who said that it was the only really >> good language for such purposes, who changed their mind when C99 >> came out. > > I think Fortran still has the edge in its coarrays and support for > expressing massively-parallel computations. C11 and C++11 have std threading, so, we can do that. > > And it actually has a type-parameterization system, too.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-30 03:09 +0200 |
| Message-ID | <10sua3s$11tq$1@dont-email.me> |
| In reply to | #398108 |
On 2026-04-30 02:57, Chris M. Thomasson wrote: > On 4/29/2026 5:14 PM, Lawrence D’Oliveiro wrote: >> On Wed, 29 Apr 2026 20:07:19 -0400, James Kuyper wrote: >> >>> I've known Fortran programmers who said that it was the only really >>> good language for such purposes, who changed their mind when C99 >>> came out. >> >> I think Fortran still has the edge in its coarrays and support for >> expressing massively-parallel computations. > > C11 and C++11 have std threading, so, we can do that. Yet, in the early 1970's, four decades before 2011, there were also other HLLs already existing with native support for complex numbers and parallelism. Janis
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web