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.
C90 will never be extended.
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 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.
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.
The folder routines will do everything I need.
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.
"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).
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"?
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:
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".
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.
"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).
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 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 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 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 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.
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.
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> 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.
"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.
... 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.
My programs work anywhere.
We have very different goals.
... maybe it is C90 that was wrong to specify argc and argv and
the Pascal people got it right.
Basically the software industry is a joke. The advances have all been
done by hardware engineers.
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.
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, ...
"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"
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.
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,
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.
That's a complete and utter lie.
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 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.
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 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.
"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.
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.
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.
Scott has a very long reputation in this and related newsgroups,
and is very much a trustworthy poster.
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.
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>
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.
"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.
Fun fact: even IBM mainframes run Linux now.
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.
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 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?
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.
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.
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".
Moreover, what is the definition of 'character' in this context?
Something that fgetc() would be able to consume without blocking.
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.
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.
"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); [...]
[...]
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.'
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 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.
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 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.
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 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.
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.
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 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.
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.)
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.
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.
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!")?
"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.
"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.
"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]
"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.
[...]
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.
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 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 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.
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.
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.
"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.
"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.
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 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 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:
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?
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 ...)
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 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:
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.
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 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 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'.
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.
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?
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?
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'.
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.
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:
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 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 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)
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
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;
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."
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 ?
"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.
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.
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 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?
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".
(There are obvious advantages to working with a widely used,
contemporary system; I don't see it necessary to go into those.)
A C program built on and running on an ASCII system, handling EBCDIC
data, could benefit from having an E"..." string literal feature, as
well as a E' ' character constant feature, either as a compiler
extension or a preprocessing tool, so that in places where EBCDIC text
is being handled, literals in that encoding could be conveniently
specified.
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).
"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.
"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.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.
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.
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().
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.
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 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.
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).
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 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.
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.
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.
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.
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.
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.
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.
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.
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, 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.
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.
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.
And all the existing C compilers in the entire planet support
the C90 dialect[*], if so instructed. Where is the problem?
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.
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.
I find the reservation of potential errno macro names annoying.
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().
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.
I find the reservation of potential errno macro names annoying.
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.
[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.
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.
"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100jhor$2lgt3$4@dont-email.me...
On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:...
The C90 standard deferred to MVS - probably still does -
and says that you can't open a file as "w", then read it as
"rb" and write (a new file) as "wb", and still access (the
new file) with "r".
I was shocked when I saw IBM's C library lose the newlines
when I did the above, and went to look at the standard to
show that IBM was violating C90 - but it turns out they
weren't.
That sort of means you can't write a "zip" program portably,
against the theoretical C90 file system. Or you would have
to have flags to say which files need to be opened as text
or binary.
I do not agree with IBM's C library, and PDPCLIB does
not have that behavior, so that constraint could potentially
be dropped in a C90+ standard.
BFN. Paul.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
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.
I don't believe that NTFS requires filename extensions.
My understanding is that a file name is stored as a single string
(with some restrictions).
Symlinks were not even added until Windows Vista. And you have to have
special privileges to create them.
Do note one more thing.
The C90 standard deferred to MVS - probably still does -
and says that you can't open a file as "w", then read it as
"rb" and write (a new file) as "wb", and still access (the
new file) with "r".
I was shocked when I saw IBM's C library lose the newlines
when I did the above, and went to look at the standard to
show that IBM was violating C90 - but it turns out they
weren't.
That sort of means you can't write a "zip" program portably,
against the theoretical C90 file system.
Or you would have
to have flags to say which files need to be opened as text
or binary.
On 2025-05-21, Paul Edwards <mutazilah@gmail.com> wrote:...
Do note one more thing.
The C90 standard deferred to MVS - probably still does -
and says that you can't open a file as "w", then read it as
"rb" and write (a new file) as "wb", and still access (the
new file) with "r".
You mean:
- write a text file, close it; then
- open it as a binary file and copy the bytes to another, new binary file; and
- finally, read the new binary file in text mode?
I don't see how that would be allowed to lose any newlines.
You made a bitwise copy of the file.
A recent draft of ISO C says "A binary stream is an ordered sequence of characters that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that were earlier written out to that stream, under the same implementation. Such a stream
may, however, have an implementation- defined number of null characters appended to the end of the stream."
I have C90 somewhere, I can look that up too, but I suspect it was
the same.
I was shocked when I saw IBM's C library lose the newlines
when I did the above, and went to look at the standard to
show that IBM was violating C90 - but it turns out they
weren't.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:48:34 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,760 |