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 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.
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...
On 2026-01-08, The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
+1
I re-worked my code over time so that -Wall yields no errors.
And then a new version of gcc comes out which picks even more nits, and
the process repeats. Not being a quick-and-dirty type, I consider it a
win overall.
The one exception is its scrutiny of printf() calls.
That was a step too far, so I added -Wno-format-overflow.
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.
Finding out where they were defined, across over a million lines of
source code, was a fun exercise. I learned somethings about ctags along
the way ...
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 is not mine, I would use the compiler options instead.
Unless I got paid to maintain that code, then I would correct the code.
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.
Don't fix what ain't broke, you might break it [1] :-D
[1] I'm speaking from experience.
| Sysop: | datGSguy |
|---|---|
| Location: | Eugene, OR |
| Users: | 7 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 219:18:05 |
| Calls: | 361 |
| Calls today: | 34 |
| Files: | 14 |
| D/L today: |
68 files (1,095K bytes) |
| Messages: | 5,751 |
| Posted today: | 1 |