Discussion:
Double-underline-itis
BartC
2017-02-28 23:44:37 UTC
Raw Message
I came across this declaration in some Linux header:

extern int mbtowc (wchar_t *__restrict __pwc,
const char *__restrict __s, size_t __n) __THROW;

There are thousands just the same. I can understand the double-underline
prefix used for implementation names that may clash with those in the
user namespace.

But what's with the double-underline on the parameter names? They
shouldn't clash with anything. (And here, I assumed __pwc was yet
another attribute that the implementation thinks is needed.)

Sometimes, as well as the double-underline at the start, they need to
have one at the end too, such as '__restrict__' (what's wrong with just
'restrict', if you need to have it all?).

Underlines are hard to see and tend to run together so you can't tell
easily if there are two or three.

Since $isn't used much, what would have been wrong with that? It's not pretty but at least you can see it! -- bartc s***@casperkitty.com 2017-02-28 23:54:32 UTC Permalink Raw Message Post by BartC But what's with the double-underline on the parameter names? They shouldn't clash with anything. (And here, I assumed __pwc was yet another attribute that the implementation thinks is needed.) User code is allowed to declare macros with almost any names the user sees fit, and might do so prior to including standard headers. If user code started with #define fmt "(Quack! My favorite number is %d)" #include <stdio.h> and the definition for printf were int printf(char const *restrict fmt, ...); then compilation of the header would fail. Such constructs don't generally cause trouble, but I don't think they're conforming when they use non-reserved identifiers. Ben Bacarisse 2017-03-01 01:19:04 UTC Permalink Raw Message Post by BartC extern int mbtowc (wchar_t *__restrict __pwc, const char *__restrict __s, size_t __n) __THROW; There are thousands just the same. I can understand the double-underline prefix used for implementation names that may clash with those in the user namespace. But what's with the double-underline on the parameter names? They shouldn't clash with anything. That's why the underscores are there. Without them, the names could clash with user-defined macros. Post by BartC (And here, I assumed __pwc was yet another attribute that the implementation thinks is needed.) Why? I would assume it's just the parameter name unless I had strong evidence that it was not. Post by BartC Sometimes, as well as the double-underline at the start, they need to have one at the end too, such as '__restrict__' (what's wrong with just 'restrict', if you need to have it all?). __restrict__ can be #defined away when processing the header with a pre-1999 version of C. You can't do that with restrict because it's not a name reserved to the implementation. Obviously one could use different headers for different C versions, but this method is simple and effective. Post by BartC Underlines are hard to see and tend to run together so you can't tell easily if there are two or three. I don't have that problem. _, __ and ___ all look very different to me. Maybe it's the font I use -- there is a slight gap between consecutive underscores. Post by BartC Since$ isn't used much, what would have been wrong with that? It's
not pretty but at least you can see it!
--
Ben.
David Brown
2017-03-01 08:11:51 UTC
Raw Message
Post by Ben Bacarisse
Post by BartC
extern int mbtowc (wchar_t *__restrict __pwc,
const char *__restrict __s, size_t __n) __THROW;
There are thousands just the same. I can understand the
double-underline prefix used for implementation names that may clash
with those in the user namespace.
But what's with the double-underline on the parameter names? They
shouldn't clash with anything.
That's why the underscores are there. Without them, the names could
clash with user-defined macros.
Post by BartC
(And here, I assumed __pwc was yet
another attribute that the implementation thinks is needed.)
Why? I would assume it's just the parameter name unless I had strong
evidence that it was not.
Post by BartC
Sometimes, as well as the double-underline at the start, they need to
have one at the end too, such as '__restrict__' (what's wrong with
just 'restrict', if you need to have it all?).
__restrict__ can be #defined away when processing the header with a
pre-1999 version of C. You can't do that with restrict because it's not
a name reserved to the implementation. Obviously one could use
different headers for different C versions, but this method is simple
and effective.
There is also the opposite effect. "restrict" can be #defined to
anything you want in pre-C99 or C++, so if the header used "restrict" it
would not work in pre-C99 modes, or C++ modes. But gcc (and probably
clang, and maybe other compilers) allows restricted pointers in C++ mode
and other C modes, using "__restrict__" instead of "restrict". So by
using "__restrict__" rather than "restrict", the header works for a
wider variety of compiler modes.

