From: peter (Peter da Silva)
Date: 12:41 on 20 Aug 2004
Subject: GCC
Condemned from their own mouths:
5.7 Conditionals with Omitted Operands
The middle operand in a conditional expression may be omitted.
Then if the first operand is nonzero, its value is the value of
the conditional expression.
Therefore, the expression
x ? : y
has the value of x if that is nonzero; otherwise, the value of y.
This example is perfectly equivalent to
x ? x : y
In this simple case, the ability to omit the middle operand is not
especially useful. When it becomes useful is when the first operand
does, or may (if it is a macro argument), contain a side effect.
Then repeating the operand in the middle would perform the side
effect twice. Omitting the middle operand uses the value already
computed without the undesirable effects of recomputing it.
Yes, it's useful. It is NOT, however, C. This kind of thing should require
compilation with "--butthead-extensions" and several embarassing "#pragma"
lines to make sure that it's NEVER used by anyone who isn't completely
aware they're being a wanker.
From: Jarkko Hietaniemi Date: 21:14 on 22 Aug 2004 Subject: Re: GCC > > Yes, it's useful. It is NOT, however, C. This kind of thing should require > compilation with "--butthead-extensions" and several embarassing "#pragma" > lines to make sure that it's NEVER used by anyone who isn't completely > aware they're being a wanker. gcc is full of those. Some people actually think gcc -Wall will protect them from unportabilities.
From: Zack Weinberg Date: 21:32 on 22 Aug 2004 Subject: Re: GCC Jarkko Hietaniemi <jhi@xxx.xx> writes: >> Yes, it's useful. It is NOT, however, C. This kind of thing should >> require compilation with "--butthead-extensions" and several >> embarassing "#pragma" lines to make sure that it's NEVER used by >> anyone who isn't completely aware they're being a wanker. > > gcc is full of those. Some people actually think gcc -Wall will > protect them from unportabilities. Neither I nor any of the other GCC people who care about portable code are likely to fix this, because buttheaded documentation licenses that discourage people from improving the documentation are worse than buttheaded documentation. However, a rewrite of the user manual so that it doesn't describe all the stupid extensions as the best thing since sliced bread *will* be accepted. I guaron-tee it. zw
From: Phil Pennock Date: 09:10 on 23 Aug 2004 Subject: Re: GCC On 2004-08-22 at 23:14 +0300, Jarkko Hietaniemi wrote: > gcc is full of those. Some people actually think gcc -Wall will protect > them from unportabilities. For portability checks, I've been using -Wall -pedantic and maybe -ansi; is this not enough? -Phil
From: Simon Cozens Date: 13:26 on 23 Aug 2004 Subject: Re: GCC Phil Pennock: > For portability checks, I've been using -Wall -pedantic and maybe -ansi; > is this not enough? No. Because, of course, -Wall doesn't mean what it says. Further gcc hate there. Perl uses gcc -g -O -pedantic -Wall -W -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wno-long-long
From: Peter Pentchev
Date: 16:01 on 23 Aug 2004
Subject: Re: GCC
--ABTtc+pdwF7KHXCz
Content-Type: text/plain; charset=windows-1251
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 23, 2004 at 01:26:09PM +0100, Simon Cozens wrote:
> Phil Pennock:
> > For portability checks, I've been using -Wall -pedantic and maybe -ansi;
> > is this not enough?
>=20
> No. Because, of course, -Wall doesn't mean what it says. Further gcc hate
> there.
>=20
> Perl uses gcc -g -O -pedantic -Wall -W -Wshadow -Wpointer-arith
> -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wno-long-long
And FreeBSD's make.conf sample has the following:
# BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested
# for use in developing FreeBSD and testing changes. They can be used by
# putting "CFLAGS+=3D${BDECFLAGS}" in /etc/make.conf. -Wconversion is not
# included here due to compiler bugs, e.g., mkdir()'s mode_t argument.
#
BDECFLAGS=3D -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \
-Wcast-qual -Wchar-subscripts -Winline \
-Wmissing-prototypes -Wnested-externs -Wpointer-arith \
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings
G'luck,
Peter
--=20
Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence contains exactly threee erors.
--ABTtc+pdwF7KHXCz
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (FreeBSD)
iD8DBQFBKgbI7Ri2jRYZRVMRAtyFAKC1tMqyvQzZ8uPnceJqS791czyD8ACfUI2T
G4oHJI+uNxf7jJhz8p/uaTc=
=JVj+
-----END PGP SIGNATURE-----
--ABTtc+pdwF7KHXCz--
From: peter (Peter da Silva) Date: 16:53 on 23 Aug 2004 Subject: Re: GCC So, do all these flags really turn off the "expression ?: expression" kludge? [Secondary hate, mail clients that pay attention to charset interacting with mail clients that take the golden rule to an absurd level by ignoring charset on input and selecting some weird platform-specific charset on output. Why would an application on an OS that has Unicode built in to it at a low level send messages in Windows-1251 or whatever?]
From: Daniel Pittman
Date: 04:55 on 24 Aug 2004
Subject: Re: GCC
On 24 Aug 2004, Peter da Silva wrote:
> So, do all these flags really turn off the "expression ?: expression" kludge?
>
> [Secondary hate, mail clients that pay attention to charset
> interacting with mail clients that take the golden rule to an absurd
> level by ignoring charset on input and selecting some weird
> platform-specific charset on output. Why would an application on an OS
> that has Unicode built in to it at a low level send messages in
> Windows-1251 or whatever?]
I worked with that particular level of that OS, and their Unicode
"support" is a matter of hate in itself.
Aside from their insistence on having two byte-orderings for wide
characters, and their recommendation to implement the "byte order mark"
because, well, they were going to do so anyway and the rest of the world
better keep up...
...They have the Unicode specific functions available on all their
platforms, including Win31 derivatives from Win98 up, as well as the
"ANSI" versions which use an encoding like ISO-8859-* or Win1251
(because they needed the extra code points, and the rest of the world
better keep up...)
When you build your code you can either call the specific charset
version as 'MySillyNameEx2A' or 'MySillyNameEx2W', or you can use the
"unqualified" name and get the 'W' version of use specify -DUNICODE to
the compiler, or the 'A' version otherwise.
If you use a 'W' version explicitly, though, your code will never run on
Windows 95, which was a key consideration for many years, because the
exported API didn't include them, even if NT did.
If you use them on Win98 those API slots are present, so you can compile
with '-DUNICODE' and have it load on Win98 *and* WinNT.
You better not expect it to run, though. They implemented *four* 'W' API
calls -- convert this from 'W' encoding and convert this to 'W'
encoding, and IIRC, UTF8 equivalents or something similar to that.
Everything else would return an error code indicating 'NOT IMPLEMENTED'.
So, supporting Unicode means you chose between (a) NT only, (b) writing
your own wrappers that detect the platform and handle conversions to and
from Unicode at *every* API call, or (c) just pretend that Unicode
doesn't exist, except if you *have* to convert right at the edges of
your code.
Writing those wrappers, for reference, involves around 800 API calls for
a modest application, and there was *no* way that I could find of doing
it automatically without a full blown C and C++ parser.
This is, in part, because using a 'W' function routinely takes a
different C structure than the 'A' version, to account for the wider
string types stored in it.
While XP is fairly sucky in and of itself, it represents a huge step
forward in the world, because it will eventually be the death of the
Win31 derived OS branch, which is only a good thing for us all.
Daniel
PS: It also bothers me slightly that I still have this much hate after
getting out of the Windows game some ... six years ago now, I think.
From: Peter Pentchev Date: 12:36 on 24 Aug 2004 Subject: Re: GCC --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 10:53:56AM -0500, Peter da Silva wrote: > So, do all these flags really turn off the "expression ?: expression" klu= dge? Not quite: gcc -pedantic outputs a warning, and of course, adding -Werror would treat this as a fatal error. However, there is no way that I can see of making gcc treat this particular construct as an error without a blanket -Werror. > [Secondary hate, mail clients that pay attention to charset interacting > with mail clients that take the golden rule to an absurd level by > ignoring charset on input and selecting some weird platform-specific > charset on output. Why would an application on an OS that has Unicode > built in to it at a low level send messages in Windows-1251 or whatever?] I'm not sure what exactly you are implying here - or which particular mail client / message is your hate targeted at. However, if it is my previous message (and consequently this one too), it's not the fault of the Redmond OS, but rather of the dreadful lack of standardization of Cyrillic character sets. This is worthy of a hate rant itself, but I'll sketch it here. This particular character set is now the de facto standard for Cyrillic communications (maybe outside Russia and Ukraine, some of which still stick to koi8-r and koi8-u). In the past couple of years, I've seen web browsers and e-mail clients use all kinds of wacky names for it - just 1251, cp1251, window-1251, win-1251, microsoft-1251 cyrillic-1251, cyr1251, and all their variations with capitalization and with/without a dash between the word and the number. IMHO, CP1251 or cp1251 sounds best, but unfortunately, there seems to have been a convergence at some point and now the majority of MIME clients like windows-1251 better. I've been toying for some time with the idea of hacking up a minimal charset detector, which reads a piece of text and determines whether it should really be marked up as windows-1251 or us-ascii will be enough. If someone knows of something that already does this and can be easily hooked into Mutt, please holler. Until then, I'm afraid that since my e-mail communication is pretty much equally split between messages in Bulgarian and English, windows-1251 it is. G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBKyhE7Ri2jRYZRVMRAoOIAJ9M6V6O9FZZOX75zb+XGWYHQFUdxwCeJ694 UBXCd4+W7LSAAcLvOW+hF5Q= =BimV -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt--
From: Aaron Crane Date: 11:59 on 24 Aug 2004 Subject: Re: GCC Peter Pentchev writes: > Not quite: gcc -pedantic outputs a warning, and of course, adding > -Werror would treat this as a fatal error. However, there is no way > that I can see of making gcc treat this particular construct as an error > without a blanket -Werror. -pedantic tells gcc to issue all diagnostics required by the standard; -pedantic-errors makes those diagnostics fatal errors. This still isn't enough to find all uses of extensions, because not all uses of extensions have diagnostics required by the standard. But it's better than nothing. > I've been toying for some time with the idea of hacking up a minimal > charset detector, which reads a piece of text and determines whether it > should really be marked up as windows-1251 or us-ascii will be enough. > If someone knows of something that already does this and can be easily > hooked into Mutt, please holler. As I understand it, putting this in your .muttrc should work: set send_charset=us-ascii:windows-1251:utf-8
From: Peter Pentchev Date: 14:14 on 24 Aug 2004 Subject: Re: GCC --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 24, 2004 at 11:59:48AM +0100, Aaron Crane wrote: > Peter Pentchev writes: [snip] > > I've been toying for some time with the idea of hacking up a minimal > > charset detector, which reads a piece of text and determines whether it > > should really be marked up as windows-1251 or us-ascii will be enough. > > If someone knows of something that already does this and can be easily > > hooked into Mutt, please holler. >=20 > As I understand it, putting this in your .muttrc should work: >=20 > set send_charset=3Dus-ascii:windows-1251:utf-8 Ah... but of course! Score one more for actually reading the docs.. I wonder how long ago *that* appeared - or was it there four years ago, when I first started using Mutt, and did I just miss it? :) Anyway, thanks a lot! G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBKz887Ri2jRYZRVMRAtsNAKCqgCd6j94rdv7h2lXHtJ4I2x48UgCff/a7 ioDCn/5SFvFvETrjTcxU71Q= =q5Hc -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs--
From: peter (Peter da Silva) Date: 12:59 on 24 Aug 2004 Subject: Re: GCC > I'm not sure what exactly you are implying here - or which particular > mail client / message is your hate targeted at. Two categories of clients, I guess. First, all the spawn-of-redmond ones that used Windows-1251 instead of ISO-8859.5. Second, Mutt, for not being able to distinguish between messages that only use code points below 128 and those that have to be explicitly tagged with a charset, even if it can't use UTF-8. Oh, and for spawn-of-redmond for doing such a crappy job of Unicode support that Windows apps find it easier not to bother.
From: Peter Pentchev Date: 13:20 on 24 Aug 2004 Subject: Re: GCC --/GPgYEyhnw15BExa Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 24, 2004 at 06:59:25AM -0500, Peter da Silva wrote: > > I'm not sure what exactly you are implying here - or which particular > > mail client / message is your hate targeted at. >=20 > Two categories of clients, I guess. First, all the spawn-of-redmond > ones that used Windows-1251 instead of ISO-8859.5. Yes, it looks like we are in violent agreement here. Unfortunately, as I said before, for the present we will have to live with this :( > Second, Mutt, for not being able to distinguish between messages that > only use code points below 128 and those that have to be explicitly > tagged with a charset, Yeah, what I said about the minimal charset detector :( =09 > even if it can't use UTF-8. Well, Mutt itself can, but some of the people that I keep in touch with still use mail readers that can't. And yes, I know that the Right Thing(tm) would be to drag them kicking and screaming into the Century of the Fruitbat, but still... > Oh, and for spawn-of-redmond for doing such a crappy job of Unicode > support that Windows apps find it easier not to bother. I can second that, too - the whole *A/*W() mess made me not bother in the past years when I had to deal with this, too. G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. --/GPgYEyhnw15BExa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBKzJ67Ri2jRYZRVMRAvLRAJ4ugQ90MwuuKauBfYspmNgiQ+r3oQCfaBzG 1dXHXg7/iDtKGJYWgr/iTus= =pwOH -----END PGP SIGNATURE----- --/GPgYEyhnw15BExa--
Generated at 10:27 on 16 Apr 2008 by mariachi