S
Spiros Bousbouras
I completely agree. I hope we won't be seeing
recurring flame wars around the issue as it was
happening with Frederick Gotham for a while.
I completely agree. I hope we won't be seeing
recurring flame wars around the issue as it was
happening with Frederick Gotham for a while.
C
Chris H
In message
I would agree however it depends on the reaction of the person being
told that they are in a minority of 2 in a sample size of several
100,000.
Do compilers still accept char unsigned? Some used to but I bet many
don't now and Tomas does say he is trying to write fully portable code.
I would agree however it depends on the reaction of the person being
told that they are in a minority of 2 in a sample size of several
100,000.
Do compilers still accept char unsigned? Some used to but I bet many
don't now and Tomas does say he is trying to write fully portable code.
H
Harald van Dijk
Yes. You've been informed it's allowed in standard C already, but I've
tried six different compilers and none even issue any diagnostic for it by
default.
S
Spiros Bousbouras
But he wasn't told that , he was told that it's
ridiculous. Such a statistic is interesting although
I would imagine you're just guessing.
I just tried compiling
int main(void) {
char unsigned c ;
return 0 ;
}
with 2 different versions of gcc, 2 different versions
of Sun Studio 12 C compiler and splint. I got some
warnings about the unused variable but that's all.
Why would a compiler not compile something which
exists in both C standards ? If anything I would imagine
it makes the implementation more complex if one tries
to enforce a specific order between char and unsigned.
C
Chris H
Which is irrelevant. C99 is significant in not having been fully
implemented by any compilers bar 1 or 2 in the last decade. Just
because it is in the standard has no relevance on people implementing
it. Especially as no one is likely to use it.
Fair enough.... it's just one of those things I have never tried in the
last 20 years.
C
Chris H
In message
Well it could be argued that it is. Being in the standard does not make
it not-ridiculous by default. However it could have been put in a
better way.
Total guess. How many C programmers are there? Get to see a lot and
this is the only time I have seen it used in over a decade. (Even then
it was in some obsolete code.
Some one else has tried it on 6 compilers. And it seems to work.
Why should it? There is no requirement anywhere (afaik) to have a fully
comforting compiler. The current C standard is infamous in its non-
implementation.
If all the world does something one way why should a compiler writer
bother with a different and practically speaking obsolete syntax?
I would have thought if tokens are always in a set order it is easier to
parse.
Well it could be argued that it is. Being in the standard does not make
it not-ridiculous by default. However it could have been put in a
better way.
Total guess. How many C programmers are there? Get to see a lot and
this is the only time I have seen it used in over a decade. (Even then
it was in some obsolete code.
Some one else has tried it on 6 compilers. And it seems to work.
Why should it? There is no requirement anywhere (afaik) to have a fully
comforting compiler. The current C standard is infamous in its non-
implementation.
If all the world does something one way why should a compiler writer
bother with a different and practically speaking obsolete syntax?
I would have thought if tokens are always in a set order it is easier to
parse.
T
Tomás Ó hÉilidhe
Imagine you're writing a program that has commandline options, e.g.:
prog.exe -t -e -f
Now imagine the code you'd have in main for it. You might have some
sort of switch statement to check whether the command line option is
't' or 'e'. If you were to impose a strict order on the commadline
options, then you'd have to keep some sort of list of what previous
command line options appeared and in what order. Sounds like a useless
and inefficient restriction to me.
T
Tomás Ó hÉilidhe
Thanks Spiros, at least one person other than myself understands the
implications of labelling someone else's way of programming as
ridiculous, especially when the differing way makes negligible impact
on the code, and zero impact on the assembler produced.
Keith Thompson and Jack Klein have so far used the word "ridiculous".
Jack Klein has been hostile, arrogrant and caustic toward me already,
so I din't think there's much point in discussing him. As for Keith,
well he tends to be courteous mainly but then he seems to drop the
ball by going and calling other people's code "ridiculous" for no good
reason.
As for the the whole "char unsigned" versus "unsigned char" thing,
well I don't care to debate in anymore but it's such a ridiculously
stupid thing in my head. The very fact that Mr Klein even brought up
the issue makes me wonder what's going thru his head: I mean either
he's deliberatley being a prick (which I do suspect), or he actually
has some sort of mental difficulty in coming to terms with a simple re-
ordering of words.
Describing the re-ordering of words in "char unsigned" versus
"unsigned char" as trivial is an under-statement. I mean, really, I
can't think of anything more simple. It's even more simple than "++i
versus i++".
And given that it's such a stupidly ridiculous thing to even be
debating, I couldn't be bothered listening to incompetants tell me how
they have a stroke when their brain sees "char unsigned" instead of
"unsigned char". If anything your brain could do with the exercise in
variety.
F
fchang
I have a purely statisical comment with no value judgement whatsoever
(and notice that I only use the word "I" and "we" in the following message).
I just grepped several large code base that I happened to have unzipped
on my machine.
FreeBSD 7.0 kernel source code (7141 files totalling 123M)
"unsigned char" appeared 2089 times.
"char unsigned" never appeared
PostgreSQL 8.3.1 complete source code (3325 files totaling 81M).
"unsigned char" appeared 1301 times.
"char unsigned" never appeared
MySQL 5.1.22 complete source code (6754 files totaling 164M)
"unsigned char" appeared 1732 times.
"char unsigned" never appeared
QT 4.3.1 complete source code for XWindows (13204 files totaling 175M)
"unsigned char" appeared 1018 times.
"char unsigned" never appeared.
FFMpeg video encoder and decoder vesion 2007/10/4 (714 files, 14M)
"unsigned char" appeared 1083 times.
"char unsigned" never appeared.
FreeBSD and PostgreSQL and MySQL all have hundreds or more contributors
contributing over the last decade and more.
So the statistical evidence seems to suggest that "char unsigned" is rare.
And I strongly suspect that we will find the same result whether we
grep through Firefox source code, or OpenOffice,
or Linux, or XFree86, or Gnome, or KDE, and indeed probably
the majority of C and C++ code base out there.
Google for "unsigned char" (with the double quotes) and we get 3,350,000 hits.
Google for "char unsigned" and we get 161,000 hits,
and looking at the first 10 hits, we can assume that many of these are mis-hits
(First hit talks about "char, unsigned char, signed char functions"
Second hit is "keyword (char char) (unsigned-char char)"
Third hit is "char -> unsigned char: msg #0000"...)
H
Harald van Dijk
This is simpler than allowing options to appear in any order.
if (streq(*argv, "-t")) {
opt_t = true;
argv++;
}
if (streq(*argv, "-e")) {
opt_e = true;
argv++;
}
if (streq(*argv, "-f")) {
opt_f = true;
argv++;
}
E
Eligiusz Narutowicz
Harald van Dijk said:
I do not see how that is any simpler that a for loop with switch where
there is only one argv++.
K
Keith Thompson
Chris H said:
What do you mean when you say that the compiler "did it that way"?
Any conforming C compiler must accept either "unsigned char" or
"char unsigned". If you're referring to the coding style used
in the compiler itself, a compiler (assuming it's written in C)
is no more or less relevant than any other chunk of C code.
H
Harald van Dijk
True, you could easily convert it to
for (;
{if (streq(*argv, "-t")) {
opt_t = true;
argv++;
} else if (streq(*argv, "-e")) {
opt_e = true;
argv++;
} else if (streq(*argv, "-f")) {
opt_f = true;
argv++;
} else
break;
}
and change that to use switch or whatever method you want, but if you do
this, you no longer guard against -t -t, which was an error when the order
was forced, but would be silently accepted here. To fix that (assuming you
don't want to allow it -- with the original case of unsigned char, you
wouldn't) you need to add extra checks. This isn't difficult, but slightly
less simple than having a fixed order.
K
Keith Thompson
Tomás Ó hÉilidhe said:
I said that I find it ridiculous for a very simple reason: I do in
fact find it ridiculous. That's a personal esthetic judgement,
nothing more, nothing less. It was directed at the use of "char
unsigned", not at you personally.
Perhaps a better would for it is "counterintuitive".
I'll note that at least one person in this discussion, a member of the
C standard committee, was surprised to discover that "char unsigned"
is even legal, and that compilers will allow it.
Source code exists for two purposes. One is to be fed to a compiler
and translated into machine code (or something similar). For that
purpose, "unsigned char" and "char unsigned" are absolutely
equivalent, assuming a non-buggy compiler. The other purpose is to be
read by humans. We've seen in this thread that, for some humans,
"char unsigned" really is more difficult to read than the much more
common "unsigned char".
Consider this simple C program:
#include <stdio.h>
int main(int argc, char **argv)
{
int i;
printf("argc = %d\n", argc);
for (i = 0; i < argc; i ++) {
printf("argv[%d] = \"%s\"\n", i, argv);
if (i > 0 && argv[0] == '-') {
printf(" This appears to be an option specifier\n");
}
}
return 0;
}
Now consider a hypothetical C programmer who insists on indenting
backwards:
#include <stdio.h>
int main(int argc, char **argv)
{
int i;
printf("argc = %d\n", argc);
for (i = 0; i < argc; i ++) {
printf("argv[%d] = \"%s\"\n", i, argv);
if (i > 0 && argv[0] == '-') {
printf(" This appears to be an option specifier\n");
}
}
return 0;
}
I would call that "ridiculous", or at least "counterintuitive", and I
suspect you would as well.
Some of us see "char unsigned" as counterintuitive in much the same
way.
Your refusal to acknowledge that different people have different
intuititve ideas of what's clear and what isn't is a large part of
what's led to this flamefest. That, and the fact that you throw
around accusations of mental retardation, which is in extremely poor
taste.
Or he understands "char unsigned" perfectly well, but strongly
dislikes it. Why do you refuse to admit that possibility?
The same argument could be used to defend the reverse indentation
example above.
E
Eligiusz Narutowicz
Harald van Dijk said:True, you could easily convert it to
for (;
if (streq(*argv, "-t")) {
opt_t = true;
argv++;
} else if (streq(*argv, "-e")) {
opt_e = true;
argv++;
} else if (streq(*argv, "-f")) {
opt_f = true;
argv++;
} else
break;
}
No. You would take out the argv++ into the for loop.
No it isn't. I do not understand what you mean by -t -t being a problem
and how using if statements one after the other solves this. Last
occurrence rules.
S
Spiros Bousbouras
The point is that in C syntax
"unsigned char unsigned" is not allowed. So
the analogous situation with option processing
would be that you wouldn't want to allow for
example "-t -e -t".
I
Ian Collins
OpenSolaris core 18630 files
"unsigned char" appeared 10135 times.
"char unsigned" never appeared 0 times.
F
Flash Gordon
Tomás Ó hÉilidhe wrote, On 11/05/08 17:17:
You really do seem to want to insult the majority of programmers whether
they be professions or amateur, neophite or expert.
When was the last time you had to review a large code base? I'm sure I
asked the question before and explained why it is relevant. I generally
deal with comparatively small projects, only up to a hundred thousand
lines or so, and it does make a difference. Others here deal with
projects an order of magnitude or more larger. The last thing you need
when reviewing a large code base is differences from the expected
patterns making you have to think about the inconsequential instead of
the important.
You really do seem to want to insult the majority of programmers whether
they be professions or amateur, neophite or expert.
When was the last time you had to review a large code base? I'm sure I
asked the question before and explained why it is relevant. I generally
deal with comparatively small projects, only up to a hundred thousand
lines or so, and it does make a difference. Others here deal with
projects an order of magnitude or more larger. The last thing you need
when reviewing a large code base is differences from the expected
patterns making you have to think about the inconsequential instead of
the important.
B
Bart
char unsigned is nothing compared with the impossibly twisted type
declarations that don't seem to bother anyone here. Those really /are/
counterintuitive.
I see both of unsigned char/char unsigned as long-winded. All these
standard type combinations should be typedef-ed somewhere to result in
a series of short and sweet typenames that can be used throughout a
project. Then it really doesn't matter where the unsigned goes.
It's just a shame that these names are not standardised so they could
be used everywhere.
Examples:
void addstr(unsigned char *a, unsigned char *b, unsigned char *c)
void addstr(uchar *a, uchar *b, uchar *c)
void addstr(charu *a, charu *b, charu *c) /* Alternate */
To me the compact form is much more legible. Even better would be:
void addstr(uchar *a, *b, *c)
but apparently this is not allowed. (Those C99 guys could have spent
those 9 years coming up with something of genuine use and trivial to
implement.)
T
Tomás Ó hÉilidhe
Not to sound facetious, but I'd no problem reading that, I was
immediately able to see that the indentation was going leftwards
instead of rightwards. I actually found it bemusing how easily I was
able to read it (which I didn't think would be the case if someone
just said to me "We're gonna reverse the indentation").
I wrote some C tutorials a few years ago and I deliberately used all
sorts of different varieties so that the learner would get used to
seeing different things. For instance one minute I might have:
const signed i = 4;
And the next I might have
auto int const i = 5;
Of course, maybe nobody writes "signed" instead of "int" but I think
it's good to be exposed to variety.
I don't refuse that possibility. I definitely do think that Mr Klein
has an ulterior motive though in berrating "char unsigned", I mean
have you seen the tone in which he addresses me? It seems he spends
more effort being hostile toward me than he does in actually
furthering the discussion.
Perhaps it could, but then I think you'd have to take into account the
difference in people's minds when it comes to reordering of words
versus playing around with "leftwards and rightwards". I myself had no
problem with the reverse indentation but I don't know maybe other
people would. People's minds are set up differently, there's stuff
we're good at and stuff we're crap at. I'm crap at drawing for
instance; you should see the state of me trying to draw a horse.