My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.
On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:
My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a
proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.
I agree that C does the job reasonably well, and it is simple.
And so, like most other geeks my age, I write with the tools I
have used in forever, rather than spending my time learning new
tools. For me, those tools are:
- C
- vim
- perl
- HTML (1.0)
And yes, it is like using a vintage Jeep for a daily driver.
The most egregious problem with old C is string handling.
A useful "string" type would have
- a maximum length, using hardware (exception) bounds checking.
to be useful, this would mean a length field in front of
the char[]
- ideally, an option for the length to be dynamic, reallocating
the memory as needed. Would require the base representation
to be a pointer to the struct. Would be a lot of "under the
hood" stuff, and probably inefficient.
PL/I was designed with all the features that were later added to C,
so the end result is cleaner.
On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:
Inspired by readline(), I've written my own replacements for strcpy()
and strcat() that do much the same thing.
To quote from the strcat man page "Read about Shlemiel the painter.". >stpcpy() was a late arrival and I never used it. I do use a similar >construct
char buf[1024];
char* ptr = buf;
ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");
rbowman <bowman@montana.com> writes:
On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:
Inspired by readline(), I've written my own replacements for strcpy()
and strcat() that do much the same thing.
To quote from the strcat man page "Read about Shlemiel the painter.". >>stpcpy() was a late arrival and I never used it. I do use a similar >>construct
char buf[1024];
char* ptr = buf;
ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");
I would suggest using snprintf instead of sprintf
to prevent accesses beyond (buf + 1024). A bit
more complicated if you want to know that the
result was truncated, since you need to adjust the
remaining length based on the return value from
the prior snprintf, as well as checking for
overflow.
On Tue, 06 Jan 2026 22:54:26 +0000, Richard Kettlewell wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
rbowman <bowman@montana.com> writes:
On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:
Inspired by readline(), I've written my own replacements for strcpy() >>>>> and strcat() that do much the same thing.
To quote from the strcat man page "Read about Shlemiel the painter.".
stpcpy() was a late arrival and I never used it. I do use a similar
construct
char buf[1024];
char* ptr = buf;
ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");
I would suggest using snprintf instead of sprintf to prevent accesses
beyond (buf + 1024). A bit more complicated if you want to know that
the result was truncated, since you need to adjust the remaining length
based on the return value from the prior snprintf, as well as checking
for overflow.
This is calling out for a wrapping up in a function or two that can do
the book-keeping automatically (and use an expandable buffer, if the use
case demands).
Ah, mission creep...
On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:
On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:
My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a >>> proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian government >>> to study C compilers, but he could not talk about what they wrote.
What language(s) did he suggest instead?
On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:
On 2026-01-06 19:57, Charlie Gibbs wrote:
On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:
On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:
My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.
What language(s) did he suggest instead?
I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.
It is possible that current C compilers signal many more problems that
back then, but not runtime errors.
gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.
On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:
On 2026-01-06 19:57, Charlie Gibbs wrote:
On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:
On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:
My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.
What language(s) did he suggest instead?
I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.
It is possible that current C compilers signal many more problems that
back then, but not runtime errors.
gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.
On 07/01/2026 22:49, rbowman wrote:
On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:Actually I welcome that. at leats 10% of the time the compiler finds a
It is possible that current C compilers signal many more problems that
back then, but not runtime errors.
gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an
int.
bug that way, and the other 90% i upgrade the source to be more explicit...
It was never a good idea but the legacy code often defined a variable in
a .h file. The newer gcc implementations would throw multiple definition errors. Fixing it would have been painful. foo.h that defined int bar;
might be included in several different programs so you would have to hunt down all the uses and then define bar someplace in a .c file.
Great project for the new guy but at the time the newest guy had been
there for 20 years. Adding the compiler flag to the relevant makefiles was easier.
In multi-module programs I define my globals in a .h file as follows:
common.h
--------
#ifdef PRIMARY
#define GLOBAL
#else
#define GLOBAL extern
#endif
foo.h
-----
#include "common.h"
GLOBAL int foo;
foo1.c
------
#define PRIMARY
#include "foo.h"
int main(int argc, char **argv)
{
setfoo();
printf("foo is %d\n", foo);
exit(0);
}
foo2.c
------
#include "foo.h"
void setfoo()
{
foo = 5;
}
It works for me; I like having only one declaration of "foo"
in my source modules.
Recently, I've been writing code with no global variables. It's been
a fun experiment.
On 2026-01-08, rbowman <bowman@montana.com> wrote:
It was never a good idea but the legacy code often defined a variable in
a .h file. The newer gcc implementations would throw multiple definition
errors. Fixing it would have been painful. foo.h that defined int bar;
might be included in several different programs so you would have to hunt >> down all the uses and then define bar someplace in a .c file.
Great project for the new guy but at the time the newest guy had been
there for 20 years. Adding the compiler flag to the relevant makefiles was >> easier.
In multi-module programs I define my globals in a .h file as follows:
common.h
--------
#ifdef PRIMARY
#define GLOBAL
#else
#define GLOBAL extern
#endif
On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:
On 2026-01-06 19:57, Charlie Gibbs wrote:
On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:
On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:
My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.
What language(s) did he suggest instead?
I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.
It is possible that current C compilers signal many more problems that
back then, but not runtime errors.
gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.
If the code were mine, I would correct the code. Even back then, I
did not take the assumption that a function would return an integer
:-D
On 2026-01-07 23:49, rbowman wrote:
On 2026-01-06 19:57, Charlie Gibbs wrote:
<snip>
It is possible that current C compilers signal many more problems that
back then, but not runtime errors.
gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an
int.
If the code were mine, I would correct the code. Even back then, I did
not take the assumption that a function would return an integer :-D
I wrote explicit prototypes in the header file. :-)
If the code is not mine, I would use the compiler options instead.
Unless I got paid to maintain that code, then I would correct the code.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 40:51:24 |
| Calls: | 188 |
| Files: | 21,502 |
| Messages: | 80,790 |