And in essence, when you read from a directory, the only thing you get
is the filename.
If it is actually a subdirectory, then that is
indicated with a "/" at the end of the filename.
Now C90 doesn't have folder/directory operations (such as opendir()) for
a reason.
Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c
And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.
Other things like size and creation date are not available,
and C90 does not guarantee that such concepts even
exist. C90 does guarantee that files exist though.
And C90 (etc) could potentially be extended to include a folder.h
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
And in essence, when you read from a directory, the only thing you get
is the filename.
You want at least the type of entry as well, surely.
<https://manpages.debian.org/readdir(3)>
If it is actually a subdirectory, then that is
indicated with a "/" at the end of the filename.
What if it's a symlink to a directory?
Now C90 doesn't have folder/directory operations (such as opendir()) for
a reason.
Surely OSes that don't support hierarchical directories are only fit for
the museum nowadays.
C90 will never be extended.
"Paul Edwards" <mutazilah@gmail.com> writes:
Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c
And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.
Other things like size and creation date are not available,
and C90 does not guarantee that such concepts even
exist. C90 does guarantee that files exist though.
C90, like all later standards, supports file operations only in hosted implementations, not in freestanding implementations. Even on a
conforming hosted implementation, every call to fopen() could fail.
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by C99, which was made obsolete by C11, which was made obsolete by C23. You're free to invent
your own language based on C90 if you like, but C went in a different direction decades ago.
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability has a
value all its own.
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability has a value
all its own.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by C99, which was made
obsolete by C11, which was made obsolete by C23. You're free to invent
your own language based on C90 if you like, but C went in a different
direction decades ago.
That depends on your definition of "C". Ritchie is no longer here to adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
A semantic debate that doesn't answer my question either way anyway.
On 20/05/2025 11:36, Paul Edwards wrote:made
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by C99, which was
obsolete by C11, which was made obsolete by C23. You're free to invent
your own language based on C90 if you like, but C went in a different
direction decades ago.
That depends on your definition of "C". Ritchie is no longer here to adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.
The language is covered by an
international standard, so "C" is the language defined by that standard.
Thus "C" means "C23" at the moment - each newly published C standard "cancels and replaces" the previous version.
Ritchie's opinion hasn't
had any connection to the "definition of C" since 1989. I don't know if
he ever expressed a public opinion on C99, or the plans for C11. I
would, however, be astounded if he had considered it "a complete and
utter joke of no relation to anything he designed".
(And while I don't think that an "appeal to authority" argument has much merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)
But Keith is absolutely correct here. C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical corrections).
You can make your own libraries, and OS's, and extensions, and languages
- whatever makes you happy. (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need. You don't
need approval from anyone else. Don't let me or anyone else hinder you enjoying yourself.) However, nothing that you ever do will be an
extension to C90.
The folder routines will do everything I need.
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability has a
value all its own.
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability has a
value all its own.
Windows Vista will never be extended either.
Operating systems have least excuse of all for turning rock into
sand. It's harder to build stable software if it has to sit on
top of amorphous gloop.
On 2025-05-20, Paul Edwards <mutazilah@gmail.com> wrote:
The folder routines will do everything I need.
Except be written in C90?
On Tue, 20 May 2025 15:05:01 +0100uni
Richard Heathfield <rjh@cpax.org.uk> wibbled:
Operating systems have least excuse of all for turning rock into
sand. It's harder to build stable software if it has to sit on
top of amorphous gloop.
On a related note, I can still compile unix C code I wrote in the 90s at
without any changes on linux and mac.
"David Brown" <david.brown@hesbynett.no> wrote in message news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by
C99, which was made obsolete by C11, which was made
obsolete by C23. You're free to invent your own language
based on C90 if you like, but C went in a different
direction decades ago.
That depends on your definition of "C". Ritchie is no longer here to
adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.
Yes, I agree with that.
The language is covered by an
international standard, so "C" is the language defined by that standard.
Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.
I don't agree with this. I'm sure the ISO committee is keen
to "cancel" the previous work.
But I have a different opinion.
I doubt that I am alone.
I'm probably in a minority, but so what?
Ritchie's opinion hasn't
had any connection to the "definition of C" since 1989. I don't know if
he ever expressed a public opinion on C99, or the plans for C11. I
would, however, be astounded if he had considered it "a complete and
utter joke of no relation to anything he designed".
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
From another corner I still deal with people who insist
that everything should be written in assembler.
And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
I understand where these people are coming from.
And I can see the alternative described by that Jeff article
I referenced.
But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
(And while I don't think that an "appeal to authority" argument has much
merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)
I'm not asking him to approve my OS ideas. I'm asking him
to explain what is wrong with the C90 that he approved of,
and whether my mentioned extensions are reasonable.
But Keith is absolutely correct here. C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical corrections). >>
You can make your own libraries, and OS's, and extensions, and languages
- whatever makes you happy. (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need. You don't
need approval from anyone else. Don't let me or anyone else hinder you
enjoying yourself.) However, nothing that you ever do will be an
extension to C90.
You seem to have a different definition of "extension to C90" to me, then.
Which is also fine.
Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.
My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).
On 20/05/2025 14:55, Kaz Kylheku wrote:
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability has a
value all its own.
Windows Vista will never be extended either.
Certainly the version on one of my ancient laptops never will be.
Indeed, I deprive it of an Internet connection for precisely that
reason. Vista is what it is, and has no business changing. If I
want to change the OS I'll buy a bloody CD-ROM.
My main development machine/environment is Windows 2000Would everybody please close their eyes and bow their heads?
[This should be fun.]
On 20/05/2025 14:47, Paul Edwards wrote:
"David Brown" <david.brown@hesbynett.no> wrote in message news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
directory.h, damn you! Folders are for schoolteachers, not
programmers. We could fall out over this.
standard.The language is covered by an
international standard, so "C" is the language defined by that
Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.
I don't agree with this. I'm sure the ISO committee is keen
to "cancel" the previous work.
Whether you agree with David or not, he's correct. He has
accurately described the way the world sees C.
You might argue that the world sees it wrong, and who am I to
dissuade you? But ISO has far more clout than you or me, alas.
And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
Mibs are marbles. You can't run a C compiler under 16 marbles,
not even if you bring in Dennis Ritchie.
I understand where these people are coming from.
So do I, but I expect it was a typo for 16 GB.
And I can see the alternative described by that Jeff article
I referenced.
But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
Right.
much(And while I don't think that an "appeal to authority" argument has
merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)
I'm not asking him to approve my OS ideas. I'm asking him
to explain what is wrong with the C90 that he approved of,
and whether my mentioned extensions are reasonable.
I'm afraid we're about 13 years too late to expect an answer
from the man himself, but I could guess at his answers:
(a) nothing;
(b) they make a reasonable library, but there's no reason tocorrections).
change C90. If people find the library useful, they will use it
and the word will spread.
But Keith is absolutely correct here. C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical
languages
You can make your own libraries, and OS's, and extensions, and
don't- whatever makes you happy. (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need. You
then.need approval from anyone else. Don't let me or anyone else hinder you
enjoying yourself.) However, nothing that you ever do will be an
extension to C90.
You seem to have a different definition of "extension to C90" to me,
Then what do you mean by it? I suspect David thinks you mean an
update to the ISO C90 document requiring all conforming C
compilers to adopt your new library. And, like me, Keith and
David know full well that that ain't gonna happen.
Which is also fine.
Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.
My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).
If you want to publish a library, nobody is going to argue
against you doing so. You can't have too many libraries. (Well, I
expect you can, but it's hard.)
On 20/05/2025 15:48, Paul Edwards wrote:
<snip>
My main development machine/environment is Windows 2000Would everybody please close their eyes and bow their heads?
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100i43s$29dr0$1@dont-email.me...
[This should be fun.]
On 20/05/2025 14:47, Paul Edwards wrote:
"David Brown" <david.brown@hesbynett.no> wrote in message
news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
directory.h, damn you! Folders are for schoolteachers, not
programmers. We could fall out over this.
What we'll fall out over is you exceeding the limits of
MSDOS 8.3 filenames. :-)
And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
Mibs are marbles. You can't run a C compiler under 16 marbles,
not even if you bring in Dennis Ritchie.
Pardon?
I also use Microsoft C 6.0 which was the
last version to run on a PC XT in 640 KiB.
gcc 3.2.3 will run in under 16 MiB if I switch off optimization.
I understand where these people are coming from.
So do I, but I expect it was a typo for 16 GB.
Nope.
But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
Right.
Certainly great to have company!
Or to put it another way - if you didn't have time pressure,
and the world was willing to stop writing code circa 1986
until C had been standardized, and with the benefit of
hindsight - what should or shouldn't be in a C90 or C2090 -
however long it takes to "get it right"?
"David Brown" <david.brown@hesbynett.no> wrote in message news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:made
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by C99, which was
obsolete by C11, which was made obsolete by C23. You're free to invent >>>> your own language based on C90 if you like, but C went in a different
direction decades ago.
That depends on your definition of "C". Ritchie is no longer here to
adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.
Yes, I agree with that.
The language is covered by an
international standard, so "C" is the language defined by that standard.
Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.
I don't agree with this.
I'm sure the ISO committee is keen
to "cancel" the previous work.
But I have a different opinion.
I doubt that I am alone. I'm probably in a minority, but so what?
Ritchie's opinion hasn't
had any connection to the "definition of C" since 1989. I don't know if
he ever expressed a public opinion on C99, or the plans for C11. I
would, however, be astounded if he had considered it "a complete and
utter joke of no relation to anything he designed".
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
From another corner I still deal with people who insist
that everything should be written in assembler.
And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
I understand where these people are coming from.
And I can see the alternative described by that Jeff article
I referenced.
But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
(And while I don't think that an "appeal to authority" argument has much
merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)
I'm not asking him to approve my OS ideas. I'm asking him
to explain what is wrong with the C90 that he approved of,
and whether my mentioned extensions are reasonable.
But Keith is absolutely correct here. C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical corrections). >>
You can make your own libraries, and OS's, and extensions, and languages
- whatever makes you happy. (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need. You don't
need approval from anyone else. Don't let me or anyone else hinder you
enjoying yourself.) However, nothing that you ever do will be an
extension to C90.
You seem to have a different definition of "extension to C90" to me, then.
Which is also fine.
Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.
My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).
While there are some people who, for reasons that still escape
me, prefer C90 over C99
On 20/05/2025 15:47, Paul Edwards wrote:
"David Brown" <david.brown@hesbynett.no> wrote in message
news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:made
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
And C90 (etc) could potentially be extended to include a folder.h
C90 will never be extended. It was made obsolete by C99, which was
obsolete by C11, which was made obsolete by C23. You're free to invent >>>>> your own language based on C90 if you like, but C went in a different >>>>> direction decades ago.
That depends on your definition of "C". Ritchie is no longer here to
adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.
Yes, I agree with that.
Then why do think that something might depend on someone's "definition
of C" ? The definition of C is clear - it is what the international standard says it is. You can have other C-like languages, but they are
not C.
The language is covered by an
international standard, so "C" is the language defined by that standard. >>> Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.
I don't agree with this.
You don't get to have an opinion on facts. What I said is /fact/ - you
can look at what it says in each new version of the C standards. This
is also normal practice for ISO standards.
You can have an opinion as to whether or not you like the ISO practices,
but not on what those practices are.
Again, you don't get to have an opinion on what the ISO committees
practices are - you only get to have an opinion on whether or not you
like them.
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if they >said he had "become deranged".
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if they
said he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
Mr. Edwards also believes that MS-DOS is the be-all and end-all of operating systems.
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape
me, prefer C90 over C99
I will not fight you, David.
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape
me, prefer C90 over C99
I will not fight you, David.
// For some reason that escapes me, I have a crash.
char *me(void)
{
char reason[42];
return reason;
}
On 20/05/2025 17:58, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if they >>> said he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
I'm not entirely sure (yet, at least) that 'troll' is a fair
assessment of Mr Edwards. Time will tell.
Mr. Edwards also believes that MS-DOS is the be-all and end-all of operating >> systems.
Citation needed. He has mentioned it in passing... I just trawled
through all his articles in this thread, and I just found that
one fleeting reference.
Perhaps I missed it. Would you be so kind as to point out why you
believe that "Mr. Edwards also believes that MS-DOS is the be-all
and end-all of operating systems"?
On 20/05/2025 18:14, Kaz Kylheku wrote:
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape
me, prefer C90 over C99
I will not fight you, David.
// For some reason that escapes me, I have a crash.
char *me(void)
{
char reason[42];
return reason;
}
Don't give up the day job, Kaz. ;-)
Sure, you can do stupid things in any dialect of C.
I think it was Doug Gwyn who said that if you set out to make it
impossible to do stupid things in C, you'll end up making it
impossible to do clever things.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 17:58, Scott Lurndal wrote:
Mr. Edwards also believes that MS-DOS is the be-all and end-all of operating
systems.
Citation needed. He has mentioned it in passing... I just trawled
through all his articles in this thread, and I just found that
one fleeting reference.
Perhaps I missed it. Would you be so kind as to point out why you
believe that "Mr. Edwards also believes that MS-DOS is the be-all
and end-all of operating systems"?
There are a decade of relevent threads on alt.os.development
discussing his PDOS/386 project.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 18:14, Kaz Kylheku wrote:
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape
me, prefer C90 over C99
I will not fight you, David.
// For some reason that escapes me, I have a crash.
char *me(void)
{
char reason[42];
return reason;
}
Don't give up the day job, Kaz. ;-)
Sure, you can do stupid things in any dialect of C.
I think it was Doug Gwyn who said that if you set out to make it
impossible to do stupid things in C, you'll end up making it
impossible to do clever things.
Define "clever" in this context. Duff's Device?
Most "clever" code often ends up being not very maintainable in the
long run, or sometimes is broken by a simple architectural enhancement.
On 20/05/2025 18:14, Kaz Kylheku wrote:
On 2025-05-20, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape
me, prefer C90 over C99
I will not fight you, David.
// For some reason that escapes me, I have a crash.
char *me(void)
{
char reason[42];
return reason;
}
Don't give up the day job, Kaz. ;-)
Sure, you can do stupid things in any dialect of C.
I think it was Doug Gwyn who said that if you set out to make it
impossible to do stupid things in C, you'll end up making it
impossible to do clever things.
If you're allowed to get all uppity about 9-letter filenames
(which uppityness I absolutely understand and respect), I reserve
the right to insist on KB, MB, and GB instead of these
nonsensical new inventions. The world knows full well that bit
and byte prefixes are measured in powers of 2, and we don't need
an intrusive iota irresponsibly interceding itself into initialisms.
But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
Right.
Certainly great to have company!
Today comp.lang.c, tomorrow ISO/IEC JTC 1/SC 22/WG 14 !
Or to put it another way - if you didn't have time pressure,
and the world was willing to stop writing code circa 1986
until C had been standardized, and with the benefit of
hindsight - what should or shouldn't be in a C90 or C2090 -
however long it takes to "get it right"?
fclose would take a FILE ** instead of FILE *, and its dying act
would be *fp = NULL;
qsort and bsearch would take context pointers to pass to cmp.
non-blocking sockets would be in the standard, using an interface
based on fopen/fread/fwrite/fclose.
Then why do think that something might depend on someone's "definition
of C" ? The definition of C is clear - it is what the international
standard says it is. You can have other C-like languages, but they are
not C.
And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
Now you are stretching credulity.
I understand where these people are coming from.
And I can see the alternative described by that Jeff article
I referenced.
Few people click on random links. If you have something to say, say it.
I never knew Ritchie personally, and can only make guesses as to what he might think or say. I would, however, be very surprised if he
considered C90 to be "perfect" or in any sense complete, or that he disapproved of the C standards committee moving forward with the
language.
I expect that like most of us, he would like some parts of
each new standard, and dislike other parts - some parts he would find
useful, and others not so much. And he would be happy to accept that
the language is not for him personally - it's fine to have features that
are of use and interest to other people.
Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.
You don't lack ambition!
My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).
I have no problem with giving technical advice (if I have any that I
think will be useful - I work with a significantly different type of programming, however). But I think you'd get on a lot better if you
said you were trying to write a C90 library of functions for directory access,
and dropped the bizarre doomsday philosophy.
Choose C90 for
maximal portability, or personal preference - that's fine. Trying to convince other people that C90 is somehow "perfect"
while C99 is a
"complete and utter joke" is not going to get you much technical help.
Telling us that you are doing all this to be "apocalypse-ready" simply
brands you as a delusional nutcase.
And while I think delusional
nutcases (as long as they are non-violent) have as much right to get technical answers as the next person, it really does distract from the C-related questions you have.
So is it right to expect directories to be covered by C90?
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if they >said he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
Mr. Edwards also believes that MS-DOS is the be-all and end-all ofoperating
systems.
"David Brown" <david.brown@hesbynett.no> wrote in message[...]
[...]while C99 is a
"complete and utter joke" is not going to get you much technical help.
I don't see what bearing my opinion on C99 (or politics,
or anything) has on a technical discussion of C90, but
so be it.
Telling us that you are doing all this to be "apocalypse-ready" simply
access, and dropped the bizarre doomsday philosophy.
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
So is it right to expect directories to be covered by C90?
Of course not. C90 is frozen, defined by the ISO standard published
in 1990. It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
I'm guessing that you meant something by "expect" that differs from
its usual meaning. Can you clarify?
There is an existing secondary standard that does provide support
for directories, among a lot of other things. POSIX. If I wanted
a system that was based on C90 and could handle directories,
I can't think of a good reason not to use C90+POSIX. (You might
have ideological reasons to insist on an earlier edition of POSIX.)
(MS Windows does not directly support POSIX, or at least does not
do so usefully, but my impression is that you don't care about that.)
If you want to define your own language based on C90, you're free
to do so. You've talked about "extending" C90. Some people here
have interpreted that to mean you want to change what C90 is, so
there's something called "C90" that includes some stuff you've added.
Calling your language "C90" will cause confusion and some anger.
But you can do exactly the same thing by defining a *new* language
*with a different name* that's based on C90 with whatever additions
you want. The name can even start with "C", just as "C++" does.
Many of us think that would be a waste of time, but it's not our
time that's being wasted.
And if you want your new language to support directory operations,
my advice would be to incorporate POSIX directory operations into
your new language's standard library.
I don't see what bearing my opinion on C99 (or politics,
or anything) has on a technical discussion of C90, but
so be it.
It *should* have no bearing at all. The problem is that if you
come here and say that C99 is a "complete and utter joke" or make
similarly inflammatory statements, people are going to react.
If you don't want that reaction, don't make statements like that.
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100i7ub$2aaj2$1@dont-email.me...
If you're allowed to get all uppity about 9-letter filenames
(which uppityness I absolutely understand and respect), I reserve
the right to insist on KB, MB, and GB instead of these
nonsensical new inventions. The world knows full well that bit
and byte prefixes are measured in powers of 2, and we don't need
an intrusive iota irresponsibly interceding itself into initialisms.
There are places in computing where powers of 2 are not
used, and sometimes it is important.
Manipulating directories is not as important as manipulating
files. The C90 people didn't leave out file manipulation (I
think the ISO Pascal people left it out, at least originally).
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a5770xjw.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
So is it right to expect directories to be covered by C90?
Of course not. C90 is frozen, defined by the ISO standard published
in 1990. It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
I'm guessing that you meant something by "expect" that differs from
its usual meaning. Can you clarify?
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
But it could potentially be even neater if it was hidden
away behind a standard fopen etc call.
That's my question.
Why not hide it in fopen()? That's my original question.
Why should it be opendir() instead of fopen()?
That's my unanswered question.
Plus you just said above that it would be reasonable for
the POSIX directory operations to be directly incorporated
into C90+'s "standard library".
The C90 people didn't choose to do that.
That doesn't necessarily constrain the C90+ people.
But it does beg the question - would it have been
ACCEPTABLE for the ANSI 89 people to have
put that directory manipulation stuff into the C89
standard IF they could do so quickly?
Or would that be an ABOMINATION?
What is the PHILOSOPHY about what SHOULD
be included in a standard?
I don't see what bearing my opinion on C99 (or politics,
or anything) has on a technical discussion of C90, but
so be it.
It *should* have no bearing at all. The problem is that if you
come here and say that C99 is a "complete and utter joke" or make
similarly inflammatory statements, people are going to react.
If you don't want that reaction, don't make statements like that.
I didn't say I didn't want the reaction. I don't care if there is
or isn't a reaction.
What I care about is whether the technical question has been
addressed or not.
It hasn't been addressed. Nor has fpeek() in a previous thread.
Nor ESC_STR.
And I am not personally familiar with the philosophy of
language standards.
"Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a5770xjw.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
So is it right to expect directories to be covered by C90?
Of course not. C90 is frozen, defined by the ISO standard published
in 1990. It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
I'm guessing that you meant something by "expect" that differs from
its usual meaning. Can you clarify?
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?
Ah, that's a very different question. I have no answer, because
I don't care. C90 is what it is. Of course it could have been different.
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
None that I can think of.
But it could potentially be even neater if it was hidden
away behind a standard fopen etc call.
That's my question.
Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a directory name give you access to the directory entries.
I don't think it would be a particularly good idea.
Why not hide it in fopen()? That's my original question.
Why should it be opendir() instead of fopen()?
That's my unanswered question.
You won't get a definitive answer. In your own language, you can
do it that way or not. My opinion on whether it's a good idea is
irrelevant, since I won't be using your language.
I might have
some interest in it being logically consistent, but directories do
not seem to present any such issues. You can use fopen(), you can use opendir(), you can invent your own functions, you can leave it out of
the language and depend on outside standards and/or libraries.
And I am not personally familiar with the philosophy of
language standards.
Because there's no such thing,
nor does there need to be.
Different
languages are designed by different people with different goals and motivations. I doubt that anyone here can tell you anything useful
about how your personal language should be defined. You can do whatever
you like.
Plus you just said above that it would be reasonable for
the POSIX directory operations to be directly incorporated
into C90+'s "standard library".
The C90 people didn't choose to do that.
That doesn't necessarily constrain the C90+ people.
Right.
But it does beg the question - would it have been
ACCEPTABLE for the ANSI 89 people to have
put that directory manipulation stuff into the C89
standard IF they could do so quickly?
Yes.
Or would that be an ABOMINATION?
No. (WTF??)
What is the PHILOSOPHY about what SHOULD
be included in a standard?
Different standards have different goals. I cannot advise you what your
own standard should be based on, since I don't agree with or care about
your goals.
I don't see what bearing my opinion on C99 (or politics,
or anything) has on a technical discussion of C90, but
so be it.
It *should* have no bearing at all. The problem is that if you
come here and say that C99 is a "complete and utter joke" or make
similarly inflammatory statements, people are going to react.
If you don't want that reaction, don't make statements like that.
I didn't say I didn't want the reaction. I don't care if there is
or isn't a reaction.
If you post inflammatory statements here, people will react. I'm asking
you, for the sake of avoiding noise in this newsgroup, not to post such statements here.
What I care about is whether the technical question has been
addressed or not.
It hasn't been addressed. Nor has fpeek() in a previous thread.
Nor ESC_STR.
I don't remember what fpeek() is supposed to be;
did you have a question about it?
I think I've discussed ESC_STR with you before.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100hase$24odp$1@dont-email.me...
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
And in essence, when you read from a directory, the only thing you
get is the filename.
You want at least the type of entry as well, surely.
<https://manpages.debian.org/readdir(3)>
No - I'm not attempting to support such sophistication.
If it is actually a subdirectory, then that is indicated with a "/"
at the end of the filename.
What if it's a symlink to a directory?
I guess that can be left as "implementation-defined". I would treat it
the same as a hardlink, ie a directory.
As far as I am aware, IBM mainframes are the most important systems on
the planet. The only professional ones too. Everything else is a clown
show.
Ritchie is no longer here to adjudicate whether something close to
C90 - in the spirit of the original C, is the true successor to his
language, and which one is a complete and utter joke of no relation
to anything he designed.
"Paul Edwards" <mutazilah@gmail.com> wrote in message news:100j09o$2f04b$1@dont-email.me...
Manipulating directories is not as important as manipulating
files. The C90 people didn't leave out file manipulation (I
think the ISO Pascal people left it out, at least originally).
Actually, I think it was program paramaters that weren't
specified.
But again - maybe it is C90 that was wrong to specify argc
and argv and the Pascal people got it right.
That depends on the philosophy of language standards.
And I am not personally familiar with the philosophy of
language standards.
On Tue, 20 May 2025 19:33:18 +1000, Paul Edwards wrote:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100hase$24odp$1@dont-email.me...
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
And in essence, when you read from a directory, the only thing you
get is the filename.
You want at least the type of entry as well, surely.
<https://manpages.debian.org/readdir(3)>
No - I'm not attempting to support such sophistication.
It's not about sophistication, it's about efficiency in real-world
operation. Without that, you will need to do a second lookup in nearly
every common directory-traversal case.
If it is actually a subdirectory, then that is indicated with a "/"
at the end of the filename.
What if it's a symlink to a directory?
I guess that can be left as "implementation-defined". I would treat it
the same as a hardlink, ie a directory.
The key point about symlinks is they are not the same as hardlinks.
On Tue, 20 May 2025 19:36:06 +1000, Paul Edwards wrote:
Ritchie is no longer here to adjudicate whether something close to
C90 - in the spirit of the original C, is the true successor to his language, and which one is a complete and utter joke of no relation
to anything he designed.
Remember also that his vision of C was something very much designed to
work on a Unix-type OS. Or at least with a POSIX API layer underneath. Without that, C is a pretty sad language indeed.
On 2025-05-20, Paul Edwards <mutazilah@gmail.com> wrote:
"Paul Edwards" <mutazilah@gmail.com> wrote in message news:100j09o$2f04b$1@dont-email.me...
Manipulating directories is not as important as manipulating
files. The C90 people didn't leave out file manipulation (I
think the ISO Pascal people left it out, at least originally).
Actually, I think it was program paramaters that weren't
specified.
But again - maybe it is C90 that was wrong to specify argc
and argv and the Pascal people got it right.
That depends on the philosophy of language standards.
And I am not personally familiar with the philosophy of
language standards.
ANSI C was codifying a lot of existing practices.
C programs starting with a main() function which takes argc and argv was
in this category. It came from Unix, and C implementations on other platforms imitated that.
C appeared as the systems programming language of Unix.
C on Unix had a way to process directories via library
functions.
Implementors of C on other systems choose to implement some functions
from Unix, and not others. They didn't implement the directory-related
ones, rendering them nonportable, and unsuitable for standardizing
into the language.
From my understanding, C and Unix standardization were separate but
somewhat coordinated efforts. Unix things that didn't get into C were standardized by the emerging Unix standard.
Today, if I want a program tha tneeds to walk directories, I use the
POSIX C library. It is widely implemented. The program won't run
absolutely everywhere, but it will run on many embedded systems,
as well as supercomputers, and everything in between.
... maybe it is C90 that was wrong to specify argc and argv and
the Pascal people got it right.
My programs work anywhere.
We have very different goals.
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
... I reserve the right to insist on KB, MB, and GB instead of these nonsensical new inventions.
non-blocking sockets would be in the standard, using an interface based
on fopen/fread/fwrite/fclose.
"Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a5770xjw.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
So is it right to expect directories to be covered by C90?
Of course not. C90 is frozen, defined by the ISO standard published
in 1990. It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
I'm guessing that you meant something by "expect" that differs from
its usual meaning. Can you clarify?
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?
Ah, that's a very different question. I have no answer, because
I don't care. C90 is what it is. Of course it could have been different.
[...]
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
None that I can think of.
Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a directory name give you access to the directory entries.
(open-directory ".")#<dir-stream b7b90820>
(get-line *1)"htrailer.txr"
(get-line *1)"y.output.bison"
(get-line *1)"jmp.S"
(open-file "/etc/hosts")#<file-stream /etc/hosts b7b7a8b0>
(get-line *5)"127.0.0.1\tlocalhost"
(get-line *5)"127.0.1.1\tsun-go"
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation.> As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c
And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.
Other things like size and creation date are not available,
and C90 does not guarantee that such concepts even
exist. C90 does guarantee that files exist though.
And in fact, files are the only thing that are ever actually
externally visible to a C90-compliant program.
Now it so happens that I need to traverse directories.
I want this to run on MVS/TSO as well as other environments,
and I have a way of making directories appear, even though
they don't really exist on the mainframe (traditional, like
MVS 3.8J).
So they will appear to be an 8.8 files, simlar to traditional
8.3 with FAT.
Plus I want to work with modern FAT long filenames, and
Unix too.
The folder routines will do everything I need.
The mkfldr() routine won't work under my MVS/TSO design,
but that doesn't bother me. I can probably make rmfldr() work,
but don't intend to for now.
Now C90 doesn't have folder/directory operations (such as
opendir()) for a reason.
That reason may cease to exist if I can demonstrate directories
grafted onto the mainframe.
And C90 (etc) could potentially be extended to include a folder.h
Or this could be something that doesn't belong in the C standard.
Or alternatively, this could be something incorporated within the
C90 standard, as designed.
I have already demonstrated zmodem working on a COM1
stream opened with fopen (shipped with Freewindows at
pdos.org). Interesting note is that I needed to escape the
MSDOS x'1a' (EOF) because something was swallowing it.
And I demonstrated it via my mainframe emulator too - giving
the mainframe the ability to connect to a BBS and do a FREQ.
Should work on real hardware too, using a TN3270 OSA/ICC
as an encapsulation layer, as I previously demonstrated with
an EBCDIC ANSI terminal.
So the next thing that I would potentially encapsulate is
something like this:
fopen(argv[1], "w+");
where the argument might be "/some/dir/" (with a terminating /
for good measure).
And then do a fputs("dir\n");
And fgets() and collect each name from the folder, using something
similar to those folder routines above - all done internally so not
really relevant.
Possibly a rewind() to reset the EOF condition of the fgets.
Or maybe an fseek to offset 0 from SEEK_CUR.
And fputs("mkdir subdir\n"); to make a subdirectory.
And fputs("rmdir subdir\n"); to remove one.
And fputs("cd ..\n"); to change directory.
I'm wondering what the underlying principles here are that
would govern the correct thing to do.
Maybe I shouldn't be overloading the FILE concept to make
an artificial file.
Or maybe it is the other way around - we should perhaps
eliminate lots of APIs - like the TCP/IP ones - and stick
them all inside streams, and perhaps FILE is a misnomer,
it should have really been called STREAM.
Any thoughts (besides "get a life!")?
Thanks. Paul.
nonsensical new inventions. The world knows full well that bitI must emphatically disagree - long before MiB was invented, I had
and byte prefixes are measured in powers of 2, ...
There is a practical barrier - while C was developed in the context of
Unix, which had a lot of influence on the design of C, that design has
also always been motivated by a desire to, among other things, be as
widely portable as possible.
The most different structure that I'm personally familiar with is
VMS, where the closest equivalent to a Unix directory was versioned.
If you specify a directory with a version number, you get that
version of that directory (if it exists); if you don't specify a
version, by default you get the latest version.
Your definition of "real world", is probably "not C90".
Your "real world" applications won't work on traditional MVS ...
The key point about symlinks is they are not the same as hardlinks.
There is no such universal concept for either of those things,
That's a complete and utter lie.
On 5/20/25 11:43, Richard Heathfield wrote:
...
nonsensical new inventions. The world knows full well that bitI must emphatically disagree - long before MiB was invented, I had
and byte prefixes are measured in powers of 2, ...
arguments with people who were certain they were measured in powers of
10, and could point at authorities supporting those views.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87tt5ezx9y.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a5770xjw.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
So is it right to expect directories to be covered by C90?
Of course not. C90 is frozen, defined by the ISO standard published
in 1990. It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
I'm guessing that you meant something by "expect" that differs from
its usual meaning. Can you clarify?
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?
Ah, that's a very different question. I have no answer, because
I don't care. C90 is what it is. Of course it could have been different.
My question is not "could", it is "should", or "ideally".
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
None that I can think of.
Ok, that's a great start. That answers one of my questions.
But it could potentially be even neater if it was hidden
away behind a standard fopen etc call.
That's my question.
Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.
I don't think it would be a particularly good idea.
Can you tell me why?
You may as well throw in the entire POSIX, the entire C23,
and the entire C++ into C90 too. There needs to be some
philosophy to set constraints.
C90 wasn't designed by one person. K&R C was more-or-less
designed by one person. But I don't want a language designed
by one person.
I want a language that is accepted by a committee.
Not the C99 committee. Not the C23 committee.
The C90+ committee. I would probably decide who gets
to sit on the committee though.
Richard would probably be on the committee, as he has
a shared goal. It's not likely that he wants to though, and
note that the committee doesn't formally exist yet. And
nor does it need to formally exist. It is enough to have
a discussion in comp.lang.c and when you, Keith, give
the go-ahead for directory manipulations to have been
incorporated into C90 - because you can't see anything
wrong with it - then the theoretical committee can
continue their work on directory manipulations in C90+.
Plus you just said above that it would be reasonable for
the POSIX directory operations to be directly incorporated
into C90+'s "standard library".
The C90 people didn't choose to do that.
That doesn't necessarily constrain the C90+ people.
Right.
But it does beg the question - would it have been
ACCEPTABLE for the ANSI 89 people to have
put that directory manipulation stuff into the C89
standard IF they could do so quickly?
Yes.
Or would that be an ABOMINATION?
No. (WTF??)
I don't understand your question.
I have a series of questions that begin with:
If xyz had been added to the C90 standard, would you have
considered that to be odd/wrong? If so, why?
It hasn't been addressed. Nor has fpeek() in a previous thread.
Nor ESC_STR.
I don't remember what fpeek() is supposed to be;
See if a stream is known to have characters in it.
If fpeek had been added to the C90 standard, would you have
considered that to be odd/wrong? If so, why? If not, what form
should it have taken?
I think I've discussed ESC_STR with you before.
But not to the point where these questions were answered:
If ESC_STR had been added to the C89 standard, because
a majority of the committee had decided they wanted to
support basic ANSI X3.64, would you have considered that
to be odd/wrong? If so, why? If not, do you think the define
ESC_STR and ESC_CHAR are a bad naming convention,
and if so, what do you think would have been better, and why?
And what header file would you have put them in?
If instead, C90 had already been published, and suddenly
committeee members realized they had forgotten about
ANSI X3.64 terminals and quickly formed a C91 standard
to add just this one feature, what header file would you
have put it in, and why?
On 2025-05-20, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:[...]
"Paul Edwards" <mutazilah@gmail.com> writes:
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
None that I can think of.
There was a significant barrier. The ANSI group which standardized
C was mainly looking at surveying and codifying existing practice.
Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.
I implemented something like this. It is fine; I don't regret it.
(open-directory ".")#<dir-stream b7b90820>
(get-line *1)"htrailer.txr"
(get-line *1)"y.output.bison"
(get-line *1)"jmp.S"
(open-file "/etc/hosts")#<file-stream /etc/hosts b7b7a8b0>
(get-line *5)"127.0.0.1\tlocalhost"
(get-line *5)"127.0.1.1\tsun-go"
On 21/05/2025 03:40, James Kuyper wrote:
On 5/20/25 11:43, Richard Heathfield wrote:
...
nonsensical new inventions. The world knows full well that bitI must emphatically disagree - long before MiB was invented, I had
and byte prefixes are measured in powers of 2, ...
arguments with people who were certain they were measured in powers of
10, and could point at authorities supporting those views.
I must emphatically double down and insist that you were right and they
were wrong wrong wrongawrong wrong.
We are not alone, you and I. Maybe we could do a badge or something?
Have your people talk to my people and we'll do lunch.
On 20/05/2025 17:19, David Brown wrote:
While there are some people who, for reasons that still escape me,
prefer C90 over C99
I will not fight you, David.
On 21/05/2025 06:50, Richard Heathfield wrote:
On 21/05/2025 03:40, James Kuyper wrote:
On 5/20/25 11:43, Richard Heathfield wrote:
...
nonsensical new inventions. The world knows full well that bit
and byte prefixes are measured in powers of 2, ...
I must emphatically disagree - long before MiB was
invented, I had arguments with people who were certain
they were measured in powers of 10, and could point at
authorities supporting those views.
I must emphatically double down and insist that you were right
and they were wrong wrong wrongawrong wrong.
We are not alone, you and I. Maybe we could do a badge or
something? Have your people talk to my people and we'll do lunch.
The answer here, I think, is obvious. Instead of rolling back
progress 35 years to C90, we need to go further. In 1970 the
perfect extendable programming language came to light - Forth.
You can extend it in any way you like. There is an official ANSI
standard, but AFAIK no ISO standard, with no change since 1994
(and people don't pay much attention to it anyway).
Even better, you can write :
: 2 1.995262315 ;
and redefine "2" to be the tenth root of 1000. Now 2 ^ 10 =
1000, KiB and KB are identical, and the world is united again.
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if they
said he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
Mr. Edwards also believes that MS-DOS is the be-all and end-all of operating systems.
On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
Didn't they use software to manage that?
A half-baked directory access interface that serves only a
small subset of programs (which access only their own file-based
data model that can be constrained to fall within the limitations)
is not going to be worth pushing all the way up into the
language standard.
certainly useful to be supported as library functions. And I'd
write and provide directory abstractions also as add-on library
functions (as opposed to part of a language; but my opinion on
that is not strong). Historically other languages even missed to
To sum up; on the way from the OS entity to the user interface
there's various abstraction levels. Depending on the service I'd
like to provide I'd probably choose different abstraction layers.
I _don't_ think that a directory abstraction should be *inherent*
part of the C language, but if necessary provided as a _library_.
On Tue, 20 May 2025 22:26:57 -0400, James Kuyper wrote:
There is a practical barrier - while C was developed in the context of Unix, which had a lot of influence on the design of C, that design has
also always been motivated by a desire to, among other things, be as
widely portable as possible.
Furthermore, back in that day, some OSes (like MS-DOS) were pretty limited
in their functionality, without even multi-tasking capability.
That situation has improved somewhat. Nowadays the world divides into POSIX-like versus non-POSIX-like. With the latter trying to become more POSIX-like over time.
The most different structure that I'm personally familiar with is
VMS, where the closest equivalent to a Unix directory was versioned.
If you specify a directory with a version number, you get that
version of that directory (if it exists); if you don't specify a
version, by default you get the latest version.
Only regular files were versioned; directories were files, but they were specially managed by the OS, and they had to have the .DIR suffix and the version number was always 1.
On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:
Your definition of "real world", is probably "not C90".
Precisely.
Your "real world" applications won't work on traditional MVS ...
Let's face it: MVS stopped being part of the "real world" a long time ago. Just about the time IBM's mainframe business started circling the gurgler.
(Also, I think it's called "z/OS" now.)
The key point about symlinks is they are not the same as hardlinks.
There is no such universal concept for either of those things,
Yes there is: they are defined in POSIX, which is an official standard,
after all.
On 20/05/2025 22:51, Paul Edwards wrote:
That's a complete and utter lie.
That's a complete and utter over-reaction.
This group takes such things to heart.
If you seek a helpful
reaction from this group, you'd do better to keep the tone
non-inflammatory
and rebut such claims quietly and dispassionately
rather than jump on your destrier and grab your
lance.
You've already been badged a 'troll'.
Try not to let the cap fit.
Try not to let the cap fit.
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100jkvt$2m0ln$1@dont-email.me...
On 20/05/2025 22:51, Paul Edwards wrote:
That's a complete and utter lie.
That's a complete and utter over-reaction.
Has no-one ever lied you saying something? Calling
the lying statement a lie is hardly an over-reaction.
Suing him for defamation of character might be though.
Maybe. Only maybe.
It artificially merges two very distinct concepts for no good
reason that I can see. Operations that make sense for files make
far less sense for directories. There's no shortage of interfaces
for dealing with directories (POSIX, C++, Perl, etc.), and I'm not
aware of any of them that conflate directories and files. It's true
that "(almost) everything is a file" is part of the Unix philosophy,
and directories are typically stored as file-like objects with most
of the same attributes that files can have, but I can't think of
any good reason for higher level code to care about that.
Directory access is largely a solved problem. If you insist on
creating yet another solution, I recommend following the existing
solutions.
You may as well throw in the entire POSIX, the entire C23,
and the entire C++ into C90 too. There needs to be some
philosophy to set constraints.
So invent a philosophy that meets your requirements.
C90 wasn't designed by one person. K&R C was more-or-less
designed by one person. But I don't want a language designed
by one person.
I want a language that is accepted by a committee.
Not the C99 committee. Not the C23 committee.
The C90+ committee. I would probably decide who gets
to sit on the committee though.
I would frankly be surprised if anyone other than you were willing
to be on that committee. Remember that being a member of a language
standard committee is a lot of work, and is typically unpaid.
Richard would probably be on the committee, as he has
a shared goal. It's not likely that he wants to though, and
note that the committee doesn't formally exist yet. And
nor does it need to formally exist. It is enough to have
a discussion in comp.lang.c and when you, Keith, give
the go-ahead for directory manipulations to have been
incorporated into C90 - because you can't see anything
wrong with it - then the theoretical committee can
continue their work on directory manipulations in C90+.
Do not mistake my idle comment for an endorsement.
Plus you just said above that it would be reasonable for
the POSIX directory operations to be directly incorporated
into C90+'s "standard library".
The C90 people didn't choose to do that.
That doesn't necessarily constrain the C90+ people.
Right.
But it does beg the question - would it have been
ACCEPTABLE for the ANSI 89 people to have
put that directory manipulation stuff into the C89
standard IF they could do so quickly?
Yes.
Or would that be an ABOMINATION?
No. (WTF??)
I don't understand your question.
If you don't know what "WTF" means, I suggest a web search.
I was
expression surprise that anyone would use a loaded word like
"abomination" for something so innocuous.
I have a series of questions that begin with:
If xyz had been added to the C90 standard, would you have
considered that to be odd/wrong? If so, why?
I'm unlikely to be interested in answering most of those questions.
I don't see how they're in any way relevent, even to what you're
working on. I have no objection to a new language based on C90,
but agonizing about what the C90 committee should or should not
have done is IMHO a waste of time.
It hasn't been addressed. Nor has fpeek() in a previous thread.
Nor ESC_STR.
I don't remember what fpeek() is supposed to be;
See if a stream is known to have characters in it.
I'd need a more precise explanation. Does it just return a
true/false value?
If so, how does it differ from feof() and/or
ferror()?
What would it do on an interactive stream?
What is the use case?
If fpeek had been added to the C90 standard, would you have
considered that to be odd/wrong? If so, why? If not, what form
should it have taken?
I have no opinion on that.
I think I've discussed ESC_STR with you before.
But not to the point where these questions were answered:
If ESC_STR had been added to the C89 standard, because
a majority of the committee had decided they wanted to
support basic ANSI X3.64, would you have considered that
to be odd/wrong? If so, why? If not, do you think the define
ESC_STR and ESC_CHAR are a bad naming convention,
and if so, what do you think would have been better, and why?
And what header file would you have put them in?
If instead, C90 had already been published, and suddenly
committeee members realized they had forgotten about
ANSI X3.64 terminals and quickly formed a C91 standard
to add just this one feature, what header file would you
have put it in, and why?
C90 *could* have added a way to refer to the escape character
(which exists, with different values, in both ASCII and EBCDIC).
The sensible way to do that would have been to allow a \e escape in
character constants and string literals. Some languages have exactly
that feature, and several C compilers support it as an extension.
No other special character values are defined as named constants
in headers.
Perhaps I would have favored standardizing \e at the time, but that
ship sailed decades ago. I'd probably favor a proposal to add \e
to C2y.
In practice, if I need an escape character, I use '\x1b'. I've never
needed to use an EBCDIC escape character. If I did, I'd use '\x27'.
If I needed to support both ASCII and EBCDIC escape characters,
I'd find a way to do that.
None of this requires language or standard
library support.
It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name. The problem
with that is that on some systems, file names can legally include
newline characters. I don't suggest it's not a horrible idea to
take advantage of that, but it is something that would have to be
addressed in a language standard.
On 20/05/2025 18:58, Scott Lurndal wrote:they
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if
operatingsaid he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
Mr. Edwards also believes that MS-DOS is the be-all and end-all of
systems.
If he can be persuaded to leave that kind of stuff out of his posts, he
might talk more about C.
The language standard would need to say something along
the lines of "if any filenames contain a NL character, the
results are implementation-defined".
Any issue with that?
"Paul Edwards" <mutazilah@gmail.com> writes:
See if a stream is known to have characters in it.
I'd need a more precise explanation. Does it just return a
true/false value? If so, how does it differ from feof() and/or
ferror()? What would it do on an interactive stream? What is the
use case?
"David Brown" <david.brown@hesbynett.no> wrote in message news:100k2q7$2o7b7$3@dont-email.me...
On 20/05/2025 18:58, Scott Lurndal wrote:they
David Brown <david.brown@hesbynett.no> writes:
On 20/05/2025 15:47, Paul Edwards wrote:
Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
They were justified in thinking that "Richie himself endorsed the
standard" is a totally irrelevant argument. They would be wrong if
operatingsaid he had "become deranged".
David, it's not particularly productive to continue to feed the trolls.
Mr. Edwards also believes that MS-DOS is the be-all and end-all of
systems.
If he can be persuaded to leave that kind of stuff out of his posts, he
might talk more about C.
That statement of belief - nor anything close to that -
exists in any of my recent, nor even my past, posts.
So I have already done as requested - and always have.
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100jkvt$2m0ln$1@dont-email.me...
On 20/05/2025 22:51, Paul Edwards wrote:
That's a complete and utter lie.
That's a complete and utter over-reaction.
Has no-one ever lied you saying something? Calling
the lying statement a lie is hardly an over-reaction.
Your advice is better directed at Scott. He's the one
who made the original inflammatory statement in
question.
And try not to accept future ridiculous claims from Scott
on trust. He's not trustworthy.
"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:100je5c$2l1b2$1@dont-email.me...
certainly useful to be supported as library functions. And I'd
write and provide directory abstractions also as add-on library
functions (as opposed to part of a language; but my opinion on
that is not strong). Historically other languages even missed to
To sum up; on the way from the OS entity to the user interface
there's various abstraction levels. Depending on the service I'd
like to provide I'd probably choose different abstraction layers.
I _don't_ think that a directory abstraction should be *inherent*
part of the C language, but if necessary provided as a _library_.
Sorry if I didn't specify that clearly.
Of course I expect the directory handling to be in a library.
Just as fopen() is in the library section of the C90 standard.
The question is whether at least "half baked" directories
should/could have been added the C90.
It would have violated the "existing practice" spirit (which
doesn't bother me - note - I failed to explicitly state this),
but it wouldn't have violated the "portable" spirit.
So long as you are careful and keep it "half-baked", you
can have a portable file system in the spirit of C90
portability.
There were reasons this couldn't be done in 1990 (actually,
it is C89 that matters here, so 1989 - and in fact, it was a
static draft even earlier than that). But I wish to do it now,
belatedly.
BFN. Paul.
Scott has a very long reputation in this and related newsgroups,
and is very much a trustworthy poster.
On 21/05/2025 16:00, David Brown wrote:
Scott has a very long reputation in this and related newsgroups,
and is very much a trustworthy poster.
In a society of strangers, it is easy to forget that some are
less strange than others.
Thanks to a zealot best forgotten, I have been AWOL from this
group for a number of years, but on my recent return I lurked
here for some while before dipping my toe back in the water, and
I was glad to recognise a few old acquaintances (dare I say
'friends'?) in the feed; strange though they undoubtedly are,
they are less strange to me than others.
Scott Lurndal is *not* a name I recall from a decade or so back
(Fluhrer yes, Lurndal not so much), but it quickly became
apparent to me that he has become a regular fixture here, and one
who is evidently respected by people whose opinion I have over
decades come to respect. I am used to arguing with such people
while retaining their respect for me and my respect for them. We
do not generally snipe at each other, and when we do we try to
snipe *gently*. I don't *know*, but I can at least *surmise* from
the tangible respect in which he is held, that Mr Lurndal is of
like mind.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 21/05/2025 16:00, David Brown wrote:
Scott has a very long reputation in this and related newsgroups,
and is very much a trustworthy poster.
In a society of strangers, it is easy to forget that some are
less strange than others.
Thanks to a zealot best forgotten, I have been AWOL from this
group for a number of years, but on my recent return I lurked
here for some while before dipping my toe back in the water, and
I was glad to recognise a few old acquaintances (dare I say
'friends'?) in the feed; strange though they undoubtedly are,
they are less strange to me than others.
Scott Lurndal is *not* a name I recall from a decade or so back
My first post was to rec.radio.scanner in 1992, if I recall correctly.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87ldqqzfj0.fsf@nosuchdomain.example.com...[...]
[...]Directory access is largely a solved problem. If you insist on
creating yet another solution, I recommend following the existing
solutions.
Well - that would be:
struct dirent
{
}[...]
And rmdir() - also flexible - allow failure
Are you sure - given the constraints - that a different interface
isn't appropriate?
Do not mistake my idle comment for an endorsement.
I don't need an official endorsement. What I need to know
is that you can't think of any philosophical reason that the
C90 committee shouldn't have done that - had they chosen
to do so.
I think I've discussed ESC_STR with you before.
But not to the point where these questions were answered:
If ESC_STR had been added to the C89 standard, because
a majority of the committee had decided they wanted to
support basic ANSI X3.64, would you have considered that
to be odd/wrong? If so, why? If not, do you think the define
ESC_STR and ESC_CHAR are a bad naming convention,
and if so, what do you think would have been better, and why?
And what header file would you have put them in?
If instead, C90 had already been published, and suddenly
committeee members realized they had forgotten about
ANSI X3.64 terminals and quickly formed a C91 standard
to add just this one feature, what header file would you
have put it in, and why?
C90 *could* have added a way to refer to the escape character
(which exists, with different values, in both ASCII and EBCDIC).
The sensible way to do that would have been to allow a \e escape in
character constants and string literals. Some languages have exactly
that feature, and several C compilers support it as an extension.
Ok, but for a C90+ or C91 or whatever standard - it would
require a change to the compiler itself to do the above.
That would be reasonable for a new language, but not for
the C90 committee.
Or my committee where I can't get any compiler vendor
at all (except for the compilers I control) to add such a thing.
Updating a header file is a trivial change in comparison.
So I think a header file is the proper way to go.
Do you not agree with this?
Or if you can at least understand why I would prefer a
header file - would you update an existing one or create
a new one (perhaps "c90ext.h" - C90 extensions), and
throw this define in - and what name would you give
this define?
No other special character values are defined as named constants
in headers.
Perhaps they should be.
Perhaps I would have favored standardizing \e at the time, but that
ship sailed decades ago. I'd probably favor a proposal to add \e
to C2y.
This "ship sailed" is some sort of semantic issue.
As you noted - C2y can be updated.
And also I can create a C90+ standard outside of
anything ISO does.
The ship hasn't sailed, from my point of view.
I have stayed in port for the last nearly 40 years.
In practice, if I need an escape character, I use '\x1b'. I've never
needed to use an EBCDIC escape character. If I did, I'd use '\x27'.
If I needed to support both ASCII and EBCDIC escape characters,
I'd find a way to do that.
Thats's my question - "find a way". Specifically - what way?
None of this requires language or standard
library support.
It is unclear to me why you are saying that. First of all, you
haven't specified what "find a way" is.
So I don't know what the alternative is to updating the
language standard.
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87h61ezf76.fsf@nosuchdomain.example.com...
It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name. The problem
with that is that on some systems, file names can legally include
newline characters. I don't suggest it's not a horrible idea to
take advantage of that, but it is something that would have to be
addressed in a language standard.
And - that's part of my question.
The language standard would need to say something along
the lines of "if any filenames contain a NL character, the
results are implementation-defined".
Ditto MVS would be the reason why mkdir() can't be
implemented - and mentioned in the Rationale, not the Standard.
"Paul Edwards" <mutazilah@gmail.com> writes:[...]
So I don't know what the alternative is to updating the
language standard.
You mean creating your own language standard based on the existing C90 standard. C90 itself will change. Please be clear on that point.
I don't need an official endorsement. What I need to know
is that you can't think of any philosophical reason that the
C90 committee shouldn't have done that - had they chosen
to do so.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-05-20, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:[...]
"Paul Edwards" <mutazilah@gmail.com> writes:
As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.
None that I can think of.
There was a significant barrier. The ANSI group which standardized
C was mainly looking at surveying and codifying existing practice.
Agreed. I consider that a practical barrier, not a "LOGICAL" one.
The ANSI C committee *could* have added directory operations to the C standard library. (I'm not suggesting that they should have.)
[...]
Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.
I implemented something like this. It is fine; I don't regret it.
(open-directory ".")#<dir-stream b7b90820>
(get-line *1)"htrailer.txr"
(get-line *1)"y.output.bison"
(get-line *1)"jmp.S"
(open-file "/etc/hosts")#<file-stream /etc/hosts b7b7a8b0>
(get-line *5)"127.0.0.1\tlocalhost"
(get-line *5)"127.0.1.1\tsun-go"
It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name.
(touch "foo\nbar")t
(sh "ls foo*bar")'foo'$'\n''bar'
(find-if (op fnmatch "foo*bar") (get-lines (open-directory ".")))"foo\nbar"
(get-char (open-directory "."))** get-char: not supported by stream #<dir-stream b7b0dd80>
"Paul Edwards" <mutazilah@gmail.com> writes:
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing. I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII. As far as
I know, no existing terminal or emulator uses the EBCDIC escape
character, and I see no need for a terminal that does so. (Terminals
used with mainframes operate very differently.)
"Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87h61ezf76.fsf@nosuchdomain.example.com...
It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name. The problem
with that is that on some systems, file names can legally include
newline characters. I don't suggest it's not a horrible idea to
take advantage of that, but it is something that would have to be
addressed in a language standard.
And - that's part of my question.
The language standard would need to say something along
the lines of "if any filenames contain a NL character, the
results are implementation-defined".
No, it would not.
I merely observed that one particular directory interface,
if I understand it correctly, would not correctly handle files
whose names contain a newline character. If you want to define a
directory interface in your new language, I suggest that it should
not have this limitation. If it doesn't have this limitation,
there's no need to make the results implementation-defined.
Accessing directories via fopen() would make it difficult but not
impossible to handle such file names correctly. Perhaps that's one
reason why (as far as I know) no existing directory interfaces use
fopen().
[...]
Ditto MVS would be the reason why mkdir() can't be
implemented - and mentioned in the Rationale, not the Standard.
mkdir() could be defined in your standard library, but could always fail
on MVS. (I'm assuming MVS doesn't support creating a directory.)
Or you could leave it out, making your language less useful on systems
that do support creating directories.
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?
On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:....
The key point about symlinks is they are not the same as hardlinks.
There is no such universal concept for either of those things,
Yes there is: they are defined in POSIX, which is an official standard, after all.
And MSDOS 4.0 - one of the systems I am interested in -
is not "trying to become POSIX-like".
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100jhh4$2lgt3$3@dont-email.me...
On Tue, 20 May 2025 22:26:57 -0400, James Kuyper wrote:
There is a practical barrier - while C was developed in the context of
Unix, which had a lot of influence on the design of C, that design has
also always been motivated by a desire to, among other things, be as
widely portable as possible.
Furthermore, back in that day, some OSes (like MS-DOS) were pretty limited >> in their functionality, without even multi-tasking capability.
And note that I sitll expect the proposed C90+ to support MSDOS.
That situation has improved somewhat. Nowadays the world divides into
POSIX-like versus non-POSIX-like. With the latter trying to become more
POSIX-like over time.
I'm not interested in restricting myself to "nowadays".
That doesn't mean I want to add a "far" keyword though.
Not that I would rule it out either.
And MSDOS 4.0 - one of the systems I am interested in -
is not "trying to become POSIX-like".
[snip]
The later UNIX-like file system NTFS ...
On 5/20/25 23:37, Lawrence D'Oliveiro wrote:
On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:...
The key point about symlinks is they are not the same as hardlinks.
There is no such universal concept for either of those things,
Yes there is: they are defined in POSIX, which is an official standard,
after all.
It is a standard. It is not universal. On the Windows machines that I've used, tho closest equivalent to a symlink works significantly
differently from a POSIX symlink.
On Thu, 22 May 2025 02:20:36 +0200, Jakob Bohm wrote:
The later UNIX-like file system NTFS ...
It was (and is) hard to describe NTFS as “Unix-like”. Yes, it had hierarchical directories and long(ish) file names, but not much else.
Drive letters were inherited (indirectly) from DEC OSes, of all things, along with an insistence on having filename extensions, restrictions on characters allowed in names etc.
Symlinks were not even added until Windows Vista. And you have to have special privileges to create them.
An official standard that isn't even supported by Windows, which is far
more important than any POSIX system in existence.
Except z/OS obviously.
But I'm not interested in the bolt-on z/OS Unix.
Fun fact: even IBM mainframes run Linux now.
I was hoping that Mr Edwards would be another such. I was (and
remain) very ready to give him a fair crack at the whip, albeit
not at the expense of people respected by people I respect, as it
were. It seems that Mr Edwards may have come to us from a more
combative environment where accusations of dishonesty are rife
and hardly noticed; if so, it might take him a while to get used
to a group where we generally treat such disrespectful tactics
with contempt. Let us hope he learns quickly, before he ends up
in too many killfiles.
On 5/21/25 11:37, Richard Heathfield wrote:
...
I was hoping that Mr Edwards would be another such. I was (and
remain) very ready to give him a fair crack at the whip, albeit
not at the expense of people respected by people I respect, as it
were. It seems that Mr Edwards may have come to us from a more
combative environment where accusations of dishonesty are rife
and hardly noticed; if so, it might take him a while to get used
to a group where we generally treat such disrespectful tactics
with contempt. Let us hope he learns quickly, before he ends up
in too many killfiles.
He's been in my killfile for a long time; long enough that I don't
remember when or why. I only see his messages when quoted in other
people's responses. Nothing I've seen from him in this thread has
motivated me to remove him from my killfile.
On Wed, 21 May 2025 19:51:25 -0400, James Kuyper wrote:
On 5/20/25 23:37, Lawrence D'Oliveiro wrote:
On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:...
The key point about symlinks is they are not the same as hardlinks.
There is no such universal concept for either of those things,
Yes there is: they are defined in POSIX, which is an official standard,
after all.
It is a standard. It is not universal. On the Windows machines that I've
used, tho closest equivalent to a symlink works significantly
differently from a POSIX symlink.
So Microsoft didn’t add symlinks until Vista, and then screwed it up, as per usual.
So what else is new?
Are you sure - given the constraints - that a different interface
isn't appropriate?
I have not said or implied that the POSIX directory interface is the
only appropriate one. It does have the considerable advantage that it already exists.
My advice is to study and understand existing solutions before inventing
your own. I can't offer meaningful advice on what's appropriate for
your language.
Do not mistake my idle comment for an endorsement.
I don't need an official endorsement. What I need to know
is that you can't think of any philosophical reason that the
C90 committee shouldn't have done that - had they chosen
to do so.
No, I don't believe you need to know that. I consider the question of
what the C90 committee could theoretically have done in some alternate timeline irrelevant.
Or my committee where I can't get any compiler vendor
at all (except for the compilers I control) to add such a thing.
You don't have a committee.
Still, you claim to be creating a new language that happens to be based
on C90. Are you adding a new constraint that any differences between
C90 and your language cannot require compiler changes?
Changing existing library implementations is not significantly easier
than changing existing compiler implementations. There are open source implementations of both.
With this new information that you're unwilling to do anything that
requires compiler changes, it seems to me that you can achieve your
goals by taking an existing conforming C90 implementation and adding
some library code (headers and implementation).
One more time, C90 itself will not change. You're free to define your
own language/library/whatever based on C90, but it will not be C90.
I have stayed in port for the last nearly 40 years.
In practice, if I need an escape character, I use '\x1b'. I've never
needed to use an EBCDIC escape character. If I did, I'd use '\x27'.
If I needed to support both ASCII and EBCDIC escape characters,
I'd find a way to do that.
Thats's my question - "find a way". Specifically - what way?
None of this requires language or standard
library support.
It is unclear to me why you are saying that. First of all, you
haven't specified what "find a way" is.
I have: "support both ASCII and EBCDIC escape characters". It's not something I've ever needed to do, so I have not spent time or effort
deciding how to do it.
So I don't know what the alternative is to updating the
language standard.
You mean creating your own language standard based on the existing C90 standard. C90 itself will not change. Please be clear on that point.
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing.
I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII. As far as
I know, no existing terminal or emulator uses the EBCDIC escape
character,
and I see no need for a terminal that does so.
(Terminals
used with mainframes operate very differently.)
mkdir() could be defined in your standard library, but could always fail
on MVS. (I'm assuming MVS doesn't support creating a directory.)
Or you could leave it out, making your language less useful on systems
that do support creating directories.
I think that if you're making some self-contained solution that must
havce a hierarchical file system, and has to be in C90, then just
code up a filesystem that exists entirely within one file that
you can open for updating in binary mode using fopen("....", "r+b")
and within which you create all the needed structure.
Then you need not have a shred of anything system-specific
in your file code.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
"Paul Edwards" <mutazilah@gmail.com> writes:
<snip>
See if a stream is known to have characters in it.
I'd need a more precise explanation. Does it just return a
true/false value? If so, how does it differ from feof() and/or
ferror()? What would it do on an interactive stream? What is the
use case?
Moreover, what is the definition of 'character' in this context?
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing. I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a575zvmb.fsf@nosuchdomain.example.com...
Hi Keith.
First - thanks a lot of teasing out an unstated assumption.
I am often operating on a set of assumptions. But I don't
list them upfront because I don't actually know what
they are.
Are you sure - given the constraints - that a different interface
isn't appropriate?
I have not said or implied that the POSIX directory interface is the
only appropriate one. It does have the considerable advantage that it
already exists.
My advice is to study and understand existing solutions before inventing
your own. I can't offer meaningful advice on what's appropriate for
your language.
I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?
Changing existing library implementations is not significantly easier
than changing existing compiler implementations. There are open source
implementations of both.
And here you have managed to tease out the unstated assumption.
I can and do use closed-source compilers like Microsoft C 6.0
and Visual Studio 2022.
They produce fantastic code.
But I bring my own library to the table - PDPCLIB. I basically
never use Microsoft's library. Or Watcom or anyone else.
I have: "support both ASCII and EBCDIC escape characters". It's not
something I've ever needed to do, so I have not spent time or effort
deciding how to do it.
The C90 committee was forced to consider that. That's why
'A' to 'Z' are not guaranteed to be consecutive, but '0' to '9' are.
Without either ASCII or EBCDIC mentioned in the C90 standard.
Regardless, that's what I'm after - a decision on how to do it.
If you personally don't want to spend the time and effort and/or
make a decision, that's fine - I'm hoping someone in the group
will do that, and perhaps when they propose a solution you will
chime in and say "no, that's not a good idea for xyz reason".
[...]I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing.
There is - I produce one myself (via emulation) - do you
want me to give you a link? Proven against real mainframe
hardware (despite the claims that my software will never
run on a real mainframe).
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a575zvmb.fsf@nosuchdomain.example.com...
I can't practically change Visual Studio, but even then,
I would be open to negotiation, if someone were to
say "look, all the extant compilers support xyz, and
if you zap offset 156383 of cl.exe in Visual Studio,
it will be brought into line with all the other compilers,
and xyz is the way forward", then I would indeed
consider compiler changes.
But I seriously doubt that xyz even exists, much less
that it could be "fixed" with a 1-byte zap.
So while I don't want to say "I refuse to change
existing compilers", in practice, that is the case.
POSIX wasn't universal when C90 came out, and it still isn't universal
today.
On Thu, 22 May 2025 14:13:53 -0400, James Kuyper wrote:
POSIX wasn't universal when C90 came out, and it still isn't universal
today.
POSIX is very much universal today. The entire Internet runs on POSIX-
based systems. You likely have one in your pocket or purse right now.
On 5/22/25 18:46, Lawrence D'Oliveiro wrote:
On Thu, 22 May 2025 14:13:53 -0400, James Kuyper wrote:
POSIX wasn't universal when C90 came out, and it still isn't universal
today.
POSIX is very much universal today. The entire Internet runs on POSIX-
based systems. You likely have one in your pocket or purse right now.
POSIX systems are quite wide-spread today. That doesn't make them
universal. In order to be universal, there must be no non-POSIX systems,
and that is manifestly not the case. In particular, while there is
support for POSIX subsystem for Windows, it does not fully conform with POSIX, and is not the default when using Windows. There's also systems
with no operating system at all, many of which could (and some of which
do) support a fully conforming implementation of C.
"Paul Edwards" <mutazilah@gmail.com> writes:inventing
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a575zvmb.fsf@nosuchdomain.example.com...
Hi Keith.
First - thanks a lot of teasing out an unstated assumption.
I am often operating on a set of assumptions. But I don't
list them upfront because I don't actually know what
they are.
Are you sure - given the constraints - that a different interface
isn't appropriate?
I have not said or implied that the POSIX directory interface is the
only appropriate one. It does have the considerable advantage that it
already exists.
My advice is to study and understand existing solutions before
your own. I can't offer meaningful advice on what's appropriate for
your language.
I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?
You've been given at least three; you didn't mention POSIX.
The POSIX interface (readdir et al) happens to be the one I'm most
familiar with. In fact it's pretty much the only one I'm familiar with.
I have no comment on the others.
As I've said before, I don't think your idea of doing directory access
via fopen() is practical.
Changing existing library implementations is not significantly easier
than changing existing compiler implementations. There are open source
implementations of both.
And here you have managed to tease out the unstated assumption.
I can and do use closed-source compilers like Microsoft C 6.0
and Visual Studio 2022.
They produce fantastic code.
But I bring my own library to the table - PDPCLIB. I basically
never use Microsoft's library. Or Watcom or anyone else.
If you're going to stick with existing C90 compilers, it seems
to me that all you need for your purposes is an add-on library.
Apparently PDPCLIB is that library.
All your talk of defining
a new language based on C90 (whether you call it C90+, or C91,
or whatever), as far as I can tell, is not useful.
C has *always* been designed to work with libraries in addition to
the standard library. POSIX is just one example. Win32 is another.
And there are countless other libraries, large and small. You don't
want to change the core language (Section 6 of the standard).
You don't need to change the standard library (Section 7); you can
either use it as it's defined or ignore it. You can create and
document your own library that does whatever you want. It doesn't
have to be a "standard".
It's just a library. It may or may not
depend on features of the C90 standard library.
The implementation of that library might have to be modified for
different target systems.
I have: "support both ASCII and EBCDIC escape characters". It's not
something I've ever needed to do, so I have not spent time or effort
deciding how to do it.
The C90 committee was forced to consider that. That's why
'A' to 'Z' are not guaranteed to be consecutive, but '0' to '9' are.
Without either ASCII or EBCDIC mentioned in the C90 standard.
I was specifically talking about the ESCAPE character, which the C90 committee ignored.
Regardless, that's what I'm after - a decision on how to do it.
If you personally don't want to spend the time and effort and/or
make a decision, that's fine - I'm hoping someone in the group
will do that, and perhaps when they propose a solution you will
chime in and say "no, that's not a good idea for xyz reason".
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
There's no portable way for the preprocessor to know whether the
target character set is ASCII, EBCDIC, or something else, but
can it be determined at compile time with a constant expression.
Note that this will likely fail if the target character set is not
based on either ASCII or EBCDIC. That's not likely to be relevant
in the real world, and apparently you've decided for some reason
not to care about the possibility.
[...]I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing.
There is - I produce one myself (via emulation) - do you
want me to give you a link? Proven against real mainframe
hardware (despite the claims that my software will never
run on a real mainframe).
So there's one emulator that nobody other than you uses?
Ok, fine, whatever.
On 2025-05-22, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 5/22/25 18:46, Lawrence D'Oliveiro wrote:
On Thu, 22 May 2025 14:13:53 -0400, James Kuyper wrote:
POSIX wasn't universal when C90 came out, and it still isn't universal >>> today.
POSIX is very much universal today. The entire Internet runs on POSIX-
based systems. You likely have one in your pocket or purse right now.
POSIX systems are quite wide-spread today. That doesn't make them universal. In order to be universal, there must be no non-POSIX systems, and that is manifestly not the case. In particular, while there is
support for POSIX subsystem for Windows, it does not fully conform with POSIX, and is not the default when using Windows. There's also systems
with no operating system at all, many of which could (and some of which
do) support a fully conforming implementation of C.
POSIX is fairly decently supported on Windows by Cygwin.
POSIX is fairly decently supported on Windows by Cygwin.
"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250522161342.990@kylheku.com...
On 2025-05-22, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 5/22/25 18:46, Lawrence D'Oliveiro wrote:
On Thu, 22 May 2025 14:13:53 -0400, James Kuyper wrote:
POSIX wasn't universal when C90 came out, and it still isn't universal >> >>> today.
POSIX is very much universal today. The entire Internet runs on POSIX-
based systems. You likely have one in your pocket or purse right now.
POSIX systems are quite wide-spread today. That doesn't make them
universal. In order to be universal, there must be no non-POSIX systems, >> > and that is manifestly not the case. In particular, while there is
support for POSIX subsystem for Windows, it does not fully conform with
POSIX, and is not the default when using Windows. There's also systems
with no operating system at all, many of which could (and some of which
do) support a fully conforming implementation of C.
POSIX is fairly decently supported on Windows by Cygwin.
You can add anything to anything.
You may as well say that Windows is widely supported, via WINE.
I've made multiple attempts to install WINE. Only one of them,
years ago, worked. Yes, with enough work, I could likely have
got it to work.
POSIX is not universal. Not then. Not now. Unless you want
to DEFINE it that way. ie any non-POSIX machine "doesn't
count".
Common Lisp standard which is from similar period as C includes
directory manipulation. In modern times this is considered one of
least useful part of the language: to run "everywhere" this part is
baroque and promises only a little.
Moreover, what is the definition of 'character' in this context?
Something that fgetc() would be able to consume without blocking.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a575zvmb.fsf@nosuchdomain.example.com...
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing. I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII.
I didn't fully answer this either.
Yes, if you want to be pedantic, the ANSI X3.64 uses the
word ASCII, because they didn't spend any effort considering
that someone might want to do exactly the same thing on an
EBCDIC system - in the future - because there was no such
thing in existence at that time.
But if that committee had spent the effort to consider EBCDIC,
they probably would have reworded the language.
But regardless - if you want to be really pedantic, forget about
ANSI X3.64 completely. I am creating a new standard called
non-ANSI X3.64, which allows either ASCII or EBCDIC,
so any reference to "ASCII" is replaced with "character set"
or any other term that means "ASCII or EBCDIC or maybe
even other things".
I do not believe this is difficult to understand.
I do not believe I have not made myself clear.
However, my perspective may be incorrect, and if you still
don't understand, it would be great if someone could
translate English to English.
I have this problem quite a lot. I don't know why - it's as
clear as day to me. Just like the C90 thing. Obviously I'm
not talking about inventing a time machine and/or sneaking
into the ISO office and changing all their existing copies
of C90 and then all the other copies everywhere in the
world, and all the derivatives too.
That is VERY OBVIOUS to me.
But for whatever reason, my casual use of "update C90"
is treated as if I am about to invent not just a time machine,
but coerce the existing members of the C90 committee to
do what I want.
Which is obviously ridiculous, so "clearly" not what I meant.
And the obvious alternative to the above, was obvious all
along. TO ME.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87bjrkxonr.fsf@nosuchdomain.example.com...
Hi Keith.
I can now see a series of disconnects.
But hopefully now I can articulate the issue.
"Paul Edwards" <mutazilah@gmail.com> writes:inventing
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a575zvmb.fsf@nosuchdomain.example.com...
Hi Keith.
First - thanks a lot of teasing out an unstated assumption.
I am often operating on a set of assumptions. But I don't
list them upfront because I don't actually know what
they are.
Are you sure - given the constraints - that a different interface
isn't appropriate?
I have not said or implied that the POSIX directory interface is the
only appropriate one. It does have the considerable advantage that it
already exists.
My advice is to study and understand existing solutions before
your own. I can't offer meaningful advice on what's appropriate for
your language.
I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?
You've been given at least three; you didn't mention POSIX.
No. That's not a language standard. Only in Common Lisp
and C++ 17, so far mentioned, has the actual language
standard - rightly or wrongly - another outstanding question -
was it right or not? - covered directories.
If you're going to stick with existing C90 compilers, it seems
to me that all you need for your purposes is an add-on library.
Here's the first disconnect.
Yes - I already have an add-on library - that's the folder.c and
folder.h I referenced in the beginning. And unistd.h would be
another.
But neither of these are in C23. Nor were they in C90.
I want a slight variation to BOTH of those standards,
and for the next ISO standard - C30 or whatever -
to include that slight variation.
(I didn't previously state this, because I wasn't aware
of it, again)
In this case, the plan is that my "add-on library", is so
small, and so useful, and hopefully so popular, that it
gets standardized into a theoretical C30, as well as
existing C90 libraries - including but not limited to
PDPCLIB - updated to include this new feature, that,
in hindsight, should have existed even in K&R C.
It's just a library. It may or may not
depend on features of the C90 standard library.
No. It IS C90+.
The implementation of that library might have to be modified for
different target systems.
Of course. The language library standard simply says what is required.
I have: "support both ASCII and EBCDIC escape characters". It's not
something I've ever needed to do, so I have not spent time or effort
deciding how to do it.
The C90 committee was forced to consider that. That's why
'A' to 'Z' are not guaranteed to be consecutive, but '0' to '9' are.
Without either ASCII or EBCDIC mentioned in the C90 standard.
I was specifically talking about the ESCAPE character, which the C90
committee ignored.
Sure. Sorry - loose language. They were forced - begrudingly
from what I think I remember I read - to consider the mainframe
implications. And most couldn't understand why the mainframe
was so complicated, with record formats etc.
Regardless, that's what I'm after - a decision on how to do it.
If you personally don't want to spend the time and effort and/or
make a decision, that's fine - I'm hoping someone in the group
will do that, and perhaps when they propose a solution you will
chime in and say "no, that's not a good idea for xyz reason".
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Disconnect. Not what I prefer. What the theoretical committee decides.
This is intended to be in the official ISO C standard for the next
1 million years.
Actually influencing ISO is a separate exercise.
It probably won't involve coercion.
But coercion wouldn't be required if the C90+ committee comes
up with something reasonable.
You can probably say that I have decided that future versions
of C will only work on character sets that include an ESC
character.
And if I am one day elected president of the USA, at the
same time as Chancellor of Germany, and a few other
places, you may well find 90% of the planet using it (or
at least, having it on their system).
On 5/22/25 19:15, Kaz Kylheku wrote:
...
POSIX is fairly decently supported on Windows by Cygwin.
Ignoring for the moment the different between "fairly decently" and
"fully, Does everyone who uses Windows do so, 100% of the time, through Cygwin? I believe not - so POSIX is not in universal use.
"Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a575zvmb.fsf@nosuchdomain.example.com...
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
But there's no such thing. I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII.
I didn't fully answer this either.
Yes, if you want to be pedantic, the ANSI X3.64 uses the
word ASCII, because they didn't spend any effort considering
that someone might want to do exactly the same thing on an
EBCDIC system - in the future - because there was no such
thing in existence at that time.
But if that committee had spent the effort to consider EBCDIC,
they probably would have reworded the language.
I believe that is unfounded speculation. I'm nearly certain that
the designers of ANSI X3.64 were aware of EBCDIC. We know that
they wrote a standard that depends on ASCII and not on EBCDIC.
I presume this was an entirely deliberate choice, not an unfortunate oversight that they would have reconsidered if they had only taken
a moment to think about it.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?
You've been given at least three; you didn't mention POSIX.
No. That's not a language standard. Only in Common Lisp
and C++ 17, so far mentioned, has the actual language
standard - rightly or wrongly - another outstanding question -
was it right or not? - covered directories.
POSIX is a language extension; it extends the Library clause of ISO C
with a myriad of new header files, functions, types and macros.
We can meaningfully talk about a language called "POSIX C",
distinct from ISO C due to (1) a richer Library clause and (2)
certain requirements in POSIX which override certain implementation
liberties in ISO C. E.g. I (may be wrong but I) think that POSIX doesn't allow int to be 16 bits wide. In other words, POSIX actually has
some language-level requirements in regard to C.
Library and Language are inseparable.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87bjrkxonr.fsf@nosuchdomain.example.com...[...]
If you're going to stick with existing C90 compilers, it seems
to me that all you need for your purposes is an add-on library.
Here's the first disconnect.
Yes - I already have an add-on library - that's the folder.c and
folder.h I referenced in the beginning. And unistd.h would be
another.
But neither of these are in C23. Nor were they in C90.
I want a slight variation to BOTH of those standards,
and for the next ISO standard - C30 or whatever -
to include that slight variation.
[...]
All your talk of defining
a new language based on C90 (whether you call it C90+, or C91,
or whatever), as far as I can tell, is not useful.
I apologize for not having the ability to express myself.
I can only see in hindsight what the issues are.
In this case, the plan is that my "add-on library", is so
small, and so useful, and hopefully so popular, that it
gets standardized into a theoretical C30,
as well as
existing C90 libraries - including but not limited to
PDPCLIB - updated to include this new feature, that,
in hindsight, should have existed even in K&R C.
[...] You don't
want to change the core language (Section 6 of the standard).
You don't need to change the standard library (Section 7); [...]
[...]
If you have created a separate library, advertise it so that it
gets used, and if people are widely happy to have that library
suggest it for inclusion. Then committees might pick it up (or
not).
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
If you have created a separate library, advertise it so that it
gets used, and if people are widely happy to have that library
suggest it for inclusion. Then committees might pick it up (or
not).
Or it might *not* be included in the language standard because
there's no need to do so. If a library is popular, programmers
can just use it whether it's part of the standard library or not.
Plenty of popular libraries are not part of the C standard library --
and they don't need to be.
[...]
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
On 23/05/2025 16:09, Richard Harnden wrote:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
7.26.3 (in 9899:1999) reads: 'Macros that begin with E and a
digit or E and an uppercase letter may be added to the
declarations in the <errno.h> header.'
I can find no reference to such identifiers being explicitly
reserved (did I miss something?), but the above at least hints at
a potential clash between declaring ESCAPE and including the
<errno.h> header.
I think it would be unlikely for the C committe or POSIX/TOG
to add ESCAPE to errno.h.
On 23/05/2025 16:09, Richard Harnden wrote:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
7.26.3 (in 9899:1999) reads: 'Macros that begin with E and a
digit or E and an uppercase letter may be added to the
declarations in the <errno.h> header.'
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an uppercase letter are reserved; they could be defined as macros in <errno.h>.)
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
(Identifiers starting with E followed by either a digit or an uppercase
letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);"
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an uppercase
letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);".
If you had programs which used that as a file scope identifier
where <float.h> was included, or an external name, you had a clash.
It wasn't previously announced that common mathematical words are
reserved, or that identifiers starting with "r" are reserved.
Basically, the concept of reserved spaces is not worth a damn, because
ISO C doesn't actually confine itself to them when naming new entities,
and so no matter what name you choose, you could have a clash in the
future.
There is no way to estimate whether some specific name starting with E
is more or less likely to experience a clash than any other hame;
i.e. we cannot say with certainty that ESCAPE is more likely to
clash than MY_ESCAPE.
Ironically, one way to protect yourself, at least as a solo developer
working on a greenfield projecg with no third party cruft, is to use
short identifiers like extern const char ES. Because no standard or
major API is going to use short names. Everyone uses long-ish names
because it's insane to do otherwise. And that gives YOU the room
to do the insane thing. :)
On 23/05/2025 21:27, Kaz Kylheku wrote:
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
<snip>
(Identifiers starting with E followed by either a digit or an uppercase
letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);"
I am tempted to ask 'who cares?' but I will sit on my hands and
be good.
Kaz Kylheku <643-408-1753@kylheku.com> writes:[ ...]
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an uppercase
letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);".
If you had programs which used that as a file scope identifier
where <float.h> was included, or an external name, you had a clash.
Along with a couple dozen other new floating point functions. All
of which are defined in <math.h>. The only potential conflict in
code written prior to C99 would be applications that include <math.h>
and defined their own 'round' function.
On 2025-05-23, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 23/05/2025 21:27, Kaz Kylheku wrote:
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
<snip>
(Identifiers starting with E followed by either a digit or an uppercase >>>> letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);"
I am tempted to ask 'who cares?' but I will sit on my hands and
be good.
That's essentially what I'm saying.
Who cares about the silly reserved
name spaces that provide nothing you can rely on to thwart future name clashes.
On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:....
On 5/22/25 19:15, Kaz Kylheku wrote:
...
POSIX is fairly decently supported on Windows by Cygwin.
Ignoring for the moment the different between "fairly decently" and
"fully, Does everyone who uses Windows do so, 100% of the time, through
Cygwin? I believe not - so POSIX is not in universal use.
No computer speaks POSIX natively; something must be installed.
On 5/22/25 22:08, Kaz Kylheku wrote:
On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:...
On 5/22/25 19:15, Kaz Kylheku wrote:
...
POSIX is fairly decently supported on Windows by Cygwin.
Ignoring for the moment the different between "fairly decently" and
"fully, Does everyone who uses Windows do so, 100% of the time, through
Cygwin? I believe not - so POSIX is not in universal use.
No computer speaks POSIX natively; something must be installed.
Yes, and POSIX could not be properly referred to as "Universal" unless
it was universally installed - which it isn't. I can't believe that this point is being debated.
I've made multiple attempts to install WINE. Only one of them,
years ago, worked. Yes, with enough work, I could likely have
got it to work.
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an uppercase letter are reserved; they could be defined as macros in <errno.h>.)
On 23/05/2025 22:10, Kaz Kylheku wrote:
On 2025-05-23, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 23/05/2025 21:27, Kaz Kylheku wrote:
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
<snip>
(Identifiers starting with E followed by either a digit or an uppercase >>>>> letter are reserved; they could be defined as macros in <errno.h>.)
But C99 introduced, for instance "double round(double);"
I am tempted to ask 'who cares?' but I will sit on my hands and
be good.
That's essentially what I'm saying.
But we refuse to care for different reasons, it seems.
Who cares about the silly reserved
name spaces that provide nothing you can rely on to thwart future name
clashes.
And who cares about future instability if C90 remains just as stable
as ever it was? (If care there is, it's caring that implementors
continue to include C90 implementations in their repertoire.)
On 23/05/2025 13:43, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
Sure, but it's a different stable.
If it were the same stable, it would be C90.
C99 isn't C90, therefore it isn't the same stable.
If you tell me C99 is a rock, I will not doubt you. But the C90 rock
it most certainly isn't.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 23/05/2025 22:10, Kaz Kylheku wrote:
On 2025-05-23, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 23/05/2025 21:27, Kaz Kylheku wrote:
On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
<snip>
(Identifiers starting with E followed by either a digit or an uppercase >>>>>> letter are reserved; they could be defined as macros in <errno.h>.) >>>>>But C99 introduced, for instance "double round(double);"
I am tempted to ask 'who cares?' but I will sit on my hands and
be good.
That's essentially what I'm saying.
But we refuse to care for different reasons, it seems.
Who cares about the silly reserved
name spaces that provide nothing you can rely on to thwart future name
clashes.
And who cares about future instability if C90 remains just as stable
as ever it was? (If care there is, it's caring that implementors
continue to include C90 implementations in their repertoire.)
There's a catch though to that "future instability" matter. Some
sets of names described in library headers, such as the ESCAPE
example of this thread, are reserved and allowed to change even
in a conforming C90 implementation. A seemingly innocuous line
of code such as
int towel;
could run afoul of this rule, even in a strictly C90 environment.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 23/05/2025 13:43, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
Sure, but it's a different stable.
If it were the same stable, it would be C90.
C99 isn't C90, therefore it isn't the same stable.
If you tell me C99 is a rock, I will not doubt you. But the C90 rock
it most certainly isn't.
Now you're being silly.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:[...]
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an uppercase
letter are reserved; they could be defined as macros in <errno.h>.)
They are reserved only as macros, and only if <errno.h> has
been #include'd.
For this particular use, it's easy to make the definition work,
simply by adding
#undef ESCAPE
before the declaration in the header file, and before the
definition in the source file (assuming of course that if
there are any #include <errno.h> they precede the #undef's).
Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c
And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.
[elaboration]
Any thoughts (besides "get a life!")?
On 23.05.2025 07:20, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
If you have created a separate library, advertise it so that it
gets used, and if people are widely happy to have that library
suggest it for inclusion. Then committees might pick it up (or
not).
Or it might *not* be included in the language standard because
there's no need to do so. If a library is popular, programmers
can just use it whether it's part of the standard library or not.
Plenty of popular libraries are not part of the C standard library --
and they don't need to be.
Yes, sure. - I thought this was what I wrote [with other words];
"might pick it up (or not)".
Honestly, I still don't understand Paul's fixation on the standards
track; i.e. beyond the good feeling one may have when contributing
something [potentially] useful. If it's a sophisticated library and
made available to the public that could be reward enough. (But who
am I to judge. To each his own.)
"Paul Edwards" <mutazilah@gmail.com> writes:
But neither of these are in C23. Nor were they in C90.
I want a slight variation to BOTH of those standards,
and for the next ISO standard - C30 or whatever -
to include that slight variation.
(I didn't previously state this, because I wasn't aware
of it, again)
I don't believe
that you personally will have any influence over any
future C standard. Your goals are too different from the goals of the committee and those of the vast majority of people who care about C.
In this case, the plan is that my "add-on library", is so
small, and so useful, and hopefully so popular, that it
gets standardized into a theoretical C30, as well as
existing C90 libraries - including but not limited to
PDPCLIB - updated to include this new feature, that,
in hindsight, should have existed even in K&R C.
In my opinion that will never happen.
I have no problem with whatever functionality you want to provide in
your PDPCLIB, and I'm willing to discuss some of it in technical terms.
It's just a library. It may or may not
depend on features of the C90 standard library.
No. It IS C90+.
I don't know what you mean by that. If you mean that your PDPCLIB
library IS "C90+", that's fine; both are your invented terms.
But it's an odd choice of terminology.
This is intended to be in the official ISO C standard for the next
1 million years.
That will not happen.
Actually influencing ISO is a separate exercise.
That will not happen either.
It probably won't involve coercion.
But coercion wouldn't be required if the C90+ committee comes
up with something reasonable.
That sounds like a threat. If it is, I suggest you stick it where the
sun don't shine. But as far as I know you have no ability to carry out
your threat, so it's more pathetically amusing that frightening.
And if I am one day elected president of the USA, at the
same time as Chancellor of Germany, and a few other
places, you may well find 90% of the planet using it (or
at least, having it on their system).
See above regarding "where the sun don't shine".
E.g. I can't drive an EBCDIC X3.64 terminal unless C90[...]
provides an ESC define.
That's what C90 is all about after all - making things as[...]
completely portable as possible.
That's convey. Not convince.
It never ever occurred to me that a US president would one
day [SNIP]
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
E.g. I can't drive an EBCDIC X3.64 terminal unless C90[...]
provides an ESC define.
Of course you can.
You can just use '\x27' in your code. It doesn't
have to be part of the language standard. If you have an application
that, for whatever reason, needs to drive both ASCII and EBCDIC
terminals, you can configure it by any means you like to use
'\x1b' or '\x27` (command-line argument, environment variable,
configuration file, reply from the terminal, whatever).
The idea that you can't do that without a constant defined in your
language standard is just silly.
That's what C90 is all about after all - making things as
completely portable as possible.
No, that's not what C90 was ever about. Very few C programs are
completely portable, because they don't need to be.
And if you want to talk
about coercing or bribing members of the C committee or any similar antisocial behaviors
"Paul Edwards" <mutazilah@gmail.com> writes:
[...]
It never ever occurred to me that a US president would one
day [SNIP]
I urge you to stick to the topic of this newsgroup. If you want
to talk about politics, don't do it here. And if you want to talk
about coercing or bribing members of the C committee or any similar >antisocial behaviors, keep it to yourself.
I can't stop you from posting here. I can ignore you.
On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:
Moreover, what is the definition of 'character' in this context?
Something that fgetc() would be able to consume without blocking.
That wouldn't cope with Unicode. Anything that can't cope with Unicode
isn't going to be considered very useful nowadays.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100oicc$3ob15$3@dont-email.me...
On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:
Moreover, what is the definition of 'character' in this context?
Something that fgetc() would be able to consume without blocking.
That wouldn't cope with Unicode. Anything that can't cope with Unicode
isn't going to be considered very useful nowadays.
"people nowadays" don't speak with one voice.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a570jpe6.fsf@nosuchdomain.example.com...
You can just use '\x27' in your code. It doesn't
have to be part of the language standard. If you have an application
that, for whatever reason, needs to drive both ASCII and EBCDIC
terminals, you can configure it by any means you like to use
'\x1b' or '\x27` (command-line argument, environment variable,
configuration file, reply from the terminal, whatever).
Yes, I agree those are standards-conforming alternatives.
But not what I want. For reasons which are difficult for me
to elaborate - "aesthetic", or "self-contained" may or may
not be apt words - I want to include the ESCAPE in the
C code, just like the "hello, world\n" bit.
The C90 committee didn't force me to accept "\n" from a
config file, so that I could have CRLF on MSDOS.
[...]
"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:100p1u4$3um4p$1@dont-email.me...
On 23.05.2025 07:20, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
If you have created a separate library, advertise it so that it
gets used, and if people are widely happy to have that library
suggest it for inclusion. Then committees might pick it up (or
not).
Or it might *not* be included in the language standard because
there's no need to do so. If a library is popular, programmers
can just use it whether it's part of the standard library or not.
Plenty of popular libraries are not part of the C standard library --
and they don't need to be.
Yes, sure. - I thought this was what I wrote [with other words];
"might pick it up (or not)".
Honestly, I still don't understand Paul's fixation on the standards
track; i.e. beyond the good feeling one may have when contributing
something [potentially] useful. If it's a sophisticated library and
made available to the public that could be reward enough. (But who
am I to judge. To each his own.)
(sorry for the delay in replying)
[snip many lines]
On 26.05.2025 00:40, Paul Edwards wrote:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a570jpe6.fsf@nosuchdomain.example.com...
You can just use '\x27' in your code. It doesn't
have to be part of the language standard. If you have an application
that, for whatever reason, needs to drive both ASCII and EBCDIC
terminals, you can configure it by any means you like to use
'\x1b' or '\x27` (command-line argument, environment variable,
configuration file, reply from the terminal, whatever).
Yes, I agree those are standards-conforming alternatives.
But not what I want. For reasons which are difficult for me
to elaborate - "aesthetic", or "self-contained" may or may
not be apt words - I want to include the ESCAPE in the
C code, just like the "hello, world\n" bit.
Doesn't '\e' work for you?
The C90 committee didn't force me to accept "\n" from a
config file, so that I could have CRLF on MSDOS.
If what you want as "escape" is a semantical name also on your
EBCDIC systems then I'd expect a compiler to use the correct
encoding for '\e'.
(If OTOH that "escape" isn't a general semantical term then it
wouldn't be reflected by the compiler; you certainly cannot
expect it be defined through a _configuration_ file.)
On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100oicc$3ob15$3@dont-email.me...
On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:
Moreover, what is the definition of 'character' in this context?
Something that fgetc() would be able to consume without blocking.
That wouldn't cope with Unicode. Anything that can't cope with Unicode
isn't going to be considered very useful nowadays.
"people nowadays" don't speak with one voice.
Nor with one language. Which is why we have Unicode.
The idea that you can't do that without a constant defined in your
language standard is just silly.
It may be silly from your perspective, but for me it is crucial.
On 26.05.2025 00:40, Paul Edwards wrote:....
But not what I want. For reasons which are difficult for me
to elaborate - "aesthetic", or "self-contained" may or may
not be apt words - I want to include the ESCAPE in the
C code, just like the "hello, world\n" bit.
Doesn't '\e' work for you?
char * str = "\e";
puts (str);
printf ("\e\n");
putchar ('\e');
putchar ('\n');
Works for me. - Is that non-standard?
On 5/25/25 21:29, Janis Papanagnou wrote:
On 26.05.2025 00:40, Paul Edwards wrote:...
But not what I want. For reasons which are difficult for me
to elaborate - "aesthetic", or "self-contained" may or may
not be apt words - I want to include the ESCAPE in the
C code, just like the "hello, world\n" bit.
Doesn't '\e' work for you?
char * str = "\e";
puts (str);
printf ("\e\n");
putchar ('\e');
putchar ('\n');
Works for me. - Is that non-standard?
Yes. It's a common extension.
C99 is just as stable as C90, and has been for well over a
decade.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025
10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either that or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade and a half
ago.
On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
2025 10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either that
or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade and a
half ago.
Tim was, I believe, taking into account the time it took for common implementations of C compilers and libraries to have complete and
generally bug-free support for the standards, and for these
implementations to become common. C99 was published in 1999, but it
took quite a while before most people programming in C could happily
use C99 without worrying about the tool support being "experimental"
or not as mature as C90 support.
On Tue, 27 May 2025 16:23:22 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
2025 10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either that
or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade and a
half ago.
Tim was, I believe, taking into account the time it took for common
implementations of C compilers and libraries to have complete and
generally bug-free support for the standards, and for these
implementations to become common. C99 was published in 1999, but it
took quite a while before most people programming in C could happily
use C99 without worrying about the tool support being "experimental"
or not as mature as C90 support.
I believe that your belief is wrong.
It is much more likely that Tim took into account defect reports.
Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
I did not find similar list for C99. However believing Tim I would guess
that the last change in C99 document was made ~15 years ago.
On Tue, 27 May 2025 16:23:22 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
2025 10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either that
or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade and a
half ago.
Tim was, I believe, taking into account the time it took for common
implementations of C compilers and libraries to have complete and
generally bug-free support for the standards, and for these
implementations to become common. C99 was published in 1999, but it
took quite a while before most people programming in C could happily
use C99 without worrying about the tool support being "experimental"
or not as mature as C90 support.
I believe that your belief is wrong.
It is much more likely that Tim took into account defect reports.
Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
I did not find similar list for C99. However believing Tim I would guess that the last change in C99 document was made ~15 years ago.
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025
10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either that or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade and a half
ago.
On 24/05/2025 06:32, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 23/05/2025 13:43, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
Sure, but it's a different stable.
If it were the same stable, it would be C90.
C99 isn't C90, therefore it isn't the same stable.
If you tell me C99 is a rock, I will not doubt you. But the C90
rock it most certainly isn't.
Now you're being silly.
No, sir. If you want to play that game, you can play it with
yourself. I know that you are perfectly capable of polite
conversation, so I see no reason to endure the opposite.
Michael S <already5chosen@yahoo.com> writes:
On Tue, 27 May 2025 16:23:22 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
2025 10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either
that or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade
and a half ago.
Tim was, I believe, taking into account the time it took for common
implementations of C compilers and libraries to have complete and
generally bug-free support for the standards, and for these
implementations to become common. C99 was published in 1999, but
it took quite a while before most people programming in C could
happily use C99 without worrying about the tool support being
"experimental" or not as mature as C90 support.
I believe that your belief is wrong.
It is much more likely that Tim took into account defect reports.
Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
I did not find similar list for C99. However believing Tim I would
guess that the last change in C99 document was made ~15 years ago.
You are partly right. Besides defect reports, there are TCs. And
there is always the possibility of future TCs, future defect
reports, or future changes for any ISO C standard while it is
still current.
To be as stable as C90, a C standard would need to be immune to
the possibility of such future changes.
I take C99 to have reached this level of stability in 2011, when
it was superseded by C11. I take C11 to have reached this level
of stability in 2017, when it was superseded by C17.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 24/05/2025 06:32, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 23/05/2025 13:43, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
Sure, but it's a different stable.
If it were the same stable, it would be C90.
C99 isn't C90, therefore it isn't the same stable.
If you tell me C99 is a rock, I will not doubt you. But the C90
rock it most certainly isn't.
Now you're being silly.
No, sir. If you want to play that game, you can play it with
yourself. I know that you are perfectly capable of polite
conversation, so I see no reason to endure the opposite.
I don't think I'm being impolite.
Got it. Stability occurs when the standards is fenced from changes by presence of the next edition.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100j8t8$2g75r$5@dont-email.me...
On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
Didn't they use software to manage that?
Yes - as the guy (Jeff) said - software written by lunatics/artists.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1010bqn$1l25r$1@dont-email.me...
On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:
"people nowadays" don't speak with one voice.
Nor with one language. Which is why we have Unicode.
Which is one solution to the problem.
Just not a solution I agree with.
I prefer VISCII-like, possibly requiring a 9-bit char, and invalidating
all applications with POSIX assumptions.
And who cares about future instability if C90 remains just as stable as
ever it was?
On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote:
Got it. Stability occurs when the standards is fenced from changes by
presence of the next edition.
Each technical corrigendum effectively yields a new edition.
The previous standard without that corrigendum is forever stable,
as any immutable object.
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
And who cares about future instability if C90 remains just as stable as
ever it was?
Even with the problems with const?
char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that.
On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
And who cares about future instability if C90 remains just as stable
as ever it was?
Even with the problems with const?
char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that.
Is C90 perfect? No, of course not.
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:....
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the Amish, whose concept of the ideal level of technology is the one that was
in effect at the time they were founded? And who have remained stuck at
that point in time ever since?
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
And who cares about future instability if C90 remains just as stable
as ever it was?
Even with the problems with const?
char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that.
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection?
Like the
Amish, whose concept of the ideal level of technology is the one that was
in effect at the time they were founded? And who have remained stuck at
that point in time ever since?
On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:...
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the
Amish, whose concept of the ideal level of technology is the one that was
in effect at the time they were founded? And who have remained stuck at
that point in time ever since?
That's not actually the case. The Amish have slowly adopted more
advanced levels of technology as the people around them have adopted
farm more advanced ones. The important thing, from their point of view,
it not a particular level of technology, but to maintain a clear
distinction between them and the non-Amish.
Which means that they are more adaptable than Richard is.
On Wed, 21 May 2025 19:23:45 +1000, Paul Edwards wrote:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:100j8t8$2g75r$5@dont-email.me...
On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
Didn't they use software to manage that?
Yes - as the guy (Jeff) said - software written by lunatics/artists.
Was RCU invented by the hardware guys, or the software guys?
On 29/05/2025 11:11, James Kuyper wrote:
On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:...
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the
Amish, whose concept of the ideal level of technology is the one that was >>> in effect at the time they were founded? And who have remained stuck at
that point in time ever since?
That's not actually the case. The Amish have slowly adopted more
advanced levels of technology as the people around them have adopted
farm more advanced ones. The important thing, from their point of view,
it not a particular level of technology, but to maintain a clear
distinction between them and the non-Amish.
Which means that they are more adaptable than Richard is.
They use a lot of C++, do they?
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 11:11, James Kuyper wrote:
On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:...
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the >>>> Amish, whose concept of the ideal level of technology is the one that was >>>> in effect at the time they were founded? And who have remained stuck at >>>> that point in time ever since?
That's not actually the case. The Amish have slowly adopted more
advanced levels of technology as the people around them have adopted
farm more advanced ones. The important thing, from their point of view,
it not a particular level of technology, but to maintain a clear
distinction between them and the non-Amish.
Which means that they are more adaptable than Richard is.
They use a lot of C++, do they?
They do love power tools.
You can have new tools without breaking the old ones. We didn't
have to change BCPL to get B, or B to get C, or C to get D or C++.
This really is a very simple point, but perhaps a simple analogy
will help to clarify it. You don't throw out your 3/4" just
because you've bought a 19mm. There is room for both in the
toolbox, and why write 3/4" on your new spanner? It /isn't/ a
3/4" spanner even though it's very like it, so why pretend otherwise?
If you want to take down a tree in a hurry, a chainsaw is just
the job, but more delicate work requires more delicate tools.
On 5/29/25 08:38, Richard Heathfield wrote:
...
You can have new tools without breaking the old ones. We didn't
have to change BCPL to get B, or B to get C, or C to get D or C++.
This really is a very simple point, but perhaps a simple analogy
will help to clarify it. You don't throw out your 3/4" just
because you've bought a 19mm. There is room for both in the
toolbox, and why write 3/4" on your new spanner? It /isn't/ a
3/4" spanner even though it's very like it, so why pretend otherwise?
That's why C99 is called C99, to distinguish it from C90 (and similarly
for later versions).
On 2025-05-29, Richard Heathfield <rjh@cpax.org.uk> wrote:
If you want to take down a tree in a hurry, a chainsaw is just
the job, but more delicate work requires more delicate tools.
(I'm now searching YouTube for anyone in Asia who might be
carving jade amulets with a chainsaw ...)
On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
And who cares about future instability if C90 remains just as stable as
ever it was?
Even with the problems with const?
char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that.
Is C90 perfect? No, of course not. "C is quirky, flawed, and an enormous success."
Is there value in having a powerful, widely-available language that,
when you turn your back for a moment, stays *exactly* where you left it? Hell, yes.
On 29/05/2025 10:39, Richard Heathfield wrote:
On 29/05/2025 08:27, Lawrence D'Oliveiro wrote: =20=20
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:=20
=20
And who cares about future instability if C90 remains just as
stable as ever it was? =20
Even with the problems with const?
=A0=A0=A0=A0 char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that. =20
Is C90 perfect? No, of course not. "C is quirky, flawed, and an
enormous success."
=20
Is there value in having a powerful, widely-available language
that, when you turn your back for a moment, stays *exactly* where
you left it? Hell, yes.
=20
That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
=20
I agree with all your are arguments on this, except for one - I can't=20 understand why you think C90 is different from later C standards in
this regard.
=20
On 29/05/2025 10:39, Richard Heathfield wrote:
On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
And who cares about future instability if C90 remains just as
stable as
ever it was?
Even with the problems with const?
char *strstr(const char *haystack, const char *needle);
Dennis Ritchie pointed out the trouble with that.
Is C90 perfect? No, of course not. "C is quirky, flawed, and an
enormous success."
Is there value in having a powerful, widely-available language
that, when you turn your back for a moment, stays *exactly*
where you left it? Hell, yes.
That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
except for one - I
can't understand why you think C90 is different from later C
standards in this regard.
On 29/05/2025 20:24, David Brown wrote:[...]
That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
So far so good. :-)
except for one - I can't understand why you think C90 is different
from later C standards in this regard.
I realise that my reply is going to sound glib, but I can't help that.
I *don't* think C90 is different. I think C90 is exactly the
same. It's the later standards that are different. Different from C90.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 20:24, David Brown wrote:[...]
That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
So far so good. :-)
except for one - I can't understand why you think C90 is different
from later C standards in this regard.
I realise that my reply is going to sound glib, but I can't help that.
I *don't* think C90 is different. I think C90 is exactly the
same. It's the later standards that are different. Different from C90.
I'd like to understand the point you're trying to make.
Being different is a transitive relationship. C90 is different
"from later C standards". You say that C90 is "exactly the same"
-- as what? As itself?
C99 is also exactly the same as itself.
If the difference is that you personally like C90 and dislike C99
and later editions, that's fine. De gustibus non est disputandem
(never argue with a guy named Gus).
On 29/05/2025 21:45, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 20:24, David Brown wrote:[...]
That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
So far so good. :-)
except for one - I can't understand why you think C90 is different
from later C standards in this regard.
I realise that my reply is going to sound glib, but I can't help that.
I *don't* think C90 is different. I think C90 is exactly the
same. It's the later standards that are different. Different from C90.
I'd like to understand the point you're trying to make.
I'll do what I can to help out; I'm really not trying to be obscure.
Being different is a transitive relationship. C90 is different
"from later C standards". You say that C90 is "exactly the same"
-- as what? As itself?
Yes. And nothing else has that quality of being C90.
C99 is also exactly the same as itself.
Yes, but it's different from C99.
If the difference is that you personally like C90 and dislike C99
and later editions, that's fine. De gustibus non est disputandem
(never argue with a guy named Gus).
Look, Gus, if that's what you want to call yourself...well, okay,
I can't in all honesty deny that de gustibus is part of it, but
it's more to do with bit rot.
Software houses need C90 for the same reason the government needs
IBM 1311s (unless they've finished migrating off them now),
cassette players, WW2 crypto keys, and the boot passwords for
those early 1990s PCs lurking in the cellar.
I shudder to think how much C90 code is out there, but it has to
be /at least/ in the region of 10^9 LOC, much of it in the
military arena, medical applications, and particularly the world
of comms. Letting C90 compilers fall off the radar (e.g. by
society forgetting how to program in it) really could be a
stupendously bad idea, for all the reasons that people overlook
when they shrug and say `I expect it'll all turn out fine'.
On 29/05/2025 11:11, James Kuyper wrote:
On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:...
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the
Amish, whose concept of the ideal level of technology is the one that
was
in effect at the time they were founded? And who have remained stuck at
that point in time ever since?
That's not actually the case. The Amish have slowly adopted more
advanced levels of technology as the people around them have adopted
farm more advanced ones. The important thing, from their point of view,
it not a particular level of technology, but to maintain a clear
distinction between them and the non-Amish.
Which means that they are more adaptable than Richard is.
They use a lot of C++, do they?
On 29/05/2025 16:08, Scott Lurndal wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 11:11, James Kuyper wrote:
On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:...
Is C90 perfect? No, of course not.
Is there some value in that particular state of imperfection? Like the >>>>> Amish, whose concept of the ideal level of technology is the one
that was
in effect at the time they were founded? And who have remained
stuck at
that point in time ever since?
That's not actually the case. The Amish have slowly adopted more
advanced levels of technology as the people around them have adopted
farm more advanced ones. The important thing, from their point of view, >>>> it not a particular level of technology, but to maintain a clear
distinction between them and the non-Amish.
Which means that they are more adaptable than Richard is.
They use a lot of C++, do they?
They do love power tools.
:-)
If you want to take down a tree in a hurry, a chainsaw is just the job,
but more delicate work requires more delicate tools.
More to the point, if you have a million lines of legacy code all
written in C90, it's a bloody good idea to keep a C90 compiler around because maintenance.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 21:45, Keith Thompson wrote:
C99 is also exactly the same as itself.
Yes, but it's different from C99.
I shudder to think how much C90 code is out there, but it has to
be /at least/ in the region of 10^9 LOC, much of it in the
military arena, medical applications, and particularly the world
of comms. Letting C90 compilers fall off the radar (e.g. by
society forgetting how to program in it) really could be a
stupendously bad idea, for all the reasons that people overlook
when they shrug and say `I expect it'll all turn out fine'.
And all the existing C compilers in the entire planet support
the C90 dialect[*], if so instructed.
Where is the problem?
[*] Well, except perhap Bart's and various hobby compilers.
On 29/05/2025 21:45, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 20:24, David Brown wrote:[...]
I'd like to understand the point you're trying to make.That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
So far so good. :-)
except for one - I can't understand why you think C90 is different
from later C standards in this regard.
I realise that my reply is going to sound glib, but I can't help that.
I *don't* think C90 is different. I think C90 is exactly the
same. It's the later standards that are different. Different from C90.
I'll do what I can to help out; I'm really not trying to be obscure.
Being different is a transitive relationship. C90 is different
"from later C standards". You say that C90 is "exactly the same"
-- as what? As itself?
Yes. And nothing else has that quality of being C90.
C99 is also exactly the same as itself.
Yes, but it's different from C99.
If the difference is that you personally like C90 and dislike C99
and later editions, that's fine. De gustibus non est disputandem
(never argue with a guy named Gus).
Look, Gus, if that's what you want to call yourself...well, okay, I
can't in all honesty deny that de gustibus is part of it, but it's
more to do with bit rot.
Software houses need C90 for the same reason the government needs IBM
1311s (unless they've finished migrating off them now), cassette
players, WW2 crypto keys, and the boot passwords for those early 1990s
PCs lurking in the cellar.
I shudder to think how much C90 code is out there, but it has to be
/at least/ in the region of 10^9 LOC, much of it in the military
arena, medical applications, and particularly the world of
comms. Letting C90 compilers fall off the radar (e.g. by society
forgetting how to program in it) really could be a stupendously bad
idea, for all the reasons that people overlook when they shrug and say
`I expect it'll all turn out fine'.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 21:45, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 20:24, David Brown wrote:[...]
I'd like to understand the point you're trying to make.That's one of the reasons I like C99 and C11, and look forward to
C23. Once implemented, they don't change either.
I agree with all your are arguments on this,
So far so good. :-)
except for one - I can't understand why you think C90 is different
from later C standards in this regard.
I realise that my reply is going to sound glib, but I can't help that. >>>>
I *don't* think C90 is different. I think C90 is exactly the
same. It's the later standards that are different. Different from C90.
I'll do what I can to help out; I'm really not trying to be obscure.
Being different is a transitive relationship. C90 is different
"from later C standards". You say that C90 is "exactly the same"
-- as what? As itself?
Yes. And nothing else has that quality of being C90.
C99 is also exactly the same as itself.
Yes, but it's different from C99.
I hope that was a typo. If you really meant that C99 is different from
C99, I suggest that requires a bit more explanation.
Obviously C90, C99, and C11 are all different from each other.
You seem to be suggesting that C90 is special in some way that C99
and C11 are not.
If that's an accurate summary of your opinion,
can you explain it?
And if it isn't, just what are we talking about?
Software houses need C90 for the same reason the government needs
IBM 1311s (unless they've finished migrating off them now),
cassette players, WW2 crypto keys, and the boot passwords for
those early 1990s PCs lurking in the cellar.
I shudder to think how much C90 code is out there, but it has to
be /at least/ in the region of 10^9 LOC, much of it in the
military arena, medical applications, and particularly the world
of comms. Letting C90 compilers fall off the radar (e.g. by
society forgetting how to program in it) really could be a
stupendously bad idea, for all the reasons that people overlook
when they shrug and say `I expect it'll all turn out fine'.
This really is a very simple point, but perhaps a simple analogy
will help to clarify it. You don't throw out your 3/4" just
because you've bought a 19mm. There is room for both in the
toolbox, and why write 3/4" on your new spanner? It /isn't/ a
3/4" spanner even though it's very like it, so why pretend otherwise?
Concerning new code it makes sense to avoid constructs that
are made illegal in later standard, that is write to the
latter of later standard even if you use only constructs
available in C90.
I shudder to think how much C90 code is out there, but it has to be /at least/ in the region of 10^9 LOC, much of it in the military arena,
medical applications, and particularly the world of comms.
Richard Heathfield <rjh@cpax.org.uk> writes:
I shudder to think how much C90 code is out there, but it has to
be /at least/ in the region of 10^9 LOC, much of it in the
military arena, medical applications, and particularly the world
of comms. Letting C90 compilers fall off the radar (e.g. by
society forgetting how to program in it) really could be a
stupendously bad idea, for all the reasons that people overlook
when they shrug and say `I expect it'll all turn out fine'.
And all the existing C compilers in the entire planet support
the C90 dialect[*], if so instructed. Where is the problem?
[*] Well, except perhap Bart's and various hobby compilers.
On Wed, 21 May 2025 19:23:45 +1000, Paul Edwards wrote:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100j8t8$2g75r$5@dont-email.me...
On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
Didn't they use software to manage that?
Yes - as the guy (Jeff) said - software written by lunatics/artists.
Was RCU invented by the hardware guys, or the software guys?
What about journalling? Two-phase commit? Diffie-Hellman? RSA? Kerberos? kexec?
On Mon, 26 May 2025 11:50:30 +1000, Paul Edwards wrote:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1010bqn$1l25r$1@dont-email.me...
On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:
"people nowadays" don't speak with one voice.
Nor with one language. Which is why we have Unicode.
Which is one solution to the problem.
Just not a solution I agree with.
It's the one most of the nations of the world agree with.
I prefer VISCII-like, possibly requiring a 9-bit char, and invalidating
all applications with POSIX assumptions.
Are you going to set up your own UN as well? You could call it the "World Series of Nations" ...
This really is a very simple point, but perhaps a simple analogy will
help to clarify it. You don't throw out your 3/4" just because you've
bought a 19mm. There is room for both in the toolbox, and why write 3/4"
on your new spanner? It /isn't/ a 3/4" spanner even though it's very
like it, so why pretend otherwise?
On 29/05/2025 14:38, Richard Heathfield wrote:
This really is a very simple point, but perhaps a simple
analogy will help to clarify it. You don't throw out your 3/4"
just because you've bought a 19mm. There is room for both in
the toolbox, and why write 3/4" on your new spanner? It /isn't/
a 3/4" spanner even though it's very like it, so why pretend
otherwise?
Your analogy does not cover C99 vs C90.
On 30/05/2025 10:20, David Brown wrote:
On 29/05/2025 14:38, Richard Heathfield wrote:
This really is a very simple point, but perhaps a simple analogy will
help to clarify it. You don't throw out your 3/4" just because you've
bought a 19mm. There is room for both in the toolbox, and why write
3/4" on your new spanner? It /isn't/ a 3/4" spanner even though it's
very like it, so why pretend otherwise?
Your analogy does not cover C99 vs C90.
It does if we can construct a program that is legal C90 but not legal
C99, which is easy enough, or (slightly harder but still not that hard)
a program that is legal in both dialects but which gives different
output under C99 than it does for C90.
$ cat c9099.c;gcc -W -Wall -ansi -pedantic -o c90 c9099.c;gcc -o c99 c9099.c;./c90;./c99
#include <stdio.h>
int main(void)
{
int a = 42;
int b = a //* comment */ 6;
;
printf("Soln = %d\n", b);
return 0;
}
Soln = 7
Soln = 42
Obviously it's a contrived example, but then examples pointing out the consequences of language differences invariably are.
On 30/05/2025 12:54, Richard Heathfield wrote:
Obviously it's a contrived example, but then examples pointing
out the consequences of language differences invariably are.
The analogy there is like complaining you can't use the back end
of your new spanner to hammer in nails, because it now has a
box/ring at the end.
On 29/05/2025 22:50, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 21:45, Keith Thompson wrote:
C99 is also exactly the same as itself.
Yes, but it's different from C99.
I hope that was a typo. If you really meant that C99 is different from
C99, I suggest that requires a bit more explanation.
Typo, of course. (9 is next to 0.) Alas, my typo-free days are over.
On 30/05/2025 15:02, David Brown wrote:
On 30/05/2025 12:54, Richard Heathfield wrote:
<snip>
Obviously it's a contrived example, but then examples pointing out
the consequences of language differences invariably are.
The analogy there is like complaining you can't use the back end of
your new spanner to hammer in nails, because it now has a box/ring at
the end.
Your argument now appears to be that people wouldn't need C90 if only
they'd written their C90 in such a way that C99 would have met their needs.
This is undoubtedly the case.
On 30/05/2025 01:05, Richard Heathfield wrote:
Typo, of course. (9 is next to 0.) Alas, my typo-free days are over.
You are, I believe, older than me. At what age can I expect my typo-
free days to start?
On 30/05/2025 01:05, Richard Heathfield wrote:
On 29/05/2025 22:50, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/05/2025 21:45, Keith Thompson wrote:
C99 is also exactly the same as itself.
Yes, but it's different from C99.
I hope that was a typo. If you really meant that C99 is
different from
C99, I suggest that requires a bit more explanation.
Typo, of course. (9 is next to 0.) Alas, my typo-free days are
over.
You are, I believe, older than me. At what age can I expect my
typo-free days to start?
:-)
I can't see how you get that from what I wrote.
I'm not sure we are getting anywhere with this thread...
On 30/05/2025 16:37, David Brown wrote:
On 30/05/2025 01:05, Richard Heathfield wrote:
Typo, of course. (9 is next to 0.) Alas, my typo-free days are
over.
You are, I believe, older than me. At what age can I expect my
typo- free days to start?
Typo free days to /end/
On 29/05/2025 14:38, Richard Heathfield wrote:
This really is a very simple point, but perhaps a simple analogy will
help to clarify it. You don't throw out your 3/4" just because you've
bought a 19mm. There is room for both in the toolbox, and why write 3/4"
on your new spanner? It /isn't/ a 3/4" spanner even though it's very
like it, so why pretend otherwise?
Your analogy does not cover C99 vs C90.
You have a good 3/4" spanner. You don't throw it out just because you
also get an adjustable spanner - sometimes the 3/4" spanner is more practical, or perhaps a bit stronger. That's keeping C when you also
have C++ available.
(The competition for first place being IBM's C compiler for z/OS)
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
And in essence, when you read from a directory, the only thing you get
is the filename.
You want at least the type of entry as well, surely.
<https://manpages.debian.org/readdir(3)>
Am 20.05.2025 um 09:27 schrieb Lawrence D'Oliveiro:
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
And in essence, when you read from a directory, the only thing you get
is the filename.
You want at least the type of entry as well, surely.
<https://manpages.debian.org/readdir(3)>
Easier to handle: https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html
On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote:
Easier to handle:
https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html
If you’re wanting language-specific facilities, then see if you can beat this <https://docs.python.org/3/library/os.html#os.walk>.
For one thing, notice how it gives you the choice of whether to follow symlinks or not?
Am 31.05.2025 um 23:42 schrieb Lawrence D'Oliveiro:
On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote:
Easier to handle:
https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html
If you’re wanting language-specific facilities, then see if you can
beat this <https://docs.python.org/3/library/os.html#os.walk>. For
one thing, notice how it gives you the choice of whether to follow
symlinks or not?
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\",
directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security holes
on operations with symlinks.
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security holes
on operations with symlinks.
Which security holes ?
Bonita Montero <Bonita.Montero@gmail.com> writes:....
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
You need the dirfd functions to avoid certain potential security holes
on operations with symlinks.
Which security holes ?
The fchownat() function shall be equivalent to the chown() and lchown() functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is O_SEARCH, the function shall not perform the check.
Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.
On 6/2/25 11:24, Scott Lurndal wrote:
Bonita Montero <Bonita.Montero@gmail.com> writes:...
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks.
Which security holes ?
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.
That describes what the functions do, it doesn't explain the potential >security holes that they avoid. The hole might seem obvious to you, but
it's certainly not obvious to me - probably because writing code to
traverse directories is something I've almost never had to do.
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security
holes on operations with symlinks.
Which security holes ?
From the posix standard:
"The purpose of the fstatat() function is to obtain the status
of files in directories other than the current working directory
without exposure to race conditions. Any part of the path of a
file could be changed in parallel to a call to stat(), resulting
in unspecified behavior. By opening a file descriptor for the target
directory and using the fstatat() function it can be guaranteed that
the file for which status is returned is located relative to the desired directory."
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security holes
on operations with symlinks.
Which security holes ?
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
Am 02.06.2025 um 17:24 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks.
Which security holes ?
The fchownat() function shall be equivalent to the chown() and lchown() >> functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory >> associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions >> of the directory underlying the file descriptor. If the access mode is >> O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or >recursive_directory_iterator ?
On Fri, 30 May 2025 18:18:43 +1000, Paul Edwards wrote:
(The competition for first place being IBM's C compiler for z/OS)
Come on, who writes C code for z/OS?
Mainframes are supposed to be all
about COBOL code, aren't they? Or so we keep being told.
And what might IBM's COBOL compiler (and associated system utilities) be written in? Why, its long-time systems-programming language of choice,
PL/I.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
"Paul Edwards" <mutazilah@gmail.com> writes:
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
Except for various Unisys systems, which are still being sold.
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is no different from working with any other character encoding - ASCII, UTF-8, different 8-bit code pages, or whatever. If the data is just passing through your code, read it in and pass it out without a care. If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is no different from working with any other character encoding - ASCII, UTF-8, different 8-bit code pages, or whatever. If the data is just passing
through your code, read it in and pass it out without a care. If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
I think that in this case you would ideally want the EBCDIC-enabled
compiler to have extensions for working with both character sets.
For isntance E"foo" would specify a string object that is
encoded in EBCDIC in the execution environment, whereas
"foo" is ASCII.
You could develop a textual preprocesor which implements
this transformation: tokenizes the C well enough to recognize
string literals preceded by E, and translates them to
string literals without E, whose content is EBCDIC bytes.
It wouldn't have to be absoultely perfect; only to work
correctly on your small amount of private code.
On 04.06.25 17:30, David Brown wrote:
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is no
different from working with any other character encoding - ASCII, UTF-8,
different 8-bit code pages, or whatever. If the data is just passing
through your code, read it in and pass it out without a care. If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.
This might be true if there were no special characters, but eg the slash
is 2FH in ASCII but 61H in EBCDIC, so Linux may have a problem there.
The backslash is 0E0H in EBCDIC (at least in Australia, Brasil, Canada,
and various other countries), 0ECH in Germany and Austria while it is
5CH in ASCII. So DOS and Windows have a problem here.
So, YES, the operating system has to be aware of the code set used.
"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604121550.286@kylheku.com...
On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
I think that in this case you would ideally want the EBCDIC-enabled
compiler to have extensions for working with both character sets.
For isntance E"foo" would specify a string object that is
encoded in EBCDIC in the execution environment, whereas
"foo" is ASCII.
You could develop a textual preprocesor which implements
this transformation: tokenizes the C well enough to recognize
string literals preceded by E, and translates them to
string literals without E, whose content is EBCDIC bytes.
It wouldn't have to be absoultely perfect; only to work
correctly on your small amount of private code.
Even assuming the above was technically possible - what's
wrong with just having a pseudo-bios and OS so that
everything is totally clean?
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:101dac8$mkpm$3@dont-email.me...
Mainframes are supposed to be all about COBOL code, aren't they? Or so
we keep being told.
That would make the IBM COBOL compiler the most important compiler in
the world, not the most important C compiler in the world.
On Wed, 4 Jun 2025 19:23:42 +1000, Paul Edwards wrote:
Most of the remaining COBOL code nowadays is compiled with ... wait for
it ... GNU COBOL. And the GNU compiler suite is, I believe, written in C++ >at its core these days (used to be C).
On 04.06.25 17:30, David Brown wrote:
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is
no different from working with any other character encoding - ASCII,
UTF-8, different 8-bit code pages, or whatever. If the data is just
passing through your code, read it in and pass it out without a care.
If you need to convert it or mix it with some other encoding, work
with a common encoding - UTF-8 is normally the right choice.
This might be true if there were no special characters, but eg the slash
is 2FH in ASCII but 61H in EBCDIC, so Linux may have a problem there.
The backslash is 0E0H in EBCDIC (at least in Australia, Brasil, Canada,
and various other countries), 0ECH in Germany and Austria while it is
5CH in ASCII. So DOS and Windows have a problem here.
So, YES, the operating system has to be aware of the code set used.
"David Brown" <david.brown@hesbynett.no> wrote in message news:101poqm$t350$1@dont-email.me...
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is no
different from working with any other character encoding - ASCII, UTF-8,
different 8-bit code pages, or whatever. If the data is just passing
through your code, read it in and pass it out without a care. If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
And how do you expect Windows 10/11 to find "test1.dat" -
all EBCDIC on its current ASCII filesystem?
On 04/06/2025 20:58, Paul Edwards wrote:UTF-8,
"David Brown" <david.brown@hesbynett.no> wrote in message news:101poqm$t350$1@dont-email.me...
On 04/06/2025 11:23, Paul Edwards wrote:
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding. It is no
different from working with any other character encoding - ASCII,
different 8-bit code pages, or whatever. If the data is just passing
through your code, read it in and pass it out without a care. If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
In /your/ code!
/You/ are responsible for writing the code that handles the data, and
which gets the encoding right. If you want to handle data in an odd encoding, write code to handle it. That's what everyone else does when dealing with data in different encodings.
And how do you expect Windows 10/11 to find "test1.dat" -
all EBCDIC on its current ASCII filesystem?
Convert the character encoding for the string.
People do this all the time. They write code that uses UTF-8, and have
to deal with Windows crappy UCS2 / partial UTF-16 / wchar_t mess. Or
they have code that supports different code pages because they started
it in the pre-Unicode days and don't live in a little American-only
ASCII bubble.
C does not make this stuff particularly convenient, though it has
improved a little since C90 - other languages have vastly superior
string and encoding handling. But that does not mean you can't do it,
or should not do it.
Maybe if you actually wanted to contribute something useful to the C
world - something that other people might find useful - you could put
your efforts into writing a library that has functions for converting encodings back and forth with UTF-8 as the base. Include support for
the dozen different EDBDIC versions.
Or do you really think that if someone sent me a file to read that was
in EDBDIC encoding, I'd be happy to install an EDBDIC "pseudo-bios" and EDBDIC version of Windows so that I could read it?
On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604121550.286@kylheku.com...
On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
If I have existing C code that does:
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
printf("It matches!\n");
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?
I think that in this case you would ideally want the EBCDIC-enabled
compiler to have extensions for working with both character sets.
For isntance E"foo" would specify a string object that is
encoded in EBCDIC in the execution environment, whereas
"foo" is ASCII.
You could develop a textual preprocesor which implements
this transformation: tokenizes the C well enough to recognize
string literals preceded by E, and translates them to
string literals without E, whose content is EBCDIC bytes.
It wouldn't have to be absoultely perfect; only to work
correctly on your small amount of private code.
Even assuming the above was technically possible - what's
wrong with just having a pseudo-bios and OS so that
everything is totally clean?
Nothing; it's just that the OS doesn't match the requirement given in
some above quoted text I was responding to that this is on "modern
Windows 10/11 system" which requires the program output to be
"translated to ASCII".
Maybe if you actually wanted to contribute something useful to the C
world - something that other people might find useful
Maybe if you actually wanted to contribute something useful to the C
world - something that other people might find useful - you could put
your efforts into writing a library that has functions for converting encodings back and forth with UTF-8 as the base. Include support for
the dozen different EDBDIC versions.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 02.06.2025 um 17:24 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security holes >>>>> on operations with symlinks.
Which security holes ?
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In >>> this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working >>> directory. If the access mode of the open file description associated >>> with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions >>> of the directory underlying the file descriptor. If the access mode is >>> O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In >>>> this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working >>>> directory. If the access mode of the open file description associated >>>> with the file descriptor is not O_SEARCH, the function shall check >>>> whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check >>>>> whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Personally, I'd use nftw to iterate over a path.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check >>>>>> whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Personally, I'd use nftw to iterate over a path.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
That would be much nicer with a lambda which can take the context
of the calling function.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Personally, I'd use nftw to iterate over a path.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
That would be much nicer with a lambda which can take the context
of the calling function.
That's a matter of opinion.
In any case, nftw is a C function and C doesn't support lamda functions.
Am 06.06.2025 um 19:24 schrieb Scott Lurndal:n shall be equivalent to the chown() and lchown()
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The fchownat() functio=
e case where path specifies a relative path. In=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functions except in th=
be changed is determined relative to the directory=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this case the file to =
le descriptor fd instead of the current working=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated with the fi=
ss mode of the open file description associated=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directory. If the acce=
or is not O_SEARCH, the function shall check=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the file descript=
ches are permitted using the current permissions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether directory sear=
lying the file descriptor. If the access mode is=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the directory under=
shall not perform the check.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O_SEARCH, the function=
l=20=20=20=20
And why is this relevant for directory_iterator or recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Personally, I'd use nftw to iterate over a path.
=20
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.htm=
=20=20=20
That would be much nicer with a lambda which can take the context
of the calling function.
=20
That's a matter of opinion.
It results in much less code.=C2=A0
Just like a lambda passed..
to std::sort() which takes context of the calling function.
=20
In any case, nftw is a C function and C doesn't support lamda functions=
=20
Lambdas without capture can be converted to C function-pointers.
On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote:
Got it. Stability occurs when the standards is fenced from
changes by presence of the next edition.
Each technical corrigendum effectively yields a new edition.
The previous standard without that corrigendum is forever stable,
as any immutable object.
On Tue, 27 May 2025 16:16:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Tue, 27 May 2025 16:23:22 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
2025 10:43 pm. It's a cool scene! Dig it.
C99 is just as stable as C90, and has been for well over a
decade.
Methinks Tim is having trouble with his arithmetic. Either
that or he doesn't know what year it is now. :)
C99 was ratified in 1999, over two and a half decades ago.
C11 is just as stable as C90, and has been for just slightly
less than a decade.
And C11 was ratified in 2011, no? That was almost a decade
and a half ago.
Tim was, I believe, taking into account the time it took for common
implementations of C compilers and libraries to have complete and
generally bug-free support for the standards, and for these
implementations to become common. C99 was published in 1999, but
it took quite a while before most people programming in C could
happily use C99 without worrying about the tool support being
"experimental" or not as mature as C90 support.
I believe that your belief is wrong.
It is much more likely that Tim took into account defect reports.
Here is the list of C11 defect reports with the last dated 2016:
https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
I did not find similar list for C99. However believing Tim I would
guess that the last change in C99 document was made ~15 years ago.
You are partly right. Besides defect reports, there are TCs. And
there is always the possibility of future TCs, future defect
reports, or future changes for any ISO C standard while it is
still current.
To be as stable as C90, a C standard would need to be immune to
the possibility of such future changes.
I take C99 to have reached this level of stability in 2011, when
it was superseded by C11. I take C11 to have reached this level
of stability in 2017, when it was superseded by C17.
Got it. Stability occurs when the standards is fenced from
changes by presence of the next edition.
Stability by obsolescence.
On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
The fchownat() function shall be equivalent to the chown() and lchown()
functions except in the case where path specifies a relative path. In
this case the file to be changed is determined relative to the directory
associated with the file descriptor fd instead of the current working
directory. If the access mode of the open file description associated
with the file descriptor is not O_SEARCH, the function shall check
whether directory searches are permitted using the current permissions
of the directory underlying the file descriptor. If the access mode is
O_SEARCH, the function shall not perform the check.
And why is this relevant for directory_iterator or
recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir().
Personally, I'd use nftw to iterate over a path.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
That would be much nicer with a lambda which can take the context
of the calling function.
That's a matter of opinion.
It results in much less code.
That is illusion, particularly in this case (about directory).
Most serious programs will 'invent' their own functions, even their own 'sugar syntax'...
'sugar syntax'... result would be better than 'directory_iterator'.
In general, no need for such things as 'directory_iterator' in C-library.
Just like a lambda passed
to std::sort() which takes context of the calling function.
In any case, nftw is a C function and C doesn't support lamda functions.
Lambdas without capture can be converted to C function-pointers.
Am 06.06.2025 um 22:04 schrieb wij:() function shall be equivalent to the chown() and lchown()
On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 20:25 schrieb Scott Lurndal:=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The fchownat=
cept in the case where path specifies a relative path. In=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functions ex=
e file to be changed is determined relative to the directory=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this case th=
ith the file descriptor fd instead of the current working=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated w=
f the access mode of the open file description associated=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directory. I=
e descriptor is not O_SEARCH, the function shall check=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the fil=
ctory searches are permitted using the current permissions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether dire=
tory underlying the file descriptor. If the access mode is=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the direc=
e function shall not perform the check.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O_SEARCH, th=
).=20=20=20
And why is this relevant for directory_iterator or recursive_directory_iterator ?
Why are you asking this question on comp.lang.c?
Because you can have it easier than with opendir() / readdir(=
..html=20
Personally, I'd use nftw to iterate over a path.
=20
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw=
=20=20=20=20=20
That would be much nicer with a lambda which can take the context
of the calling function.
=20
That's a matter of opinion.
It results in much less code.
That is illusion, particularly in this case (about directory).
I've shown the code. In C++17 iterating through a single directory and printing it is two lines of code.
Most serious programs will 'invent' their own functions, even their own 'sugar syntax'...=20
Not to iterate through a directory in C++.
=20
'sugar syntax'... result would be better than 'directory_iterator'.=20
Why ?
y.In general, no need for such things as 'directory_iterator' in C-librar=
=20
=20
In C you're forced to write ten times the code if you include error
handling.
ions.Just like a lambda passed
to std::sort() which takes context of the calling function.
=20
In any case, nftw is a C function and C doesn't support lamda funct=
=20=20
Lambdas without capture can be converted to C function-pointers.
C++ is no better, probably worse. Firstly, the term 'exception' (and
'vector' probably) is disabled in human mind to think about exception.
C++ had been trying to HIDE error (exception) from its beginning, very wrong and very unsuccessful.
Am 07.06.2025 um 13:58 schrieb wij:
=20
C++ is no better, probably worse. Firstly, the term 'exception' (and 'vector' probably) is disabled in human mind to think about exception.=20
I deal with exceptions every day and I've no problems with that. C++ exceptions aren't that clean like Java exceptions, but still make much
less work than C return code handling.
wrongC++ had been trying to HIDE error (exception) from its beginning, very =
and very unsuccessful.=20
Exceptions are the cleanest way of error handling.=C2=A0
In most cases you
deal with the error in a higher function and not in the leaf of the
call graph; therefore exceptions are perfect.
The error from opendir(..):
EACCES Permission denied.
EBADF fd is not a valid file descriptor opened for reading.
EMFILE The per-process limit on the number of open file descriptors has
been reached.
ENFILE The system-wide limit on the total number of open files has been
reached.
ENOENT Directory does not exist, or name is an empty string.
ENOMEM Insufficient memory to complete the operation.
ENOTDIR name is not a directory.
...
I think your 'less work' was from simplication or idealization, lots are simplified and idealized.
If you can handle errors that way, C can also do it in much simpler way.
The basic problem of throwing error is losing error context, it is similar
to set a global errno (or object) and cause the program to stack unwind.
C++ has many artificial fancy things and encourages such programming style. Good or bad? Both, but I would say mostly bad.
Am 07.06.2025 um 20:43 schrieb wij:d file descriptor opened for reading.
=20
The error from opendir(..):
=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EACCES Permission denied. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EBADF=C2=A0 fd is not a vali=
limit on the number of open file descriptors has=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EMFILE The=C2=A0 per-process=
=A0=C2=A0=C2=A0 been reached.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
on the total number of open files has=C2=A0 been=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENFILE The system-wide limit=
=A0=C2=A0=C2=A0 reached.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
ist, or name is an empty string.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOENT Directory does not ex=
o complete the operation.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOMEM Insufficient memory t=
ory.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOTDIR name is not a direct=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...=20
With C++ that's all encapsulated in filesystem_error which is derived
from system_error. But you can omit permission denied errors with directory_options::skip_permission_denied. That makes sense mostly
with recursive_directory_iterator.=C2=A0
If you want to to that in C you'vee
at least ten times the code.
=20
I think your 'less work' was from simplication or idealization, lots ar=
..simplified and idealized.=20
No, show me your C code to iterate through a directory and I show you
the same code with up to a fifth of C++-code. When you iterate=20 recur-sively that's a tenth of the code.
=20
If you can handle errors that way, C can also do it in much simpler way=
=20lar
Absolutely not.
=20
The basic problem of throwing error is losing error context, it is simi=
..to set a global errno (or object) and cause the program to stack unwind=
=20yle.
The context doesn't matter. A bad_alloc doesn't need context, a
system_error also not. And that's most of the exceptions the C++
runtime throws (some are derived from system_error).
=20
C++ has many artificial fancy things and encourages such programming st=
Good or bad? Both, but I would say mostly bad.=20
C is bad, because you've to do simple things over and over with multiple times the code because there are no language-facilities to abstract your coding.
Am 07.06.2025 um 20:43 schrieb wij:
The basic problem of throwing error is losing error context, [...]
The context doesn't matter. A bad_alloc doesn't need context, a
system_error also not. And that's most of the exceptions the C++
runtime throws (some are derived from system_error).
I see std::filesystem as evidence that C++ finally admits the deficiency of its advance error handling system (std::exception). But the result is worse than C.
I am not familiar with C++ std lib, I cannot say much.
I see std::filesystem as evidence that C++ finally admits the deficiency of its advance error handling system (std::exception). But the result is worse
than C.
Am 07.06.2025 um 21:56 schrieb wij:
I see std::filesystem as evidence that C++ finally admits the deficiency of >> its advance error handling system (std::exception). But the result is worse
than C.
That's just a mere assertion without any facts. In fact, exception
handling makes error handling possible with a fraction of the code
length, because most parts of the code don't need to handle errors,
whereas in C they do. In C every call level has to deal with erorrs,
whereas in C++ only one level at the upper edge has to catch the
errors.
Am 07.06.2025 um 21:56 schrieb wij:y of
=20
I see std::filesystem as evidence that C++ finally admits the deficienc=
orseits advance error handling system (std::exception). But the result is w=
=C2=A0> than C.
=20
That's just a mere assertion without any facts.
In fact, exception
handling makes error handling possible with a fraction of the code
length, because most parts of the code don't need to handle errors,
whereas in C they do. In C every call level has to deal with erorrs,
whereas in C++ only one level at the upper edge has to catch the
errors.
You can of course use setjmp & longjmp in C but depending on how many levels up you jump they could be more trouble than they're worth. I think I've only ever used them once.
I know a bit of the development of std::filesystem. The view of mere 'standard'
disregards fact and uses more the 'assertion' criticized.
"dont' need" is illusion, errors are always there, mostly ignored and encouraged
to ignore by simplification.
C has not hard coded what 'exception' should be. E.g. C can also set an error object and let interested code to handle it in many ways, what's left is impl.
issues.
But, I think the 'throw' mechanism (not std::exception) is good, like many others. 'throw' is more like a soft assert failure, which is no error handling.
Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:
You can of course use setjmp & longjmp in C but depending on how many levels >> up you jump they could be more trouble than they're worth. I think I've only >> ever used them once.
That's makes a lot of work and it's really ugly. And you need global >jump_buf-s for that.
Context, in the general case, matters. ...
It's been decades that I used C++, but back then in the 1990's
we did pass error context with the thrown error object.
That's an inherent part of C++'s exception handling. If you useMost exceptions you throw or catch are bad_allocs or system_errors.
standard error classes without context that's of course possible,
but nothing prevents you to define yet another error class derived
from some existing error class with additional information. You
are actually free to do what suits you and your projects best;
use rudimentary handling, or have a sophisticated error framework,
or anything in between.
Its no different to C++ exceptions except obviously no destructors
are called so there's no chance to do a tidy up at each stack level.
Am 08.06.2025 um 16:52 schrieb wij:tandard'
=20
I know a bit of the development of std::filesystem. The view of mere 's=
disregards fact and uses more the 'assertion' criticized.=20
Another statement without arguments.
ncouraged"dont' need" is illusion, errors are always there, mostly ignored and e=
errorto ignore by simplification.=20
If the code is written to be exception-safe, i.e. it uses
RAII throughout, then this is easily possible.
=20
C has not hard coded what 'exception' should be. E.g. C can also set an=
s impl.object and let interested code to handle it in many ways, what's left i=
anyissues.=20
Are you serious? The fact that the exception type is transported along
with the exception itself makes things really convenient. This way, the
stack can be unrolled until the correct exception handler is found.
=20
But, I think the 'throw' mechanism (not std::exception) is good, like m=
andling.others. 'throw' is more like a soft assert failure, which is no error h=
=20
Totally different - asserts are handled at debug-time.
Based on this statement, you didn't understand exceptions correctly.
On Sun, 8 Jun 2025 17:02:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:
Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:
You can of course use setjmp & longjmp in C but depending on how many levels
up you jump they could be more trouble than they're worth. I think I've only
ever used them once.
That's makes a lot of work and it's really ugly. And you need global >>jump_buf-s for that.
Its no different to C++ exceptions except obviously no destructors are called >so there's no chance to do a tidy up at each stack level. Also jumps arn't >limited to lower to higher stack frames jumps, they can jump about all over >the place. Whether thats useful or not I can't say. I've never needed it.
Am 07.06.2025 um 23:12 schrieb Janis Papanagnou:
Context, in the general case, matters. ...
If you need the context then you catch the exception near where
it is thrown; but that's not usual, meaning in most cases you
don't need that context. F.e. when a bad_alloc is thown it dosn't
matter which allocation failed, it's just enough to know that a >memory-collapse happened.
Muttley@DastardlyHQ.org writes:
On Sun, 8 Jun 2025 17:02:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:
Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:
You can of course use setjmp & longjmp in C but depending on how many levels
up you jump they could be more trouble than they're worth. I think I've only
ever used them once.
That's makes a lot of work and it's really ugly. And you need global >>>jump_buf-s for that.
Its no different to C++ exceptions except obviously no destructors are called >>so there's no chance to do a tidy up at each stack level. Also jumps arn't >>limited to lower to higher stack frames jumps, they can jump about all over >>the place. Whether thats useful or not I can't say. I've never needed it.
I've used sigsetjmp/siglongjmp in C++ code, very successfully. As an experiment a few
years ago, I replaced it with C++ exceptions and took a 20% performance
hit in the application. Needless to say the experiment was a failure.
In general, I tend to concur with wij - I prefer to handle run-of-the-mill errors when they're detected.
For example:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
c_file_card_unit::c_file_card_unit(ulong channel, ulong unit, const char *name,
So, if is_ready() returns false after the constructor runs,
the creator of the object knows the creation failed.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 07.06.2025 um 23:12 schrieb Janis Papanagnou:
Context, in the general case, matters. ...
If you need the context then you catch the exception near where
it is thrown; but that's not usual, meaning in most cases you
don't need that context. F.e. when a bad_alloc is thown it dosn't
matter which allocation failed, it's just enough to know that a
memory-collapse happened.
Actually it very much matters where the allocation failed, if
one wishes to recover from it.
It seems your concept of error
handling is simply reporting it (hopefully with sufficient
context information for the user to understand what needs to
be fixed) and calling exit().
My primary interest of programming is on the theory. ...
I've used sigsetjmp/siglongjmp in C++ code, very successfully. As an experiment a few
years ago, I replaced it with C++ exceptions and took a 20% performance
hit in the application. Needless to say the experiment was a failure.
Actually it very much matters where the allocation failed, if
one wishes to recover from it.
Am 08.06.2025 um 18:28 schrieb wij:
=20
My primary interest of programming is on the theory. ...=20
Then don't talk about practical issues.
In C every call level has to deal with erorrs, whereas in C++ only
one level at the upper edge has to catch the errors.
Am 08.06.2025 um 17:08 schrieb Muttley@DastardlyHQ.org:
Its no different to C++ exceptions except obviously no destructors
are called so there's no chance to do a tidy up at each stack level.
It's much more complicated than exceptions because the functions where
the error raises and where the error is "caught" need shared global >variables. C++ doesn't need that, just throw and catch and everything
is glued to the runtime.
And the problem with your solution is: All functions between the setjmp-
and the longjmp-calls don't have any cleanup, i.e. they don't handle
back their opened resources to the runtime or the kernel. With RAII in >combination with exceptions that's for free.
Do you really think setjmp() / longjmp() is a competitive solution ?
You're naive.
In general, I tend to concur with wij - I prefer to handle run-of-the-mill >errors when they're detected.
Did you actually read what I wrote? Obviously in C++ you'd use exceptionsI ask myself if setjmp() / longjmp() with manual unwinding then is
but in C without any kind of built in exception mechanism they're better
than nothing if you want to jump out of a deep stack.
Same here. I think with exceptions the clue is in the name. They should really
only be used for exceptional circumstances, not as a general minor error handling mechanism.
Not necessarily that simple. It might be easier if C++ had
try/finally (like Python does), but it doesn’t.
Am 08.06.2025 um 18:58 schrieb Scott Lurndal:
Actually it very much matters where the allocation failed, if
one wishes to recover from it.
This very rarely makes sense. It's almost always the case that if
an operation fails, it doesn't matter what allocation was behind
it.
Have you ever written real-world production code? Like an operating system, where allocation failures should -never- result in an
inability to recover.
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating
system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating
system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
Exacerbated by the propensity for you to use C++ features that require dynamic allocation where other forms of data structures are more suitable.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating
system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating >>>> system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
That's how 100% of all programs that deal with bad_alloc are designed.
Exacerbated by the propensity for you to use C++ features that require
dynamic allocation where other forms of data structures are more suitable.
When dynamic allocation is needed it is needed.
And there are many ways to handle it that don't include throwing
bad_alloc when the system is unable to provide additional address
space, memory or backing store.
Allocating major data structures at application start (perhaps using
a pool allocator) and crafting your algorithms such that they
don't require infinite memory is a good start.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 08.06.2025 um 18:58 schrieb Scott Lurndal:
Actually it very much matters where the allocation failed, if
one wishes to recover from it.
This very rarely makes sense. It's almost always the case that if
an operation fails, it doesn't matter what allocation was behind
it.
Have you ever written real-world production code? Like an operating system, where allocation failures should -never- result in an
inability to recover.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating >>>>> system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
That's how 100% of all programs that deal with bad_alloc are designed.
Exacerbated by the propensity for you to use C++ features that requireWhen dynamic allocation is needed it is needed.
dynamic allocation where other forms of data structures are more suitable. >>
And there are many ways to handle it that don't include throwing
bad_alloc when the system is unable to provide additional address
space, memory or backing store.
Allocating major data structures at application start (perhaps using a
pool allocator) and crafting your algorithms such that they
don't require infinite memory is a good start.
You're talking to someone who can't understand the difference
between comp.lang.c and comp.lang.c++. What do you expect?
On 2025-06-08, Scott Lurndal <scott@slp53.sl.home> wrote:
Muttley@DastardlyHQ.org writes:
On Sun, 8 Jun 2025 17:02:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:
Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:
You can of course use setjmp & longjmp in C but depending on how
many levels up you jump they could be more trouble than they're
worth. I think I've only ever used them once.
That's makes a lot of work and it's really ugly. And you need
global jump_buf-s for that.
setjmp and longjmp have a clearly defined implementation model
(obviously not in ISO C, but so in implementation practice).
On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security
holes on operations with symlinks.
Which security holes ?
TOCTOU.
On Mon, 09 Jun 2025 18:33:38 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating >>>>>> system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
That's how 100% of all programs that deal with bad_alloc are designed.
Exacerbated by the propensity for you to use C++ features that require >>>> dynamic allocation where other forms of data structures are more suitable. >>>When dynamic allocation is needed it is needed.
And there are many ways to handle it that don't include throwing
bad_alloc when the system is unable to provide additional address
space, memory or backing store.
Allocating major data structures at application start (perhaps using a
pool allocator) and crafting your algorithms such that they
don't require infinite memory is a good start.
Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >causes huge startup delays and can often cause the machine to do lots of >swapping and/or slow everything else down to treacle.
And all the existing C compilers in the entire planet support
the C90 dialect[*], if so instructed. Where is the problem?
Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:
On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security
holes on operations with symlinks.
Which security holes ?
TOCTOU.
That's unavoidable with directory-operations.
That's unavoidable with directory-operations.
Incorrect. The entire purpose of the POSIX *at functions are to close
those security holes.
Muttley@DastardlyHQ.org writes:
Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >>causes huge startup delays and can often cause the machine to do lots of >>swapping and/or slow everything else down to treacle.
That's a problem with host not being suitable for java, if that
is the behavior you are seeing. I've not seen that in production
java-based applications that are competently developed.
For C/C++, one generally allocates page-aligned regions with mmap, eschewing >granular allocation methods such as new/delete/malloc.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
[...]
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an
uppercase letter are reserved; they could be defined as macros
in <errno.h>.)
They are reserved only as macros, and only if <errno.h> has
been #include'd.
For this particular use, it's easy to make the definition work,
simply by adding
#undef ESCAPE
before the declaration in the header file, and before the
definition in the source file (assuming of course that if
there are any #include <errno.h> they precede the #undef's).
It would be even easier to pick a different name.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:
On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>>> directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security
holes on operations with symlinks.
Which security holes ?
TOCTOU.
That's unavoidable with directory-operations.
Incorrect. The entire purpose of the POSIX *at functions are to close
those security holes.
Muttley@DastardlyHQ.org writes:
On Mon, 09 Jun 2025 18:33:38 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:That's your problem caused by poor design and implementation.
Have you ever written real-world production code? Like an operating >>>>>>> system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover. >>>>>
That's how 100% of all programs that deal with bad_alloc are designed. >>>>
Exacerbated by the propensity for you to use C++ features that require >>>>> dynamic allocation where other forms of data structures are more suitable.
When dynamic allocation is needed it is needed.
And there are many ways to handle it that don't include throwing
bad_alloc when the system is unable to provide additional address
space, memory or backing store.
Allocating major data structures at application start (perhaps using a
pool allocator) and crafting your algorithms such that they
don't require infinite memory is a good start.
Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >> causes huge startup delays and can often cause the machine to do lots of
swapping and/or slow everything else down to treacle.
That's a problem with host not being suitable for java, if that
is the behavior you are seeing. I've not seen that in production
java-based applications that are competently developed.
For C/C++, one generally allocates page-aligned regions with mmap, eschewing granular allocation methods such as new/delete/malloc.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 09.06.2025 um 16:01 schrieb Scott Lurndal:
Have you ever written real-world production code? Like an operating >>>>> system, where allocation failures should -never- result in an
inability to recover.
If you need an allocation to proceed and it fails you can't recover.
That's your problem caused by poor design and implementation.
That's how 100% of all programs that deal with bad_alloc are designed.
Exacerbated by the propensity for you to use C++ features that requireWhen dynamic allocation is needed it is needed.
dynamic allocation where other forms of data structures are more suitable. >>
And there are many ways to handle it that don't include throwing
bad_alloc when the system is unable to provide additional address
space, memory or backing store.
Allocating major data structures at application start (perhaps using a
pool allocator) and crafting your algorithms such that they
don't require infinite memory is a good start.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:[...]
Richard Harnden <richard.harnden@gmail.invalid> writes:
On 22/05/2025 23:32, Keith Thompson wrote:
In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.
Wouldn't that be a reserved identifier?
Yes, it would. Good catch.
(Identifiers starting with E followed by either a digit or an
uppercase letter are reserved; they could be defined as macros
in <errno.h>.)
They are reserved only as macros, and only if <errno.h> has
been #include'd.
For this particular use, it's easy to make the definition work,
simply by adding
#undef ESCAPE
before the declaration in the header file, and before the
definition in the source file (assuming of course that if
there are any #include <errno.h> they precede the #undef's).
It would be even easier to pick a different name.
The point of my comment was to help explain the rules about what
macro names are reserved and under what circumstances, not to
suggest a way to avoid conflicts.
A better way to avoid conflicts with E* macros is to take functions
where errno is needed, as for example signal(), and not call them
directly but rather wrap each one in a function, with the wrapping
functions put in (one or more) separate translation unit(s). Those translation units, and only those translation units, are the ones
where a #include <errno.h> is done. Some details are needed to keep
the separation complete, but I think those aren't too hard to work
out, so if someone has trouble please ask. This way most of the
program can use names beginning with E that might otherwise be
reserved, without any fear of conflicts. There is a bit of source
code overhead, but that is paid only once, across all projects that
use this approach. Also there are some other benefits, related to
libraries used that are not part of ISO C, such as Posix, which
again should be readily apparent to anyone used to working in large
projects that use such libraries.
I find the reservation of potential errno macro names annoying.
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
I find the reservation of potential errno macro names annoying.
If the standard contained /no/ statements about what a given header
file may reserve, then /any/ identifier whatsoever would be a potential clash.
The errno reservation is kind of good because implementors often extend
the set of errno constants. POSIX has a lot more of them than ISO C, and there are some vendor-specific ones.
Anyway, you can safely ignore the reservation theatre, and just
deal with clashes that happen, when they happen. (If you're lucky,
that could just be never).
Anyway, ISO C, POSIX and vendors have historically introduced new
identifiers in spaces that were not previously declared as reserved.
If you're ever hit by that, you will feel like a completel sucker if
you've religiously adhered to namespaces from your end.
Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:\",
On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:
Sth. like this:
for( directory_entry const &de : recursive_directory_iterator( "\
directory_options::follow_directory_symlink ) )
cout << de.path() << endl;
You need the dirfd functions to avoid certain potential security
holes on operations with symlinks.
Which security holes ?
TOCTOU.
That's unavoidable with directory-operations.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
I find the reservation of potential errno macro names annoying.
If the standard contained /no/ statements about what a given header
file may reserve, then /any/ identifier whatsoever would be a potential
clash.
The errno reservation is kind of good because implementors often extend
the set of errno constants. POSIX has a lot more of them than ISO C, and
there are some vendor-specific ones.
Anyway, you can safely ignore the reservation theatre, and just
deal with clashes that happen, when they happen. (If you're lucky,
that could just be never).
You can do that, but a new clash could happen when your code is
compiled on a system that defines an errno macro that you haven't
seen before.
Anyway, ISO C, POSIX and vendors have historically introduced new
identifiers in spaces that were not previously declared as reserved.
If you're ever hit by that, you will feel like a completel sucker if
you've religiously adhered to namespaces from your end.
Yes, that can happen, but no, I won't feel like a complete sucker.
If I define my own strfoo() function and a new edition of the standard defines strfoo() in <string.h>, the clash is my fault,and I could have avoided it by defining str_foo().
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
I find the reservation of potential errno macro names annoying.
If the standard contained /no/ statements about what a given header
file may reserve, then /any/ identifier whatsoever would be a potential
clash.
The errno reservation is kind of good because implementors often extend
the set of errno constants. POSIX has a lot more of them than ISO C, and >>> there are some vendor-specific ones.
Anyway, you can safely ignore the reservation theatre, and just
deal with clashes that happen, when they happen. (If you're lucky,
that could just be never).
You can do that, but a new clash could happen when your code is
compiled on a system that defines an errno macro that you haven't
seen before.
A new CRASH could happen too, and any number of things.
This clash would be literally one of the first roadblocks, if not the
first one, that we would see when just exploring the possibility whether
our code might not run on that system.
At that point we could be months away from declaring that a supported platform.
Anyway, ISO C, POSIX and vendors have historically introduced new
identifiers in spaces that were not previously declared as reserved.
If you're ever hit by that, you will feel like a completel sucker if
you've religiously adhered to namespaces from your end.
Yes, that can happen, but no, I won't feel like a complete sucker.
If I define my own strfoo() function and a new edition of the standard
defines strfoo() in <string.h>, the clash is my fault,and I could have
avoided it by defining str_foo().
But, my point is, that maybe you could have called it kidneybeans() and
still have a clash.
In fact, if you are writing new string functions that are the same sort
of stuff like the standard ones, you should use the str prefix,
for consistency.
If your code is influential enough, they might be standardized one
day---and then they are ready with the proper naming, so early adopters
of your functions won't have to change anything; just in their build
system drop the third party code and switch to what their library now provides.
No it isn’t. That’s why we have the fd-based calls in recent POSIX, and in
Linux. That plugs the holes, and makes it possible to implement privileged file-access software like Samba securely.
Am 11.06.2025 um 01:33 schrieb Lawrence D'Oliveiro:
No it isn’t. That’s why we have the fd-based calls in recent POSIX, and >> in Linux. That plugs the holes, and makes it possible to implement
privileged file-access software like Samba securely.
opendir() and readdir() hasn't changed for decades.
Am 11.06.2025 um 01:33 schrieb Lawrence D'Oliveiro:
No it isn’t. That’s why we have the fd-based calls in recent POSIX, and in
Linux. That plugs the holes, and makes it possible to implement privileged >> file-access software like Samba securely.
opendir() and readdir() hasn't changed for decades.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
I find the reservation of potential errno macro names annoying.
If the standard contained /no/ statements about what a given header
file may reserve, then /any/ identifier whatsoever would be a potential >>>> clash.
The errno reservation is kind of good because implementors often extend >>>> the set of errno constants. POSIX has a lot more of them than ISO C, and >>>> there are some vendor-specific ones.
Anyway, you can safely ignore the reservation theatre, and just
deal with clashes that happen, when they happen. (If you're lucky,
that could just be never).
You can do that, but a new clash could happen when your code is
compiled on a system that defines an errno macro that you haven't
seen before.
A new CRASH could happen too, and any number of things.
Sure, but a compilation failure is more likely.
This clash would be literally one of the first roadblocks, if not the
first one, that we would see when just exploring the possibility whether
our code might not run on that system.
At that point we could be months away from declaring that a supported
platform.
Sure, but why not skip that first roadblock?
Anyway, ISO C, POSIX and vendors have historically introduced new
identifiers in spaces that were not previously declared as reserved.
If you're ever hit by that, you will feel like a completel sucker if
you've religiously adhered to namespaces from your end.
Yes, that can happen, but no, I won't feel like a complete sucker.
If I define my own strfoo() function and a new edition of the standard
defines strfoo() in <string.h>, the clash is my fault,and I could have
avoided it by defining str_foo().
But, my point is, that maybe you could have called it kidneybeans() and
still have a clash.
Certainly, I've already acknowledged that.
But surely an identifier that the standard says is reserved is less
likely to cause a clash than one that isn't.
In fact, if you are writing new string functions that are the same sort
of stuff like the standard ones, you should use the str prefix,
for consistency.
If your code is influential enough, they might be standardized one
day---and then they are ready with the proper naming, so early adopters
of your functions won't have to change anything; just in their build
system drop the third party code and switch to what their library now
provides.
I see your point, but ... meh. To me, a name matching "str[a-z]*"
fairly strongly suggests a function declared in <string.h> in ISO C.
Of course it's not an absolute rule; see strlcpy(), for example
(which is now part of POSIX).
Even a str*() identifier that never clashes with ISO C's <string.h>
can still clash with POSIX, or glibc, or BSD, or ....
I would have been happier if POSIX were less intrusive on the
C standard library, but the way C and POSIX evolved didn't make
that feasible.
I find the reservation of potential errno macro names annoying.
That turns out to not be true. fdopendir(3) was added in Issue
7 of the Single Unix Specification (aka POSIX). https://pubs.opengroup.org/onlinepubs/9799919799/functions/fdopendir.html ftw(3)/nftw(3) are used more often than opendir(3) in real world code.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
I find the reservation of potential errno macro names annoying.
If the standard contained /no/ statements about what a given header
file may reserve, then /any/ identifier whatsoever would be a potential
clash.
The errno reservation is kind of good because implementors often extend
the set of errno constants. POSIX has a lot more of them than ISO C, and
there are some vendor-specific ones.
Anyway, you can safely ignore the reservation theatre, and just
deal with clashes that happen, when they happen. (If you're lucky,
that could just be never).
You can do that, but a new clash could happen when your code is
compiled on a system that defines an errno macro that you haven't
seen before.
Anyway, ISO C, POSIX and vendors have historically introduced new
identifiers in spaces that were not previously declared as reserved.
If you're ever hit by that, you will feel like a completel sucker if
you've religiously adhered to namespaces from your end.
Yes, that can happen, but no, I won't feel like a complete sucker.
If I define my own strfoo() function and a new edition of the standard defines strfoo() in <string.h>, the clash is my fault,and I could have avoided it by defining str_foo().
Nothing can prevent all possible name clashes, but I like to follow the
rules in the standard that let me prevent some of them.
[fdopendir] doesn't make a difference for the discussed point.
On 28/05/2025 13:41, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 24/05/2025 06:32, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 23/05/2025 13:43, Tim Rentsch wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 20/05/2025 10:18, Keith Thompson wrote:
C90 will never be extended.
And for that reason it will always be valuable. Stability
has a value all its own.
C99 is just as stable as C90, and has been for well over a
decade.
Sure, but it's a different stable.
If it were the same stable, it would be C90.
C99 isn't C90, therefore it isn't the same stable.
If you tell me C99 is a rock, I will not doubt you. But the C90
rock it most certainly isn't.
Now you're being silly.
No, sir. If you want to play that game, you can play it with
yourself. I know that you are perfectly capable of polite
conversation, so I see no reason to endure the opposite.
I don't think I'm being impolite.
Then we are again in disagreement, and it seems obvious that it would
be foolishly optimistic of me to expect to be able to resolve the
matter. I'll tell Thunderbird to leave it there.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 101:34:11 |
| Calls: | 161 |
| Files: | 21,502 |
| Messages: | 78,549 |