Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #383532 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-03-12 00:14 +0000 |
| Last post | 2024-03-12 06:15 +0000 |
| Articles | 9 on this page of 69 — 13 participants |
Back to article view | Back to comp.lang.c
Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 00:14 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 18:15 -0700
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 01:34 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 19:56 -0700
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 03:30 +0000
Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 10:23 -0700
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 14:31 -0700
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-14 23:59 +0000
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:01 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 17:11 -0700
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:33 +0000
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-15 09:15 +0100
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 17:15 -0700
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:34 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 19:19 -0700
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-15 03:17 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 20:44 -0700
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-15 09:22 +0100
Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 19:49 -0700
Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-12 01:33 -0400
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 06:14 +0000
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 06:21 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 07:44 +0000
Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-12 08:03 +0000
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-12 11:10 +0100
Re: Word For Today: “Uglification” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-12 17:46 +0300
Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 14:53 +0000
Re: Word For Today: “Uglification” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-12 18:09 +0300
Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 15:42 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 18:50 +0000
Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 22:29 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 16:00 -0700
Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-13 11:45 +0000
Re: Word For Today: “Uglification” Michael S <already5chosen@yahoo.com> - 2024-03-13 14:12 +0200
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:15 -0700
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 18:47 +0100
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 11:56 -0700
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 22:07 +0100
Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 16:40 +0100
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 15:48 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 09:03 -0700
Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-13 16:44 +0000
Re: Word For Today: “Uglification” Nick Bowler <nbowler@draconx.ca> - 2024-03-13 17:01 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 02:53 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 18:42 +0000
Re: Word For Today: “Uglification” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-12 22:07 +0000
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 23:13 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 16:29 -0700
Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-13 09:01 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:06 -0700
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 21:51 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 22:16 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 15:26 -0700
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-13 22:33 +0000
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 22:50 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 16:06 -0700
Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-13 23:32 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-14 00:40 +0000
Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-13 23:15 +0000
Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 23:09 -0700
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 00:23 +0000
Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-12 11:51 -0400
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 21:31 +0000
Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 15:21 -0700
Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-13 03:36 -0400
Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 21:52 +0000
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 22:10 +0000
Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-13 20:47 -0400
Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 06:15 +0000
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-13 00:23 +0000 |
| Message-ID | <20240312171612.767@kylheku.com> |
| In reply to | #383565 |
On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Tue, 12 Mar 2024 08:03:50 +0000, Richard Kettlewell wrote: > >> That’s true, but AFAICT it’s exactly what Lawrence is complaining about: >> there’s nothing in the language spec to help those thousand other >> libraries avoid name clashes. > > My specific complaint was about temporary names being used internal to > library macros. It’s a problem that is essentially impossible to solve > with string-based macro processors. Firstly, C preprocessing is not exactly "string based" but token based. A string or token based macro preprocessor could provide a way for macros to obtain and use generated symbols (gensyms): identifiers that are valid in the host language for variables and other uses, but are uniquely generated within the translation unit. Needless to say, the standard C preprocessing doesn't provide such a thing, which is a problem. But this issue independent of weaknesses caused by macro processing being token or character based. A structural macro preprocessor that doesn't provide gensyms or any equivalent form of hygiene would have the same problem. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-03-12 11:51 -0400 |
| Message-ID | <usptlp$c79g$1@dont-email.me> |
| In reply to | #383541 |
On 3/12/24 02:14, Lawrence D'Oliveiro wrote: ... > The problem I have with that is the singular form of “library”. In a > typical Linux distro, you could have thousands of libraries installed. > I just did this command on my Debian system: > > dpkg-query -l lib*dev | wc -l > > and the answer came back “1037”. The idea that a C-language > implementation and run-time environment is any sense monolithic seems > hopelessly out of touch. It was never monolithic, any more than talking about the United States implies that the United States is a monolithic entity. The standard allows an implementation to have many separate parts, by failing to prohibit such a structure - but everything it says about one is about the implementation as a whole, not the individual parts.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-12 21:31 +0000 |
| Message-ID | <usqhjg$gpvk$2@dont-email.me> |
| In reply to | #383552 |
On Tue, 12 Mar 2024 11:51:21 -0400, James Kuyper wrote: > ... everything it says about one is about > the implementation as a whole, not the individual parts. You don’t see the problem with trying avoid clashes between those parts?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-12 15:21 -0700 |
| Message-ID | <87h6hb851o.fsf@nosuchdomain.example.com> |
| In reply to | #383558 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 12 Mar 2024 11:51:21 -0400, James Kuyper wrote:
>> ... everything it says about one is about
>> the implementation as a whole, not the individual parts.
>
> You don’t see the problem with trying avoid clashes between those parts?
I think everyone is aware of the problem. Was that your point?
The standard reserves certain identifiers for use by the implementation.
The implementation includes the standard library described in section 7,
not to all the libraries that happen to be installed on a system; those
libraries, as far as the standard is concerned, are just user code.
Third-party libraries are, for example, not permitted to define
identifiers starting with two underscores, because those same
identifiers might be used by the standard library or by the compiler.
This is typically not enforced, but using such an identifier in code
that's not part of the standard library has undefined behavior. (I've
seen plenty of such identifiers in third-party code; it typically
doesn't cause a problem in practice unless there's an actual collision.)
If your point is that "name collisions are a problem", of course that's
true. Name collisions within the standard library are typically not a
problem. The standard library is typically provided either by a single
implementer or by a few implementers who are very careful to avoid
collisions.
C doesn't provide a namespace facility like C++'s, so implementers of
third-party libraries might use identifier prefixes or other tricks to
avoid collisions.
Again, have you actually seen name collision problems in the real world?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-03-13 03:36 -0400 |
| Message-ID | <usrl1b$r66p$1@dont-email.me> |
| In reply to | #383558 |
On 3/12/24 17:31, Lawrence D'Oliveiro wrote: > On Tue, 12 Mar 2024 11:51:21 -0400, James Kuyper wrote: > >> ... everything it says about one is about >> the implementation as a whole, not the individual parts. > > You don’t see the problem with trying avoid clashes between those parts? Yes, I do, and so do implementors. Avoiding those clashes is their responsibility. They are supposed to test their partial implementations with implementations of other parts of C, and document which combinations they claim qualify as conforming implementations of C. I'm not saying this is required by the C standard, but only by their general responsibility to produce a usable product. The C standard only governs things which claim to be conforming implementations of C. It cannot constrain things for which no such claim has been made. If you want to rely upon guarantees provided by the C standard, only use things which claim to meet its requirements. Therefore, your responsibility is to read the documentation of any partial implementations you put together, and only put together partial implementations for which such a claim has been made. Or, if you choose to mix and match partial implementations willy-nilly, own your choice and don't complain about the results.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-13 21:52 +0000 |
| Message-ID | <ust76r$15mv5$4@dont-email.me> |
| In reply to | #383572 |
On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote: > Yes, I do, and so do implementors. Avoiding those clashes is their > responsibility. Implementors of the C standard? What about providers of other libraries?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-13 22:10 +0000 |
| Message-ID | <20240313150115.10@kylheku.com> |
| In reply to | #383594 |
On 2024-03-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote: > >> Yes, I do, and so do implementors. Avoiding those clashes is their >> responsibility. > > Implementors of the C standard? What about providers of other libraries? One possible point of view is that the integrators who put together a GNU/Linux distro effectively take on the role of C implementors. If a clash takes place among any libraries in Debian or Alpine or GNU Guix or what have you, you can regard that as a bug in the distro. The distro can fix it however they see fit: apply a local patch to one or more libraries, and get possibly get that upstreamed, or not. (It makes sense to get that upstreamed, because other distros are all building most of the same libraries; a clash between libraries can affect any distro the same way as any other.) In any case, the C standard doesn't distinguish any party other than implementor and user. Libraries that are not in the implementation are in the program being presented for translation and linkage, and clashes in the program are the program's problem. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-03-13 20:47 -0400 |
| Message-ID | <usthef$17uno$1@dont-email.me> |
| In reply to | #383594 |
On 3/13/24 17:52, Lawrence D'Oliveiro wrote: > On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote: > >> Yes, I do, and so do implementors. Avoiding those clashes is their >> responsibility. > > Implementors of the C standard? What about providers of other libraries? Avoiding conflicts is their responsibility, obviously. As a general rule, they do so by choosing a library-specific prefix to use on all identifiers that might otherwise cause problems.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-12 06:15 +0000 |
| Message-ID | <20240311231053.559@kylheku.com> |
| In reply to | #383532 |
On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> From /usr/include/«arch»/bits/select.h on my Debian system:
>
> #define __FD_ZERO(s) \
> do { \
> unsigned int __i; \
> fd_set *__arr = (s); \
> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
> __FDS_BITS (__arr)[__i] = 0; \
> } while (0)
>
> Note how this macro brings the entire expression for “s” into the
> scope containing those temporary “__i” and “__arr” variables. You just
> better hope they won’t clash.
>
> I think there is a clause in the C spec that says names beginning with
> underscores (“uglified” names, I think they’re called) are reserved
> for library implementors or something. But what happens if one library
> implementation depends on another? What keeps the choices of names
> from clashing in that situation? Just luck, I guess.
That doesn't happen. There is only one library that's part of the
language implementation, and those identifiers are reserved for that.
Any third party library that is not part of the implementation cannot
use these identifiers with the absolute certainty that they don't clash
with anything.
Standard C doesn't offer a solution for the problem of party library
writers needing private identifiers in their headers.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web