| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:36:54 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,577 |
On Sat, 19 Apr 2025 17:15:42 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 19/04/2025 09:46, Janis Papanagnou wrote:
On 17.04.2025 17:56, David Brown wrote:
But anyway, the newest breakthrough is thorium
nuclear clocks, which IIRC are 5 orders of magnitude more stable
than cesium clocks. (And probably 5 orders of magnitude more
expensive...)
I've not heard of Thorium based clocks. But I've heard of
"optical clocks" that are developed to get more precise and
more stable versions of atomic clock times.
It was only last year that a good measurement of the resonant
frequencies of the Thorium 229 nucleus was achieved - the science bit
is done, now the engineering bit needs to be finished to get a
practical nuclear clock.
Record my prediction: it's not going to happen.
David Brown <david.brown@hesbynett.no> writes:
[...]
I don't know enough about Thorium 229 nuclear resonances to be able
to predict one way or the other. Do you have a good reason or
reference for your thoughts here?
Can you PLEASE take this somewhere else? (Or drop it, I don't care.)
Don't read anything into the fact that I replied to one particular participant in the thread.
On 19/04/2025 22:15, Michael S wrote:
On Sat, 19 Apr 2025 17:15:42 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 19/04/2025 09:46, Janis Papanagnou wrote:
On 17.04.2025 17:56, David Brown wrote:
But anyway, the newest breakthrough is thorium
nuclear clocks, which IIRC are 5 orders of magnitude more stable
than cesium clocks. (And probably 5 orders of magnitude more
expensive...)
I've not heard of Thorium based clocks. But I've heard of
"optical clocks" that are developed to get more precise and
more stable versions of atomic clock times.
It was only last year that a good measurement of the resonant
frequencies of the Thorium 229 nucleus was achieved - the science
bit is done, now the engineering bit needs to be finished to get a
practical nuclear clock.
Record my prediction: it's not going to happen.
I don't know enough about Thorium 229 nuclear resonances to be able
to predict one way or the other. Do you have a good reason or
reference for your thoughts here?
On Mon, 21 Apr 2025 14:28:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
I don't know enough about Thorium 229 nuclear resonances to be able
to predict one way or the other. Do you have a good reason or
reference for your thoughts here?
Can you PLEASE take this somewhere else? (Or drop it, I don't care.)
Don't read anything into the fact that I replied to one particular
participant in the thread.
There are two types of usenet groups:
- groups that suffer from significat amount of OT discussions
- dead
On Wed, 02 Apr 2025 16:59:59 +1100
Alexis <flexibeast@gmail.com> wrote:
Thought people here might be interested in this image on Jens
Gustedt's blog, which translates section 6.2.5, "Types", of the C23
standard into a graph of inclusions:
https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
That's a little disappointing.
IMHO, C23 should have added optional types _Binary32, _Binary64,
_Binary128 and _Binary256 that designate their IEEE-754 namesakes.
Plus, a mandatory requirement that if compiler supports any of IEEE-754 binary types then they have to be accessible by above-mentioned names.
On Wed, 16 Apr 2025 23:13:58 +0100, Richard Heathfield wrote:
1) No account is taken of the 11-day shift in September 1752.
root@debian10:~ # ncal -s IT 10 1582
October 1582
Su 17 24 31
Mo 1 18 25
Tu 2 19 26
We 3 20 27
Th 4 21 28
Fr 15 22 29
Sa 16 23 30
Michael S <already5chosen@yahoo.com> writes:
On Wed, 02 Apr 2025 16:59:59 +1100
Alexis <flexibeast@gmail.com> wrote:
Thought people here might be interested in this image on Jens
Gustedt's blog, which translates section 6.2.5, "Types", of the C23
standard into a graph of inclusions:
https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/ >>
That's a little disappointing.
IMHO, C23 should have added optional types _Binary32, _Binary64,
_Binary128 and _Binary256 that designate their IEEE-754 namesakes.
Plus, a mandatory requirement that if compiler supports any of
IEEE-754 binary types then they have to be accessible by
above-mentioned names.
I see where you're coming from,
but I disagree with the suggested
addition; it simultaneously does too much and not enough. If
someone wants some capability along these lines, the first step
should be to understand what the underlying need is, and then to
figure out how to accommodate that need. The addition described
above creates more problems than it solves.
[...]
Back in the mainframe days, it was common to use julian dates
as they were both concise (5 BCD digits/20 bits) and sortable.
YYDDD
If time was neeeded, it was seconds since midnight in a reference
timezone.
[ Just noticed this post while catching up in my backlog, so I'm not
sure my questions/comments have already been addressed elsewhere. ]
On 16.04.2025 22:04, Scott Lurndal wrote:
[...]
Back in the mainframe days, it was common to use julian dates
as they were both concise (5 BCD digits/20 bits) and sortable.
YYDDD
If time was neeeded, it was seconds since midnight in a reference
timezone.
I don't quite understand the rationale behind all that said above.
"YYDDD" was used without century information? How is that useful?
(I assume it's just the popular laziness that later lead to all the
Y2k chaos activities.)
And "seconds since midnight" where taken despite the Julian Dates
have a day start at high noon (12:00)? [*]
[ Just noticed this post while catching up in my backlog, so I'm not[snip]
sure my questions/comments have already been addressed elsewhere. ]
On 16.04.2025 22:04, Scott Lurndal wrote:
[...]
Back in the mainframe days, it was common to use julian dates
as they were both concise (5 BCD digits/20 bits) and sortable.
YYDDD
If time was neeeded, it was seconds since midnight in a reference
timezone.
I don't quite understand the rationale behind all that said above.
"YYDDD" was used without century information? How is that useful?
(I assume it's just the popular laziness that later lead to all the
Y2k chaos activities.)
I believe the current rule for software is to consider "39" the cutoff,
ie 39 is considered 2039, and 40 is considered 1940. I agree though,
removing the century is a bad idea for anything that is supposed to be
kept for a length of time.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
[*] I recall that e.g. SunOS also had that wrong and assumed start at
midnight. Folks generally don't seem to be aware of that difference.
I don't recall SunOS using any kind of Julian days/dates for anything
at the system level, though some programs might. [...]
On 4/28/25 20:10, Janis Papanagnou wrote:
[...]
And "seconds since midnight" where taken despite the Julian Dates
have a day start at high noon (12:00)? [*]
Strictly speaking, "Julian Day" is the number of days since Jan 01 4713
BCE at Noon (a date that was chosen because it simplifies conversion
between several different ancient calendar systems. It starts at Noon
because it was devised for use by astronomers, who are generally awake
at midnight and asleep at Noon (especially in ancient times).
Informally speaking, "Julian Day" is commonly used to refer to any
system for designating dates that include a "day of year" component, as
does the above example. Most of these start at midnight, not Noon.
There's no use being a purist about this (that would be my preference
too) - the informal meaning is quite common, probably more common than
the "correct" one.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[ Just noticed this post while catching up in my backlog, so I'm not
sure my questions/comments have already been addressed elsewhere. ]
On 16.04.2025 22:04, Scott Lurndal wrote:
[...]
Back in the mainframe days, it was common to use julian dates
as they were both concise (5 BCD digits/20 bits) and sortable.
YYDDD
If time was neeeded, it was seconds since midnight in a reference
timezone.
I don't quite understand the rationale behind all that said above.
"YYDDD" was used without century information? How is that useful?
(I assume it's just the popular laziness that later lead to all the
Y2k chaos activities.)
Yes, it was felt that saving storage (perhaps in the form of columns
on punch cards) was more important than supporting dates after 1999.
One relic of this is the tm_year member of struct tm in <time.h>,
which holds number of years since 1900. It was (I'm fairly sure)
originally just a 2-digit year number.
And "seconds since midnight" where taken despite the Julian Dates
have a day start at high noon (12:00)? [*]
The Julian day number used by astronomers does start at noon,
specifically at noon, Universal Time, Monday, January 1, 4713 BC
in the proleptic Julian calendar. As I write this, the current
Julian date is 2460794.591939746.
Outside of astronomy, the word Julian is (mis)used for just about
anything that counts days rather than months and days. A date
expressed in the form YYDDD (or YYYYDDD, or YYYYDDD) almost certainly
refers to a calendar day, starting and ending at midnight in some
time zone. See also the tm_yday member of struct tm, which counts
days since January 1 of the specified year.
On 4/29/2025 12:24 AM, James Kuyper wrote:
On 4/29/25 01:10, candycanearter07 wrote:
...
I believe the current rule for software is to consider "39"
the cutoff,
ie 39 is considered 2039, and 40 is considered 1940. I agree
though,
removing the century is a bad idea for anything that is
supposed to be
kept for a length of time.
I sincerely doubt that there is any unique current rule for
interpreting
two-digit year numbers - just a wide variety of different rules
used by
different people for different purposes. That's part of the
reason why
it's a bad idea to rely upon such rules.
Could always argue for a compromise, say, 1 signed byte year.
Say: 1872 to 2127, if origin is 2000.
Could also be 2 digits if expressed in hexadecimal.
Or, maybe 1612 BC to 5612 AD if the year were 2 digits in Base 85.
Or, 48 BC to 4048 AD with Base 64.
On 4/29/2025 12:24 AM, James Kuyper wrote:
On 4/29/25 01:10, candycanearter07 wrote:
...
I believe the current rule for software is to consider "39" the cutoff,
ie 39 is considered 2039, and 40 is considered 1940. I agree though,
removing the century is a bad idea for anything that is supposed to be
kept for a length of time.
I sincerely doubt that there is any unique current rule for interpreting
two-digit year numbers - just a wide variety of different rules used by
different people for different purposes. That's part of the reason why
it's a bad idea to rely upon such rules.
Could always argue for a compromise, say, 1 signed byte year.
Say: 1872 to 2127, if origin is 2000.
Could also be 2 digits if expressed in hexadecimal.
On 2025-04-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
antispam@fricas.org (Waldek Hebisch) writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
[...]
Not always practical. A good example is the type size_t. If a
function takes an argument of type size_t, then the symbol size_t
should be defined, no matter which header the function is being
declared in.
Why? One can use a type without a name for such type.
Convenience and existing practice. Sure, an implementation of
<string.h> could provide a declaration of memcpy() without making
size_t visible, but what would be the point?
Ther eis a point to such a discipline; you get ultra squeaky clean
modules whose header files define only their contribution to
the program, and do not transitively reveal any of the identifiers
from their dependencies.
In large programs, this clean practice can can help prevent
clashes.
[...]
Using memcpy as an example, it could be declared as
void *memcpy(void * restrict d, const void * restrict s,
__size_t size);
size_t is not revealed, but a private type __size_t.
To get __size_t, some private header is included <sys/priv_types.h>
or whatever.
The <stddef.h> header just includes that one and typedefs __size_t
size_t (if it were to work that way).
A system vendor which provides many API's and has the privilege of
being able to use the __* space could do things like this.
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
[some symbols are defined in more than one header]
(In my opinion, things would be better if headers were not allowed
to behave as if they include other headers, or provide identifiers
also given in other heards. Not in ISO C, and not in POSIX.
Every identifier should be declared in exactly one home header,
and no other header should provide that definition. [...])
Not always practical. A good example is the type size_t. If a
function takes an argument of type size_t, then the symbol size_t
should be defined, no matter which header the function is being
declared in.
Why?
One can use a type without a name for such type.
Similarly for NULL for any function that has defined
behavior on some cases of arguments that include NULL.
Why? There are many ways to produce null pointers.
And fact that
a function had defined behavior for null pointers does not mean
that users will need null pointers.
No doubt
there are other compelling examples.
Do not look compelling at all.
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
antispam@fricas.org (Waldek Hebisch) writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
[...]
Not always practical. A good example is the type size_t. If a
function takes an argument of type size_t, then the symbol size_t
should be defined, no matter which header the function is being
declared in.
Why? One can use a type without a name for such type.
Convenience and existing practice. Sure, an implementation of
<string.h> could provide a declaration of memcpy() without making
size_t visible, but what would be the point?
Cleanliness of definitions? Consistency?
Fragment that you
replaced by [...] contained a proposal:
Every identifier should be declared in exactly one home header,
and no other header should provide that definition.
That would be pretty clean and consistent rule: if you need some
standard symbol, then you should include corresponding header.
Tim claimed that this in not practical. Clearly C standard
changed previous practice about headers,
so existing practice is _not_ a practical problem with adapting
such proposal.
With current standard and practice one frequently needs symbols
from several headers,
so "convenience" is also not a practival problem with such
proposal.
People not interested in clean name space can
define private "all.h" which includes all standard C headers
and possibly other things that they need, so for them overhead
is close to zero.
antispam@fricas.org (Waldek Hebisch) writes:
I believe that's not true, but certainly it is not /clearly/ true.
A lot of time passed between 1978, when K&R was published, and 1989,
when the first C standard was ratified. No doubt the C standard
unified different practices among many existing C implementations,
but it is highly likely that some of them anticipated the rules that
would be ratified in the C standard.
The fact that ncal knows about the 11-day shift ...
Strictly speaking, "Julian Day" is the number of days since Jan 01 4713
BCE at Noon ...
On Tue, 8 Apr 2025 20:53:45 +0300 Michael S <already5chosen@yahoo.com> wibbled:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Any chance of using utf8 rather than whatever the hell encoding this is.
On Mon, 28 Apr 2025 07:52:10 +0100, Richard Heathfield wrote:
The fact that ncal knows about the 11-day shift ...
Note the calendar listing I posted had a 10-day shift.
On Mon, 21 Apr 2025 14:28:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
I don't know enough about Thorium 229 nuclear resonances to be able
to predict one way or the other. Do you have a good reason or
reference for your thoughts here?
Can you PLEASE take this somewhere else? (Or drop it, I don't care.)
Don't read anything into the fact that I replied to one particular
participant in the thread.
There are two types of usenet groups:
- groups that suffer from significat amount of OT discussions
- dead
On Mon, 14 Apr 2025 01:59:24 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 09 Apr 2025 13:14:55 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
[may trailing commas in argument lists be accepted, or
must they be rejected?]
It is required in the sense that it is a syntax error,
and syntax errors require a diagnostic.
Trailing commas in argument lists and/or parameter lists
could be accepted as an extension, even without giving a
diagnostic as I read the C standard, but implementations
are certainly within their rights to reject them.
I have no doubts that implementations have full rights to reject
them. The question was about possibility to accept them and
especially about possibility to accept without diagnostics.
So, it seems, there is no consensus about it among few posters
that read the relevant part of the standard.
I don't think anyone should care about that. If there were any
significant demand for allowing such trailing commas then someone
would implement it, and people would use it even if in some
technical sense it meant that an implementation supporting it
would be nonconforming.
Personally, I'd use this feature if it would be standard.
But if it would be non-standard feature supported by both gcc and
clang I would hesitate.
Besides, the opinions of people posting
in comp.lang.c carry zero weight; the only opinions that matter
are those of peole on the ISO C committee, and the major compiler
writers, and none of those people bother posting here.
My impression was that Philipp Klaus Krause that posts here, if
infrequently, is a member of WG14.
Michael S <already5chosen@yahoo.com> writes:
My impression was that Philipp Klaus Krause that posts here, if infrequently, is a member of WG14.
Do you know if he is a member, or is he just an interested
participant?
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
But I would guess that for headers required for freestanding
implementations I would have no problems.
On Sun, 27 Apr 2025 12:05:16 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 02 Apr 2025 16:59:59 +1100
Alexis <flexibeast@gmail.com> wrote:
Thought people here might be interested in this image on JensThat's a little disappointing.
Gustedt's blog, which translates section 6.2.5, "Types", of the C23
standard into a graph of inclusions:
https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/ >>>
IMHO, C23 should have added optional types _Binary32, _Binary64,
_Binary128 and _Binary256 that designate their IEEE-754 namesakes.
Plus, a mandatory requirement that if compiler supports any of
IEEE-754 binary types then they have to be accessible by
above-mentioned names.
I see where you're coming from,
I suppose, you know it because you followed my failed attempt to improve speed and cross-platform consistency of gcc IEEE binary128 arithmetic.
Granted, in this case absence of common name for the type was much
smaller obstacle than general indifference of gcc maintainers.
So, yes, on the "producer" side the problem of absence of common name
was annoying but could be regarded as minor.
Apart from being a "producer", quite often I am on the other side,
wearing a hat of consumer of extended precision types. When in this
role, I feel that the relative weight of inconsistent type names is
rather significant. I'd guess that it is even more significant for
people whose work, unlike mine, is routinely multi-platform. I would
not be surprised if for many of them it ends up as main reason to
refrain completely from use IEEE binary128 in their software; even when
it causes complications to their work and when the type is
readily available, under different names, on all platforms they care
about.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
antispam@fricas.org (Waldek Hebisch) writes:
I believe that's not true, but certainly it is not /clearly/ true.
A lot of time passed between 1978, when K&R was published, and
1989, when the first C standard was ratified. No doubt the C
standard unified different practices among many existing C
implementations, but it is highly likely that some of them
anticipated the rules that would be ratified in the C standard.
Looking at SVID 3rd edition (1989), size_t did not yet exist, so in
that particular case, there was no need to implicitly define it in
any header file.
For interfaces that require custom typedefs (for example, stat(2)),
the SVID requires the programmer include <sys/types.h> before
including <sys/stat.h>.
When size_t was added there were existing interfaces where the
argument was changed to require size_t/ssize_t. These interfaces
did not, at the time, require the programmer to include
<sys/types.h> or <stddef.h> in order to use the interface, for
example in the SVID memory(BA_LIB) interface description, the
programmer had been instructed that only <string.h> was required
for the str* functions, and <memory.h> was required for the mem*
functions - but the SVID noted at that time that the latter was
deprecated - the pending ANSI C standard was to require only
<string.h>.
So, when the arguments of memcpy/strcpy were changed from int to
size_t, they couldn't go back and require existing code to include
e.g. <stddef.h> to get size_t; POSIX chose to note in the
interface description that additional typedefs may be visible
when <string.h> is included.
"The <string.h> header shall define NULL and size_t as described
in <stddef.h>."
On Mon, 05 May 2025 16:25:57 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
My impression was that Philipp Klaus Krause that posts here, if
infrequently, is a member of WG14.
Do you know if he is a member, or is he just an interested
participant?
He appears in the picture named "WG14 members attending the Strasbourg meeting in-person for the finalization of C23". To me that sounds as sufficient proof.
scott@slp53.sl.home (Scott Lurndal) writes:
After digging into the history, I have the impression that SVID
was hoping to be a leader in defining standard interfaces (which
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
Not in my own code. But I remember an old piece of code whose
author apparently thought that 'inline' is a perfect name for
input line. Few days ago I had trouble compiling with gcc-15
code which declares its own 'bool' type. The code is supposed to
compile using a wide range of compilers, so I am still looking
for "best" solution.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
I'm not Michael, but I was once mildly inconvienced because I
defined a logging function called log(). The solution was trivial:
I changed the name.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
After digging into the history, I have the impression that SVID
was hoping to be a leader in defining standard interfaces (which
SVID was AT&T's attempt to standardize unix interfaces. The last
edition (third) was released in 1989, but earlier versions date
to 1983.
As to who, exactly, first proposed size_t, that I don't recall.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
I'm not Michael, but I was once mildly inconvienced because I
defined a logging function called log(). The solution was trivial:
I changed the name.
Yes, I expect I have run into similar situations. What I was
wondering about were problems where either the existence of
the problem or what to do to fix it needed more than a minimal
effort.
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required for
freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
Not in my own code. But I remember an old piece of code whose
author apparently thought that 'inline' is a perfect name for
input line.
Few days ago I had trouble compiling with gcc-15
code which declares its own 'bool' type. The code is supposed to
compile using a wide range of compilers, so I am still looking
for "best" solution.
I recall running into issues using variables named 'index'
when porting code to SVR4 when the BSD compatibility layer
was present.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 14 Apr 2025 01:24:49 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
about where they may or may not be used. Do you really have a
problem avoiding identifiers defined in this or that library
header, either for all headers or just those headers required
for freestanding implementations?
I don't know. In order to know I'd have to include all
standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
I'm not Michael, but I was once mildly inconvienced because I
defined a logging function called log(). The solution was
trivial: I changed the name.
Yes, I expect I have run into similar situations. What I was
wondering about were problems where either the existence of the
problem or what to do to fix it needed more than a minimal
effort.
I recall running into issues using variables named 'index'
when porting code to SVR4 when the BSD compatibility layer
was present.
https://man.freebsd.org/cgi/man.cgi?query=index&sektion=3