(Not that "restrict" in a function declaration does much other than
document the restriction, as has been discussed on another thread.)
Post by Ben Bacarisse
Post by BartC
Underlines are hard to see and tend to run together so you can't tell
easily if there are two or three.
I don't have that problem. _, __ and ___ all look very different to
me. Maybe it's the font I use -- there is a slight gap between
consecutive underscores.
Post by BartC
Since \$ isn't used much, what would have been wrong with that? It's
not pretty but at least you can see it!
BartC
2017-03-01 11:45:41 UTC
Raw Message
Post by Ben Bacarisse
Post by BartC
extern int mbtowc (wchar_t *__restrict __pwc,
const char *__restrict __s, size_t __n) __THROW;
There are thousands just the same. I can understand the
double-underline prefix used for implementation names that may clash
with those in the user namespace.
But what's with the double-underline on the parameter names? They
shouldn't clash with anything.
That's why the underscores are there. Without them, the names could
clash with user-defined macros.
Yes, that's what supercat said. But then, macros can cause all sorts of
mischief. Anyone producing a header file for a library, and wishing to
use parameter names in function declarations, would also be at risk of
having those names clashing with macros declared before the header.

What can do they do? Use __ prefixes too? That would partly defeat the
purpose of using parameter names to document their uses, and would
clutter up the code. And __ is probably reserved for the implementation,
so they could then clash with macros in the standard headers.
Post by Ben Bacarisse
Post by BartC
(And here, I assumed __pwc was yet
another attribute that the implementation thinks is needed.)
Why? I would assume it's just the parameter name unless I had strong
evidence that it was not.
(I was looking for what was causing my parsing of the declaration to
fail, I saw __pwc and declared that as another blank macro. As it turned
out, wchar_t wasn't defined some reason. Eventually I'll have my own
headers without any of these problems.

As it is, I have to painstakingly scan along looking for commas before I
can even see how many parameters there are. Written in a saner manner:

extern int mbtowc (wchar_t dest, char* source, size_t n);

Ah! Now it's obvious, even with those ugly "_t" suffixes; it presumably
copies source to dest converting UTF8 or whatever to a wide-character
array. Only the exactly meaning of n is unclear, but I would assume it's
the maximum capacity of dest.
Post by Ben Bacarisse
Post by BartC
Sometimes, as well as the double-underline at the start, they need to
have one at the end too, such as '__restrict__' (what's wrong with
just 'restrict', if you need to have it all?).
__restrict__ can be #defined away when processing the header with a
pre-1999 version of C. You can't do that with restrict because it's not
a name reserved to the implementation. Obviously one could use
different headers for different C versions, but this method is simple
and effective.
You mean that

#define restrict

won't work because someone could have....

I don't even understand the problem. These are system headers, designed
to work with a particular implementation, so will know whether
'restrict' is supported or not. What's the point of such a keyword being
introduced if it then goes onto use something else?

Or do the headers know the implementation doesn't recognise restrict?
That's hard to believe because my set of gcc headers use __restrict too.

(And they seem to favour a single underline for parameter names. So a
sort of primitive unary counting system:

abc 0, user identifier
___abc 3, reserved, or system identifier _abc with __ prefix?
__abc__ ? I give up!)
Post by Ben Bacarisse
Post by BartC
Underlines are hard to see and tend to run together so you can't tell
easily if there are two or three.
I don't have that problem. _, __ and ___ all look very different to
me. Maybe it's the font I use -- there is a slight gap between
consecutive underscores.
In my own editor, in Notepad, in SciTe, in the C highlighting of both
Pastebin and Github, and in my Thunderbird newsreader, underlines run
together. Only with a couple of things I tried in Ubuntu was there a
miniscule gap of what looked to be one pixel.

(Actually, that might also be the case in Windows; if I magnify the
screen pixels, then I can see a slight greyish discontinuity between the
_ characters. Probably an effect of character smoothing. But they still
look like they run together.)

--
___bart_c
Ben Bacarisse
2017-03-01 12:30:41 UTC
Raw Message
Post by BartC
Post by Ben Bacarisse
Post by BartC
extern int mbtowc (wchar_t *__restrict __pwc,
const char *__restrict __s, size_t __n) __THROW;
There are thousands just the same. I can understand the
double-underline prefix used for implementation names that may clash
with those in the user namespace.
But what's with the double-underline on the parameter names? They
shouldn't clash with anything.
That's why the underscores are there. Without them, the names could
clash with user-defined macros.
Yes, that's what supercat said. But then, macros can cause all sorts
of mischief. Anyone producing a header file for a library, and wishing
to use parameter names in function declarations, would also be at risk
of having those names clashing with macros declared before the header.
I'm not sure what your point is. You asked a question and I tried to
answer it (in fact I'd say I did answer it). Are you saying that system
might not bother?
Post by BartC
What can do they do?
They should either not use names in the header or document the names
used so annt one #defining one of them prior to including the header
will know what's gone wrong.

<snip>
Post by BartC
Post by Ben Bacarisse
Post by BartC
Sometimes, as well as the double-underline at the start, they need to
have one at the end too, such as '__restrict__' (what's wrong with
just 'restrict', if you need to have it all?).
__restrict__ can be #defined away when processing the header with a
pre-1999 version of C. You can't do that with restrict because it's not
a name reserved to the implementation. Obviously one could use
different headers for different C versions, but this method is simple
and effective.
You mean that
#define restrict
won't work because someone could have....
I don't even understand the problem. These are system headers,
designed to work with a particular implementation, so will know
whether 'restrict' is supported or not. What's the point of such a
keyword being introduced if it then goes onto use something else?
Many implementations support various C standards. As I said, you could
include a different header for C90, C99 and so on but it's easier to
#define __restrict__ to either nothing or restrict depending on the
language version.

<snip>
--
Ben.
BartC
2017-03-01 13:04:28 UTC
Raw Message
Post by Ben Bacarisse
Post by BartC
You mean that
#define restrict
won't work because someone could have....
I don't even understand the problem. These are system headers,
designed to work with a particular implementation, so will know
whether 'restrict' is supported or not. What's the point of such a
keyword being introduced if it then goes onto use something else?
Many implementations support various C standards. As I said, you could
include a different header for C90, C99 and so on but it's easier to
#define __restrict__ to either nothing or restrict depending on the
language version.
I've just come across __signed__! How many C systems don't support 'signed'?

typedef __signed__ char __s8;
typedef unsigned char __u8;

Is this so __signed__ could be defined as 'unsigned' according to some
compiler option? That seems unlikely when you declaring distinct s8 and
u8 types.

(In a file from a Linux set of includes, one of various assorted headers
that get loaded even when just using a handful of standard headers in
the user-code. include\asm-generic\int-ll64.h

This was just after I had to 'remove' one time.h because it didn't
define clock(). But there were 4 other time.h files in sub-directories,
so no worries!

What a mess these system headers are. I hadn't realised they were so
Heath Robinson, looking like a bunch of hacks put together to meet some

Anyway these headers do seem to rely heavily on the use of "__" prefixes
absolutely everywhere. And, for some reason that I'm not sure has been
explained yet, on "__" suffixes.)
--
Bartc
Ben Bacarisse
2017-03-01 15:29:30 UTC
Raw Message
Post by BartC
Post by Ben Bacarisse
Post by BartC
You mean that
#define restrict
won't work because someone could have....
I don't even understand the problem. These are system headers,
designed to work with a particular implementation, so will know
whether 'restrict' is supported or not. What's the point of such a
keyword being introduced if it then goes onto use something else?
Many implementations support various C standards. As I said, you could
include a different header for C90, C99 and so on but it's easier to
#define __restrict__ to either nothing or restrict depending on the
language version.
I've just come across __signed__! How many C systems don't support 'signed'?
Why do you assume is about support? My first reaction when I see
something like this that I don't understand is that it's probably a my
fault. Yes, there is often junk in these files but there is often stuff
I can't be sure about because it's solving a problem I've not yet
grasped.

<snip>
--
Ben.
Kenny McCormack
2017-03-01 15:47:27 UTC
Raw Message
In article <***@bsb.me.uk>,
Ben Bacarisse <***@bsb.me.uk> wrote:
...
Post by Ben Bacarisse
Why do you assume is about support? My first reaction when I see
something like this that I don't understand is that it's probably a my
fault. Yes, there is often junk in these files but there is often stuff
I can't be sure about because it's solving a problem I've not yet
grasped.
Given your situation in life, I think that's a very reasonable position for
you to take. Man's got to know his limitations...!
--
"The party of Lincoln has become the party of John Wilkes Booth."

- Carlos Alazraqui -
Keith Thompson
2017-03-01 17:30:23 UTC
Raw Message
BartC <***@freeuk.com> writes:
[...]
Post by BartC
I've just come across __signed__! How many C systems don't support 'signed'?
typedef __signed__ char __s8;
typedef unsigned char __u8;
[...]

The "signed" keyword and the signed char type were, IIRC, introduced
by ANSI C in 1989. A header designed to work with both pre-ANSI
and ANSI C would have to have some way of dealing with that. And
since the header still works even with C11 (as long as __signed__
is defined properly), there's not much motivation to fix it --
unless you wrongly assume that headers are intended as end user
documentation.

The use of __s8 and __u8, rather than the standard int8_t and
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
s***@casperkitty.com
2017-03-01 18:14:52 UTC
Raw Message
Post by Keith Thompson
[...]
Post by BartC
I've just come across __signed__! How many C systems don't support 'signed'?
typedef __signed__ char __s8;
typedef unsigned char __u8;
[...]
The "signed" keyword and the signed char type were, IIRC, introduced
by ANSI C in 1989. A header designed to work with both pre-ANSI
and ANSI C would have to have some way of dealing with that. And
since the header still works even with C11 (as long as __signed__
is defined properly), there's not much motivation to fix it --
unless you wrongly assume that headers are intended as end user
documentation.
The use of __s8 and __u8, rather than the standard int8_t and
Client code written for systems where "char" is signed might expect
that a function expecting a const pointer to an array of 8-bit signed
values would accept a pointer to a string literal. Even systems where
"char" is signed, however, will not allow implicit conversions from
string literals to "signed char const *".

I think the Standard should have allowed implementations to, at their
option, treat as identical, types which have precisely-matching
representations and semantics. Treating "char" and "signed char" identically
in such cases would make some implementations simpler, and would not affect
the meaning of any program upon which the Standard would impose any
requirements. While some kinds of type incompatibility would be indicative
of possible logic problems (e.g. between an unsigned "char" type and a
"signed char" type), I see no reason to expect that would be true in cases
where the involved types have identical representations and are treated
identically in every way (including aliasing).
Tim Rentsch
2017-04-17 01:45:31 UTC
Raw Message
Post by Keith Thompson
[...]
I've just come across __signed__! How many C systems don't
support 'signed'?
typedef __signed__ char __s8;
typedef unsigned char __u8;
[...]
The "signed" keyword and the signed char type were, IIRC, introduced
by ANSI C in 1989. A header designed to work with both pre-ANSI
and ANSI C would have to have some way of dealing with that. And
since the header still works even with C11 (as long as __signed__
is defined properly), there's not much motivation to fix it --
unless you wrongly assume that headers are intended as end user
documentation.
The use of __s8 and __u8, rather than the standard int8_t and
It probably is from an old header, but using __s8 and __u8 (as
opposed to int8_t and uint8_t) doesn't necessarily imply that.
The __u8 and __s8 types, as typedef'ed above, are more widely
applicable than the [u]int8_t types, for a variety of reasons.
Presumably someone concerned with maximizing portability
would be aware of such concerns.

TickleMe Elmo
2017-03-01 07:30:39 UTC
Raw Message
Facts about Steve "Steven Petruzzellis" Carroll

Steve "Steven Petruzzellis" Carroll is a nearly 60 year old guy who is single, broke and has no skills. He blames Snit for his loss of his wife and girlfriend. Steven is jealous of what Snit has and in a narcissistic rage repeatedly works to take it away from him. For over 10 years he has failed at even this. Steve "Steven Petruzzellis" Carroll is an utter failure in life.

Of his online life Steven says

I've been booted off by past providers before because people
complain about me and all my bullshit. I don't want to lose my ISP
*again* but I still need my army of sock puppets so I continually
search usenet for whatever servers I haven't yet been booted
from.

Some examples where Steven has been booted

X10 Hosting booted Steven for inappropriate activity
http://tinyurl.com/z92qmz4

Comcast booted Steven for inappropriate activity
http://tinyurl.com/h75nh9l

FreeHostingEU booted Steven for copyright infringement http://devsite.eu.pn

http://demsites.atwebpages.com/pokeman

Had a GigaNews account which was removed for harassing Snit

Stopped posting from his fretwizzen Google account since shortly after I complained. Seems he lost that too.

His wife booted Steven to the curb for cheating on her

Only site Steven Petruzzellis has pointed to that has ever been available
http://www.oldneighborhoodrestaurant.net
http://tinyurl.com/zgby6mp

Made by the Go Daddy Website builder and is utter crap. Later he denied he said he was merely taking credit for someone else's work but Steven is the contact person http://tinyurl.com/hcw6dul http://tinyurl.com/hc7ee9q

He also bragged he was working on an update and showed it here https://vid.me/u6RK

He likely went to the Go Daddy Website Builder after he failed to get WordPress installed.

https://mu.wordpress.org/forums/topic/13879

This is why Steve "Steven Petruzzellis" Carroll attacks Snit.

Steven Petruzzellis was is divorced because his wife caught him screwing another woman.

Snit is married and by all appearances happily so.
He never complains about his wife in COLA.

Steven Petruzzellis is living on charity of a friend in a single room.

Snit does not live in a mansion or even a high end home but has a house and a yard.

Steven Petruzzellis has two kids but no respect. He repeatedly called Ryan his "little screwup" and refers to his son Steve as a "dick" and worse. He says at least one of them likely hacked his computer and is a "mentally deficient child." He mocks his possible future daughter-in-law as someone who takes too many selfies and is focused only on herself

Snit has two kids (or more) and never speaks poorly of them in public.
No reason to think they are not a happy family.

Steven Petruzzellis claims to be a stay at home dad who pays thousands of dollars for day care. Steven has no job and no purpose in life. Steven has given up and now seeks a mother-figure to date.

Snit has his own business doing technical work and also teaches.
Snit offers a true contribution to society.
Teachers are truly under appreciated.

Top Six Ways Snit Trolls