#define with semicolon
cc
such as:
#define SMALL 1;
I didn't think it was, but a very good friend of mine claims it's
perfectly acceptable if you want to prevent the #define from being
used in an expression like if(SMALL).
Keith Thompson
Why would you want to prevent it from being used in an expression?
I think "1;" is a poor example of what your friend is talking about.
I'd be interested in seeing a better example.
A #define can contain any token sequence you like. The macro name
will be expanded to that token sequence every time you use it.
If you want that token sequence to include a semicolon, then you
should have a semicolon in the definition.
But most of the time, a macro expansion is used either in an
expression context (in which case it *shouldn't* have any semicolons,
and it should be protected by parentheses where necessary), or
in a statement context (in which case, if it consists of multiple
substatements, you need to use the "do { ... } while (0)" trick).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
cc
> cc <scatnu...@hotmail.com> writes:
> > Is it acceptable practice to have a #define with a semicolon in it,
> > such as:
>
> > #define SMALL 1;
>
> > I didn't think it was, but a very good friend of mine claims it's
> > perfectly acceptable if you want to prevent the #define from being
> > used in an expression like if(SMALL).
>
> Why would you want to prevent it from being used in an expression?
> I think "1;" is a poor example of what your friend is talking about.
> I'd be interested in seeing a better example.
That was his example. That was also his explanation of why he did it
(so the compiler would complain if he used it as an expression).
Another example was from the linux kernel.
/usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
#define LDO_MAX_VOLT 3300;
> A #define can contain any token sequence you like. The macro name
> will be expanded to that token sequence every time you use it.
> If you want that token sequence to include a semicolon, then you
> should have a semicolon in the definition.
I know what #define does. I was asking about coding standards more or
less, and if a #define with a semicolon was commonly used and accepted
practice.
> But most of the time, a macro expansion is used either in an
> expression context (in which case it *shouldn't* have any semicolons,
> and it should be protected by parentheses where necessary), or
> in a statement context (in which case, if it consists of multiple
> substatements, you need to use the "do { ... } while (0)" trick).
>
Right. So you see no logical reason to ever use something like #define
SMALL 1;? I don't either, but I was just making sure there wasn't
something I missed.
Ben Pfaff
> Is it acceptable practice to have a #define with a semicolon in it,
> such as:
>
> #define SMALL 1;
No, I'd assume that was a typo.
--
Ben Pfaff
http://benpfaff.org
Dr Nick
> On Jul 13, 3:38 pm, Keith Thompson <ks...@mib.org> wrote:
>> cc <scatnu...@hotmail.com> writes:
>> > Is it acceptable practice to have a #define with a semicolon in it,
>> > such as:
>>
>> > #define SMALL 1;
>>
>> > I didn't think it was, but a very good friend of mine claims it's
>> > perfectly acceptable if you want to prevent the #define from being
>> > used in an expression like if(SMALL).
>>
>> Why would you want to prevent it from being used in an expression?
>> I think "1;" is a poor example of what your friend is talking about.
>> I'd be interested in seeing a better example.
>
> That was his example. That was also his explanation of why he did it
> (so the compiler would complain if he used it as an expression).
>
> Another example was from the linux kernel.
>
> /usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
> #define LDO_MAX_VOLT 3300;
Flippin' heck. I hope I'm nowhere near the keyboard when anything the
kernal controls get close to that. Mainline or not.
>> A #define can contain any token sequence you like. The macro name
>> will be expanded to that token sequence every time you use it.
>> If you want that token sequence to include a semicolon, then you
>> should have a semicolon in the definition.
>
> I know what #define does. I was asking about coding standards more or
> less, and if a #define with a semicolon was commonly used and accepted
> practice.
>
>> But most of the time, a macro expansion is used either in an
>> expression context (in which case it *shouldn't* have any semicolons,
>> and it should be protected by parentheses where necessary), or
>> in a statement context (in which case, if it consists of multiple
>> substatements, you need to use the "do { ... } while (0)" trick).
>>
>
> Right. So you see no logical reason to ever use something like #define
> SMALL 1;? I don't either, but I was just making sure there wasn't
> something I missed.
I can't think of one.
I had a quick look through my source collection and the only example I
could find where I had a #define ending with a ; was one of those things
where you define a macro one way then include a file, then define it
another and include the file again.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Keith Thompson
> On Jul 13, 3:38 pm, Keith Thompson <ks...@mib.org> wrote:
>> cc <scatnu...@hotmail.com> writes:
>> > Is it acceptable practice to have a #define with a semicolon in it,
>> > such as:
>>
>> > #define SMALL 1;
>>
>> > I didn't think it was, but a very good friend of mine claims it's
>> > perfectly acceptable if you want to prevent the #define from being
>> > used in an expression like if(SMALL).
>>
>> Why would you want to prevent it from being used in an expression?
>> I think "1;" is a poor example of what your friend is talking about.
>> I'd be interested in seeing a better example.
>
> That was his example. That was also his explanation of why he did it
> (so the compiler would complain if he used it as an expression).
How else would he use it?
> Another example was from the linux kernel.
>
> /usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
> #define LDO_MAX_VOLT 3300;
I suspect that's just an error. Perhaps it's only used in contexts
where the extra semicolon is harmless, such as
voltage = LDO_MAX_VOLT;
which expands to
voltage = 3300;;
which is an assignment statement followed by an expression statement.
Or, worse, if it's used like this:
voltage = LDO_MAX_VOLT + 1;
then it expands to
voltage = 330; + 1;
where the "+ 1;" is an expression statement that discards the result
(and voltage gets the wrong value).
>> A #define can contain any token sequence you like. The macro name
>> will be expanded to that token sequence every time you use it.
>> If you want that token sequence to include a semicolon, then you
>> should have a semicolon in the definition.
>
> I know what #define does. I was asking about coding standards more or
> less, and if a #define with a semicolon was commonly used and accepted
> practice.
I'd say no. It's more commonly a mistake -- and if you're unlucky,
the compiler won't warn you about it.
>> But most of the time, a macro expansion is used either in an
>> expression context (in which case it *shouldn't* have any semicolons,
>> and it should be protected by parentheses where necessary), or
>> in a statement context (in which case, if it consists of multiple
>> substatements, you need to use the "do { ... } while (0)" trick).
>
> Right. So you see no logical reason to ever use something like #define
> SMALL 1;? I don't either, but I was just making sure there wasn't
> something I missed.
I won't say there's *never* a reason to do something like that.
There are cases where macros will expand to something other than
an expression or a statement. It usually means you're messing with
the language syntax, which is dangerous but *sometimes* useful.
Many years ago, I wrote something like:
#define EVER ;;
...
for (EVER) {
...
}
but I got better.
Harald van Dijk
> Right. So you see no logical reason to ever use something like #define
> SMALL 1;? I don't either, but I was just making sure there wasn't
> something I missed.
I do, though it does not apply to your case. There are lint-like tools
that allow you to declare that a macro expands to a statement. The
tool will verify that it is only ever used as a statement, but in
return, it has to actually *be* a statement, or it gets very confused.
A macro expansion that would be a statement if you add a semicolon
does not qualify.
Keith Thompson
From your description, it sounds like there are some bad lint-like
tools out there.
A macro that's intended to expand to a statement (and not to an
expression) should use the "do { ... } while (0)" trick to avoid
problems when used with if/else.
Harald van Dijk
> Harald van Dijk <true...@gmail.com> writes:
> > On Jul 13, 8:56 pm, cc <scatnu...@hotmail.com> wrote:
> >> Right. So you see no logical reason to ever use something like #define
> >> SMALL 1;? I don't either, but I was just making sure there wasn't
> >> something I missed.
>
> > I do, though it does not apply to your case. There are lint-like tools
> > that allow you to declare that a macro expands to a statement. The
> > tool will verify that it is only ever used as a statement, but in
> > return, it has to actually *be* a statement, or it gets very confused.
> > A macro expansion that would be a statement if you add a semicolon
> > does not qualify.
>
> From your description, it sounds like there are some bad lint-like
> tools out there.
>
> A macro that's intended to expand to a statement (and not to an
> expression) should use the "do { ... } while (0)" trick to avoid
> problems when used with if/else.
That depends. As long as it warns for empty statements, which includes
the cases where the macro is immediately followed by a semicolon, it
is fine. Regardless of whether the macro appears in an if statement,
it expects the macro to always be used by itself. And if it is always
used by itself, it causes no problems before an else: it looks just as
you would normally use it. It is just as valid as far as C is
concerned. The main thing it has going against it is that it gets very
confusing when you mix it with macros that do expect to be followed by
a semicolon. (I don't use it myself, by the way.)
Joe Pfeiffer
> On Jul 13, 3:38 pm, Keith Thompson <ks...@mib.org> wrote:
>> cc <scatnu...@hotmail.com> writes:
>> > Is it acceptable practice to have a #define with a semicolon in it,
>> > such as:
>>
>> > #define SMALL 1;
>>
>> > I didn't think it was, but a very good friend of mine claims it's
>> > perfectly acceptable if you want to prevent the #define from being
>> > used in an expression like if(SMALL).
>>
>> Why would you want to prevent it from being used in an expression?
>> I think "1;" is a poor example of what your friend is talking about.
>> I'd be interested in seeing a better example.
>
> That was his example. That was also his explanation of why he did it
> (so the compiler would complain if he used it as an expression).
>
> Another example was from the linux kernel.
>
> /usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
> #define LDO_MAX_VOLT 3300;
I was curious enough I went and looked that one up -- it's the only
#define in the file that ends with a semicolon (even LDO_MIN_VOLT
doesn't), and a recursive grep fails to turn the symbol up anywhere else
in the kernel. I'm guessing the reason for this one was an
overly-clever way of keeping anybody from using it (for anything!) in
what seems to be a fairly new driver.
Keith Thompson
I'm guessing that it's just a mistake that nobody has fixed yet.
Adding the semicolon won't keep it from being used. In many cases, it
won't change anything:
voltage = LDO_MAX_VOLT;
and in others it can silently change the meaning of the code:
voltage = LDO_MAX_VOLT + 1;
--
Barry Schwarz
wrote:
Acceptable is in the eye of the beholder. If you are at work, it is
whatever standards your company adopts. If you are at home, it is
whatever your preference is.
The only thing perfect about is that it is perfectly legal syntax.
I don't find it acceptable at all personally but there is no reason
why you or anyone else reading this should care what I think.
--
Remove del for email
Ben Bacarisse
<snip>
> Another example was from the linux kernel.
>
> /usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
> #define LDO_MAX_VOLT 3300;
It's quote clear from the context that it's a typo. Fortunately the
macro is not used anywhere!
<snip>
--
Ben.
Hallvard B Furuseth
>> Right. So you see no logical reason to ever use something like #define
>> SMALL 1;? I don't either, but I was just making sure there wasn't
>> something I missed.
>
> I won't say there's *never* a reason to do something like that.
> There are cases where macros will expand to something other than
> an expression or a statement. It usually means you're messing with
> the language syntax, which is dangerous but *sometimes* useful.
>
> Many years ago, I wrote something like:
>
> #define EVER ;;
> ...
> for (EVER) {
> ...
> }
>
> but I got better.
More generally, you can end up with such strange-looking macros if you
use the preprocessor to extend the language. E.g. macros for a poor
man's exception facility, typically with setjmp at the core. These
might also use ugliness like
#define FOO_BEGIN(x) { <something>
#define FOO_END(x) <something else> }
You should then try to keep the ugliness inside macro definitions,
so code using the macros will not look too bad. That can lead to
strange definitions like '#define SMALL 1;'.
You might even deliberatey design the facility so the 'x' macro
parameter above takes an argument of format '<number> <semicolon>',
if user code is always supposed to pass a macro like SMALL, never a
number. It could still be naughty and pass FOO_BEGIN(1;) directly
instead of FOO_BEGIN(SMALL), but that will at least look strange.
Maybe that's what the OP's friend is talking about. However it makes
no sense to speak of that in isolation, without reference to the macro
set which uses SMALL.
--
Hallvard
Phil Carmody
There's worse.
$ git grep define\ DELAY_1
Ug.
Phil
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon
Walter Banks
cc wrote:
I wish I had a nickel for every customer call I have taken over the last
30 years where a semicolon at the end of a #define changed an
expression. The worst ones are when an expression is split in two and
creates two valid statements. No compiler errors or warnings just
application anguish.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
pete
The only macro construct that I'm familiar with,
which is designed to be a statement,
is this:
#define macro \
do { \
} while (0)
That gives you a compound statement
in which you can do various things,
such as defining objects etc..
But the semicolon is left out of the macro
so you are forced to have
the semicolon being obvious in code like this:
macro;
--
pete
Gene
> I won't say there's *never* a reason to do something like that.
> There are cases where macros will expand to something other than
> an expression or a statement. It usually means you're messing with
> the language syntax, which is dangerous but *sometimes* useful.
>
> Many years ago, I wrote something like:
>
> #define EVER ;;
> ...
> for (EVER) {
> ...
> }
>
> but I got better.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
A recovering macroholic?
io_x
"cc" <scat...@hotmail.com> ha scritto nel messaggio
news:ab0d55fe-25e5-482b...@c29g2000yqd.googlegroups.com...
> Is it acceptable practice to have a #define with a semicolon in it,
> such as:
>
> #define SMALL 1;
i think you can not use that in this below
if(a>SMALL) b=c;
and this not compile at last i hope so
could be ok in
a=SMALL;
or
a=SMALL b=c;
cc
It seems as though some people have taken issue with my
characterization of the situation. First off, it wasn't a very good
friend, but actually someone I don't even know. It was a Usenet thing.
That was supposed to be a joke for others reading, but one person was
very upset and called me a liar. So no, it wasn't "a very good
friend." Also, they seem to have an issue with the way I presented the
situation. Here is the full post:
"'The semi-colon will be expanded as part of the macro, causing the
printf to fail to compile.'
Correct - but in reality what I actually do is exploit that to make it
intentionally fail!
e.g. I could easily write
if(SMALL) { do something } else { do something else }
That is bad programming - for the most part, I know I would never
write if(SMALL) ... because if I set SMALL to 2,3,4, then everything
is OK when configuring the software, but if accidentally set SMALL to
0 the execution of the if() statement will change and that would have
been an unintentional side effect.
If I accidentally wrote the code with if(SMALL) it will not fail
especially hard to spot the mistake if it is buried in a complex
formula. And there is no warning of impending doom.
So by putting semicolon in #define SMALL 1; I've made sure on
compiling it it is guaranteed to fail when used out of context."
So that's the whole quote (of which I see no difference in what I said
before), so if you feel differently about it being poor coding
practice I would like to hear why again. Also I'm sorry I jokingly
called someone I don't know, my very good friend. Thanks.
Anders Wegge Keller
if (some_condition)
some_var = SMALL + some_other_var++;
I wish you a merry time debugging code like this.
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
Roberto Waltman
>Many years ago, I wrote something like:
>
> #define EVER ;;
> ...
> for (EVER) {
> ...
> }
>
>but I got better.
I am tempted to do that often, because with some compilers this,
while (1) { ... }
generates a warning about the "expression being constant", while your
example is accepted silently.
--
Roberto Waltman
[ Please reply to the group.
Return address is invalid ]
Gordon Burditt
they wanted to stick into a program, and was annoyed that C had no
syntax for that, so they decided on preprocessor abuse.
A mixed-unit measurement is a measurement containing the sum of two
or more different units, rather than a fractional number and one
unit. One of the more annoying examples of this is Mr. Spock's (or
Data's) way of stating time: "5 years, 2 months, 3 weeks, 2 days,
6 hours, 18 minutes, 37.538 seconds" until the Enterprise is totally
out of synthahol.
#define INCHES ) / 63360.0) )
#define METERS ) / 1609.344) + ((
#define LENGTH ( ((
This particular set of awful macros was intended to deal with
mixed-unit measurements in meters and inches, yielding a length in
miles and fractions of miles. (The actual units being used by this
guy made a little more sense, but not much).
It was intended to be used in the form:
LENGTH 37.5 METERS 5 INCHES
I hope I talked him out of it, among other things, by pointing out
that:
LENGTH 5 INCHES 37.5 METERS
wouldn't work, but in some circumstances would silently screw up,
and that it couldn't be extended to handle:
LENGTH 37.5 METERS 5 INCHES 2.5 ANGSTROMS
Also, he was very dissappointed that a set of #defines like this
didn't work on sscanf() input strings.
Snit
70288d39-b915-4810...@e8g2000yqi.googlegroups.com on 7/15/11
4:12 AM:
> On Jul 13, 2:19 pm, cc <scatnu...@hotmail.com> wrote:
>> Is it acceptable practice to have a #define with a semicolon in it,
>> such as:
>>
>> #define SMALL 1;
>>
>> I didn't think it was, but a very good friend of mine claims it's
>> perfectly acceptable if you want to prevent the #define from being
>> used in an expression like if(SMALL).
>
> It seems as though some people have taken issue with my
> characterization of the situation. First off, it wasn't a very good
> friend, but actually someone I don't even know. It was a Usenet thing.
> That was supposed to be a joke for others reading, but one person was
> very upset and called me a liar.
Who was very upset? I merely noted how you were not honest in your claims,
just as you were not honest in your claims about me. But I do not read all
posts... maybe your lying about this, esp. when tied to your other lying,
really did get someone "very upset". Clearly you are addicted to lying.
Heck, just in the last 24 hours you have claimed, of me:
cc:
------
Just so everyone else knows, Snit has admitted he can't tell
if what he's saying is his opinion or a fact, and he also
does not know the definition of words he uses.
-----
Which I never did. You went so far as to lie and attribute "quotes" to me
which I never said. Here are just some examples:
cc:
-----
"I don't know the difference between opinion and fact." - Snit
-----
"I'm a mind reader." - Snit
-----
Of course, as noted, I never said such things. And your creating quotes for
people includes people outside of Usenet, such as when you denied there were
any general principles in UI design (of course there are!) and when you
could find no support for your denial, nor could you counter the evidence of
your error, you created this quote:
cc:
-----
"There are no general principles in HCI." - John M. Carroll
-----
But, of course, you never were able to provide a source for this quote. You
just made it up - and then insisted he emailed you and denounced his public
claims.
And now you are pulling your trolling and your lies into another forum.
Why? Why not keep your lies about me and about others in COLA... or just
stop posting lies at all?
> So no, it wasn't "a very good
> friend." Also, they seem to have an issue with the way I presented the
> situation. Here is the full post:
>
> "'The semi-colon will be expanded as part of the macro, causing the
> printf to fail to compile.'
>
> Correct - but in reality what I actually do is exploit that to make it
> intentionally fail!
>
> e.g. I could easily write
>
>
> if(SMALL) { do something } else { do something else }
>
>
> That is bad programming - for the most part, I know I would never
> write if(SMALL) ... because if I set SMALL to 2,3,4, then everything
> is OK when configuring the software, but if accidentally set SMALL to
> 0 the execution of the if() statement will change and that would have
> been an unintentional side effect.
>
> If I accidentally wrote the code with if(SMALL) it will not fail
> especially hard to spot the mistake if it is buried in a complex
> formula. And there is no warning of impending doom.
>
> So by putting semicolon in #define SMALL 1; I've made sure on
> compiling it it is guaranteed to fail when used out of context."
>
> So that's the whole quote (of which I see no difference in what I said
> before), so if you feel differently about it being poor coding
> practice I would like to hear why again. Also I'm sorry I jokingly
> called someone I don't know, my very good friend. Thanks.
Are you also sorry about your lies about me? Just curious.
--
[INSERT .SIG HERE]
Keith Thompson
> Keith Thompson wrote:
>>Many years ago, I wrote something like:
>>
>> #define EVER ;;
>> ...
>> for (EVER) {
>> ...
>> }
>>
>>but I got better.
>
> I am tempted to do that often, because with some compilers this,
>
> while (1) { ... }
>
> generates a warning about the "expression being constant", while your
> example is accepted silently.
Then just write
for (;;) { ... }
The EVER macro adds nothing but cuteness (which can be good in some
contexts, but isn't in this one). "for (;;)" is a sufficiently
familiar idiom that it doesn't need to be hidden behind a macro.
And I suggest that those compilers could stand some improvement
in their errrror messages. Warning about constant conditions is
reasonable, but "while (1)" should be treated as a special case.
Do those same compilers warn about "do { ... } while (0)", which
is commonly used in macros?
Keith Thompson
> On Jul 13, 2:19 pm, cc <scatnu...@hotmail.com> wrote:
>> Is it acceptable practice to have a #define with a semicolon in it,
>> such as:
>>
>> #define SMALL 1;
>>
>> I didn't think it was, but a very good friend of mine claims it's
>> perfectly acceptable if you want to prevent the #define from being
>> used in an expression like if(SMALL).
>
> It seems as though some people have taken issue with my
> characterization of the situation. First off, it wasn't a very good
> friend, but actually someone I don't even know. It was a Usenet thing.
> That was supposed to be a joke for others reading, but one person was
> very upset and called me a liar. So no, it wasn't "a very good
> friend." Also, they seem to have an issue with the way I presented the
> situation. Here is the full post:
>
> "'The semi-colon will be expanded as part of the macro, causing the
> printf to fail to compile.'
>
> Correct - but in reality what I actually do is exploit that to make it
> intentionally fail!
>
> e.g. I could easily write
>
>
> if(SMALL) { do something } else { do something else }
I don't recall anyone *here* taking issue with your characterization,
much less calling you a liar. If someone did so elsewhere, I fail
to see why you should bring it here, or why anyone here should care.
But ok, by your own description you misstated your relationship with the
person who made the suggestion. You describe that misstatement as a
joke, but you made it in a context where nobody would have any reason to
think it wasn't serious. I certainly had no reason to doubt that the
person in question is "a very good friend" of yours (and very little
reason to care).
With regard to the technical issue, I'd say that
#define SMALL 1;
is almost certainly a very bad idea. There might be a valid reason
to reject the use of SMALL in some contexts, but that's not the way
to do it. As has been pointed out several times, code that refers to
SMALL assuming it's defined in a more conventional way could either
quietly work as intended, or quietly give incorrect results, or fail
with a syntax error (and a message that's likely to be misleading).
It would help to know exactly what contexts SMALL is *intended*
to be used in, and what contexts are to be discouraged.
I do not mean this to be a criticism of the person who made the
suggestion, since we don't know the context, and I don't particularly
trust your characterization of it.
Apparently the person in question posts as "Snit", and has recently
posted in this thread. If Snit would care to discuss the technical
issues, I'd be interested. Perhaps there are good reasons for the
macro that I haven't thought of -- or perhaps the macro definition
isn't as you've presented it. But if it's going to devolve into
an argument about who lied about whom in some other forum, perhaps
you could keep it in that other forum rather than spreading it here.
Robert Wessel
wrote:
>Roberto Waltman <use...@rwaltman.com> writes:
>> Keith Thompson wrote:
>>>Many years ago, I wrote something like:
>>>
>>> #define EVER ;;
>>> ...
>>> for (EVER) {
>>> ...
>>> }
>>>
>>>but I got better.
>>
>> I am tempted to do that often, because with some compilers this,
>>
>> while (1) { ... }
>>
>> generates a warning about the "expression being constant", while your
>> example is accepted silently.
>
>Then just write
>
> for (;;) { ... }
>
>The EVER macro adds nothing but cuteness (which can be good in some
>contexts, but isn't in this one). "for (;;)" is a sufficiently
>familiar idiom that it doesn't need to be hidden behind a macro.
>
>And I suggest that those compilers could stand some improvement
>in their errrror messages. Warning about constant conditions is
>reasonable, but "while (1)" should be treated as a special case.
>
>Do those same compilers warn about "do { ... } while (0)", which
>is commonly used in macros?
MSVC does at higher warning levels (or at least did a release or two
ago, haven't actually checked it in on VS2010). I've still got code
with the appropriate #pragma to suppress the warning.
cc
It was an inside joke, and irrelevant to the code anyway.
> With regard to the technical issue, I'd say that
>
> #define SMALL 1;
>
> is almost certainly a very bad idea. There might be a valid reason
> to reject the use of SMALL in some contexts, but that's not the way
> to do it. As has been pointed out several times, code that refers to
> SMALL assuming it's defined in a more conventional way could either
> quietly work as intended, or quietly give incorrect results, or fail
> with a syntax error (and a message that's likely to be misleading).
>
> It would help to know exactly what contexts SMALL is *intended*
> to be used in, and what contexts are to be discouraged.
I gave all the info I had. I was looking more for what contexts would
#define SMALL 1; be a good idea.
> I do not mean this to be a criticism of the person who made the
> suggestion, since we don't know the context, and I don't particularly
> trust your characterization of it.
>
> Apparently the person in question posts as "Snit", and has recently
Nope, it was someone who posts as "7." Snit is delusional.
> posted in this thread. If Snit would care to discuss the technical
> issues, I'd be interested. Perhaps there are good reasons for the
> macro that I haven't thought of -- or perhaps the macro definition
> isn't as you've presented it. But if it's going to devolve into
The macro definition is as I presented it, and I was looking for good
reasons to have the macro that way as well. I told this "7" it sounded
like bad practice, and I just wanted to verify that I wasn't missing
anything either.
> an argument about who lied about whom in some other forum, perhaps
> you could keep it in that other forum rather than spreading it here.
>
I thought I asked a legitimate C question (well style question at
least), then followed it up with the exact post I had a question about
and little more context. Although I don't see why anyone should care
if "7" is my friend or not. I don't know why Snit chose to go nuts
here, but it wasn't my intention. I apologize on behalf of Snit.
Snit
AM:
He insisted people would want to know about his mischaracterization of his
relationship with 7. I told him you folks likely would not - and, at first,
he wanted *me* to tell you about his misrepresentation. I told him the
whole idea was silly.
This really comes from a fairly long set of debates where cc has been busted
making all sorts of claims about me and others. He fabricates quotes when
he knows he has lost a Usenet debate. Some examples:
-----
"I have taken HCI classes on Making GUIs Pretty." - Snit
-----
"I am a mind reader." - Snit
-----
"I admit I have never taken any HCI classes." - Snit
-----
"There are no general principles in HCI." - John M. Carroll
-----
"I don't know the difference between opinion and fact." - Snit
-----
But, whatever.
> But ok, by your own description you misstated your relationship with the
> person who made the suggestion. You describe that misstatement as a
> joke, but you made it in a context where nobody would have any reason to
> think it wasn't serious. I certainly had no reason to doubt that the
> person in question is "a very good friend" of yours (and very little
> reason to care).
Exactly. He lied to you - but about something that does not really matter.
It is weird... why tell the lie at all? But then, once he did, why make an
issue out of it?
> With regard to the technical issue, I'd say that
>
> #define SMALL 1;
>
> is almost certainly a very bad idea. There might be a valid reason
> to reject the use of SMALL in some contexts, but that's not the way
> to do it. As has been pointed out several times, code that refers to
> SMALL assuming it's defined in a more conventional way could either
> quietly work as intended, or quietly give incorrect results, or fail
> with a syntax error (and a message that's likely to be misleading).
>
> It would help to know exactly what contexts SMALL is *intended*
> to be used in, and what contexts are to be discouraged.
>
> I do not mean this to be a criticism of the person who made the
> suggestion, since we don't know the context, and I don't particularly
> trust your characterization of it.
Makes sense.
> Apparently the person in question posts as "Snit", and has recently
> posted in this thread. If Snit would care to discuss the technical
> issues, I'd be interested.
I am not the one who even posted the technical question... and am not a
programmer (do some scripting, but not a programmer).
> Perhaps there are good reasons for the macro that I haven't thought of -- or
> perhaps the macro definition isn't as you've presented it. But if it's going
> to devolve into an argument about who lied about whom in some other forum,
> perhaps you could keep it in that other forum rather than spreading it here.
Good thought.
--
[INSERT .SIG HERE]
Snit
30a60455-46bc-45b8...@e7g2000vbw.googlegroups.com on 7/15/11
10:37 AM:
...
>> But ok, by your own description you misstated your relationship with the
>> person who made the suggestion. You describe that misstatement as a
>> joke, but you made it in a context where nobody would have any reason to
>> think it wasn't serious. I certainly had no reason to doubt that the
>> person in question is "a very good friend" of yours (and very little
>> reason to care).
>
> It was an inside joke, and irrelevant to the code anyway.
Why would you tell an "inside joke" to an "outside" group? That makes no
sense. And, according to you, not only did I call you on it, but someone
became "very upset" with you about it (you have not said who).
...
>> Apparently the person in question posts as "Snit", and has recently
>
> Nope, it was someone who posts as "7." Snit is delusional.
Why bad-mouth me in multiple groups? I mean, really, can you actually point
to my doing anything wrong or dishonest? I can easily point to you just
flat our fabricating quotes and attributing them to me and others. Heck,
from *today*:
-----
"I have taken HCI classes on Making GUIs Pretty." - Snit
-----
"I am a mind reader." - Snit
-----
"I admit I have never taken any HCI classes." - Snit
-----
"There are no general principles in HCI." - John M. Carroll
-----
"I don't know the difference between opinion and fact." - Snit
-----
"Okay, I admit it. I'm dumb." - Snit
-----
"Hadron and I have been in a relationship for quite some
time now." - Snit
----
About me and about others. All lies. And then you call me "delusional" as
you run around lying about me, Carroll and 7 in a group where they are not
even relevant. Just bizarre.
> Although I don't see why anyone should care if "7" is my friend or not.
Nor I... which is why I specifically told you I was not going to bring your
BS debates to this forum (even when you asked me to!) and encouraged you not
to.
> I don't know why Snit chose to go nuts here, but it wasn't my intention. I
> apologize on behalf of Snit.
You are the one who came to this group and started telling lies about me and
about others. Why?
--
[INSERT .SIG HERE]
Keith Thompson
> cc stated in post
> 30a60455-46bc-45b8...@e7g2000vbw.googlegroups.com on 7/15/11
> 10:37 AM:
>
> ...
>>> But ok, by your own description you misstated your relationship with the
>>> person who made the suggestion. You describe that misstatement as a
>>> joke, but you made it in a context where nobody would have any reason to
>>> think it wasn't serious. I certainly had no reason to doubt that the
>>> person in question is "a very good friend" of yours (and very little
>>> reason to care).
>>
>> It was an inside joke, and irrelevant to the code anyway.
>
> Why would you tell an "inside joke" to an "outside" group? That makes no
> sense. And, according to you, not only did I call you on it, but someone
> became "very upset" with you about it (you have not said who).
Snit, perhaps you could discuss this with him somewhere else (or
at least refrain from doing so here). We knew nothing of your
involvement in this before you started posting here.
You may well have legitimate greivances with "cc", but unless
they're relevant to the C programming language, anyone here who's
interested in hearing about them can easily go to wherever this
dispute started and read about them there.
Snit
PM:
> Snit <use...@gallopinginsanity.com> writes:
>> cc stated in post
>> 30a60455-46bc-45b8...@e7g2000vbw.googlegroups.com on 7/15/11
>> 10:37 AM:
>>
>> ...
>>>> But ok, by your own description you misstated your relationship with the
>>>> person who made the suggestion. You describe that misstatement as a
>>>> joke, but you made it in a context where nobody would have any reason to
>>>> think it wasn't serious. I certainly had no reason to doubt that the
>>>> person in question is "a very good friend" of yours (and very little
>>>> reason to care).
>>>
>>> It was an inside joke, and irrelevant to the code anyway.
>>
>> Why would you tell an "inside joke" to an "outside" group? That makes no
>> sense. And, according to you, not only did I call you on it, but someone
>> became "very upset" with you about it (you have not said who).
>
> Snit, perhaps you could discuss this with him somewhere else (or
> at least refrain from doing so here). We knew nothing of your
> involvement in this before you started posting here.
I just do not want him spreading his lies about me here. He has a habit of
making up quotes about me and just out and out lying.
What is weird is that our two main debates were about nothing a reasonable
person would find offensive. One: I noted that in UI design there are well
established guidelines / principles and, two, I noted that I think there is
"too much" abuse of power by the police and others.
> You may well have legitimate greivances with "cc", but unless
> they're relevant to the C programming language, anyone here who's
> interested in hearing about them can easily go to wherever this
> dispute started and read about them there.
Frankly I have no idea why cc even brought the silly debate here. I
specifically asked him *not* to.
From COLA:
cc:
-----
Beyond that, I suggest you let everyone in clc know I was
dishonest, and for what reasons.
-----
Snit:
-----
Huh? Why would I talk about you to other people. My
goodness you think the world revolves around you.
-----
cc:
-----
Well if I was being lied to, I would like to know.
-----
Snit:
-----
Who said anyone was lying to you? And, frankly, why would
you care if you were lied to about some people you know
nothing about? But if you are feeling bad about your lying
then *you* should go confess. Why do you want me to do
your dirty work?
-----
And then he said he *did* post here - so I read what he wrote.
--
[INSERT .SIG HERE]
cc
> Keith Thompson stated in post lny5zznvd6....@nuthaus.mib.org on 7/15/11 1:26> >> 30a60455-46bc-45b8-9fbd-11a284c62...@e7g2000vbw.googlegroups.com on 7/15/11
> >> 10:37 AM:
>
> >> ...
> >>>> But ok, by your own description you misstated your relationship with the
> >>>> person who made the suggestion. You describe that misstatement as a
> >>>> joke, but you made it in a context where nobody would have any reason to
> >>>> think it wasn't serious. I certainly had no reason to doubt that the
> >>>> person in question is "a very good friend" of yours (and very little
> >>>> reason to care).
>
> >>> It was an inside joke, and irrelevant to the code anyway.
>
http://groups.google.com/group/comp.os.linux.advocacy/msg/3a5ee46536f2a32f?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/a8051fcdf5ded95d?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/7de52749f27d42a2?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/652fc8011997f516?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/8d54e837191e9be1?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/f66f2e6b68a0c1ec?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/15fe1ade93092d9b?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/f5acc6d53e4cc9c5?hl=en&dmode=source
http://groups.google.com/group/comp.os.linux.advocacy/msg/f48f73bbb34e2019?hl=en&dmode=source
All the context one would need.
cc
Bullshit. You admitted you could not tell the difference by not answering
my questions.
Anyone in clc can just ask the people in COLA and they will hear of what a
liar you are.
> cc:
> -----
> "I don't know the difference between opinion and fact." - Snit
> -----
> "I'm a mind reader." - Snit
> -----
You have made both of those claims.
> Of course, as noted, I never said such things. And your creating
> quotes for people includes people outside of Usenet, such as when you
> denied there were any general principles in UI design (of course
> there are!) and when you could find no support for your denial, nor
> could you counter the evidence of your error, you created this quote:
>
> cc:
> -----
> "There are no general principles in HCI." - John M. Carroll
> -----
He said that in his email to me. I quoted it for you.
--
You Ain't the Biggest Fish in the Crotch
cc
Poor Snit. You make up things about people all the time and then cry when
people do it to you.
--
cc
> cc stated in post
> 30a60455-46bc-45b8...@e7g2000vbw.googlegroups.com on
> 7/15/11 10:37 AM:
>
> ...
>>> But ok, by your own description you misstated your relationship
>>> with the person who made the suggestion. You describe that
>>> misstatement as a joke, but you made it in a context where nobody
>>> would have any reason to think it wasn't serious. I certainly had
>>> no reason to doubt that the person in question is "a very good
>>> friend" of yours (and very little reason to care).
>>
>> It was an inside joke, and irrelevant to the code anyway.
>
> Why would you tell an "inside joke" to an "outside" group? That
> makes no sense. And, according to you, not only did I call you on
> it, but someone became "very upset" with you about it (you have not
> said who).
You are the one who is clearly very upset. Look how much you keep crying
about it.
> ...
>>> Apparently the person in question posts as "Snit", and has recently
>>
>> Nope, it was someone who posts as "7." Snit is delusional.
>
> Why bad-mouth me in multiple groups? I mean, really, can you
> actually point to my doing anything wrong or dishonest? I can easily
> point to you just flat our fabricating quotes and attributing them to
> me and others. Heck, from *today*:
>
> -----
> "I have taken HCI classes on Making GUIs Pretty." - Snit
> -----
> "I am a mind reader." - Snit
> -----
> "I admit I have never taken any HCI classes." - Snit
> -----
> "There are no general principles in HCI." - John M. Carroll
> -----
> "I don't know the difference between opinion and fact." - Snit
> -----
> "Okay, I admit it. I'm dumb." - Snit
> -----
> "Hadron and I have been in a relationship for quite some
> time now." - Snit
> ----
All perfectly accurate quotes.
> About me and about others. All lies. And then you call me
> "delusional" as you run around lying about me, Carroll and 7 in a
> group where they are not even relevant. Just bizarre.
>
>> Although I don't see why anyone should care if "7" is my friend or
>> not.
>
> Nor I... which is why I specifically told you I was not going to
> bring your BS debates to this forum (even when you asked me to!) and
> encouraged you not to.
>
>> I don't know why Snit chose to go nuts here, but it wasn't my
>> intention. I apologize on behalf of Snit.
>
> You are the one who came to this group and started telling lies about
> me and about others. Why?
--
cc
You sure beg for attention a lot.
cc
Interesting forgery. Seems kind of unnecessary though, no?
Snit
e7abab8c-3b8e-45b1...@o18g2000yqm.googlegroups.com on 7/19/11
11:18 AM:
Based on the headers I think Carroll is trying to get in on the fun... but,
hey, given how you keep forging my name as you fabricate quotes and
attribute them to me, you should have no problem with him forging your name?
Right?
I mean, after all - you clearly have decided forgeries are OK in your book.
--
[INSERT .SIG HERE]
cc
>
> Based on the headers I think Carroll is trying to get in on the fun... but,
> hey, given how you keep forging my name as you fabricate quotes and
> attribute them to me, you should have no problem with him forging your name?
>
> Right?
>
> I mean, after all - you clearly have decided forgeries are OK in your book.
>
Ohhhh. I see what's going on here. Well I apologize to clc. Clearly
Snit has lost his little mind. I suggest killfiling anything from "cc"
as I imagine there will be more forgeries to follow from Snit. I asked
a C question (again, relatively speaking), and didn't intend on having
a moron follow and post off topic.
Kleuskes & Moos
> On Jul 15, 4:31 pm, Snit <use...@gallopinginsanity.com> wrote:
>
>
>
>
>
>
>
>
>
> > Keith Thompson stated in post lny5zznvd6....@nuthaus.mib.org on 7/15/11 1:26
> > PM:
>
> > > Snit <use...@gallopinginsanity.com> writes:
> > >> cc stated in post
> > >> 30a60455-46bc-45b8-9fbd-11a284c62...@e7g2000vbw.googlegroups.com on 7/15/11
> > >> 10:37 AM:
>
> > >> ...
> > >>>> But ok, by your own description you misstated your relationship with the
> > >>>> person who made the suggestion. You describe that misstatement as a
> > >>>> joke, but you made it in a context where nobody would have any reason to
> > >>>> think it wasn't serious. I certainly had no reason to doubt that the
> > >>>> person in question is "a very good friend" of yours (and very little
> > >>>> reason to care).
>
> > >>> It was an inside joke, and irrelevant to the code anyway.
>
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/a8051fcdf5d...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/7de52749f27...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/652fc801199...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/8d54e837191...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/f66f2e6b68a...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/15fe1ade930...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/f5acc6d53e4...
>
> http://groups.google.com/group/comp.os.linux.advocacy/msg/f48f73bbb34...
>
> All the context one would need.
I would hardly consider comp.os.linux.advocacy to be a reliable source
of _anything_.
J. J. Farrell
Would you two ask your nannies to push your prams of somewhere else, please.
Snit
To be fair, this is not likely cc. Based on headers it is probably a guy
named Steve Carroll who follows me around wherever I go. He, like cc, loves
to forge people's identities.
In any case, sorry the COLA madness slipped over to CLC. I just did not
want cc to spread lies about me here that went unanswered. As if anyone in
CLC cares about me one whit. :)
--
[INSERT .SIG HERE]
Noob
> Or, worse, if it's used like this:
> voltage = LDO_MAX_VOLT + 1;
Setting the voltage to one VOLT more than the MAX?
Are you trying to blow the whole thing up?! ;-)
J. J. Farrell
The point is that this code would set the voltage to the max, NOT a volt
more. Perhaps this could be considered a good technique for safety
critical code ...
Phil Carmody
> > > such as:
> >
> > > #define SMALL 1;
> >
> > > I didn't think it was, but a very good friend of mine claims it's
> > > perfectly acceptable if you want to prevent the #define from being
> > > used in an expression like if(SMALL).
> >
> > I think "1;" is a poor example of what your friend is talking about.
> > I'd be interested in seeing a better example.
>
> That was his example. That was also his explanation of why he did it
> (so the compiler would complain if he used it as an expression).
>
> Another example was from the linux kernel.
>
> /usr/src/linux-3.0.0-rc7-mainline/include/linux/mfd/tps65910.h:
> #define LDO_MAX_VOLT 3300;
Patch now in Jiri Kosina's "trivial" tree. Commit 497888cf
treewide: fix potentially dangerous trailing ';' in #defined values/expressions
Thanks for reporting it (and for others such as Keith for responding
to it, as I don't read googlegroups posts). Let's hope we don't see
any more of those for a while.
Phil
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon
Michael Angelo Ravera
> Is it acceptable practice to have a #define with a semicolon in it,
> such as:
>
> #define SMALL 1;
>
> I didn't think it was, but a very good friend of mine claims it's
> perfectly acceptable if you want to prevent the #define from being
> used in an expression like if(SMALL).
Maybe someday I will come up with a good and friendly reason to
include a terminal semicolon in a define, but every time that I have
included one to date has been accidental and ALWAYS extremely
unfriendly.
You haven't SEEN obscure and difficult to diagnose errors such as you
will see if you do this accidentally or use the define of someone who
did so.
Todd Carnes
> Thanks for reporting it (and for others such as Keith for responding to
> it, as I don't read googlegroups posts). Let's hope we don't see any
> more of those for a while.
Posts to comp.lang.c are not GoogleGroups posts.
Ian Collins
Joe Pfeiffer
checking... in this case, the original question was, as was the OPs
followup pointing to the #define in the kernel.
Phil Carmody
I'm not quite sure how a post from googlegroups can be anything but a
googlegroups post, but if in your twisted little world that's how
things are, I hope you're happy there.
Todd Carnes
> A number of old school Usenet users ignore posts from groups.google.com.
I see. I think it's a silly thing to do, but I guess it's no different
than the way I refused for years to give in and get a cell phone. Sooner
or later they'll get over it...just like I did. :)
Todd
Todd Carnes
> I'm not quite sure how a post from googlegroups can be anything but a
> googlegroups post, but if in your twisted little world that's how things
> are, I hope you're happy there.
Sheesh, don't get your panties in a bunch.
While users on GoogleGroups may post to a usenet newsgroup, they also may
post to groups that are not on usenet... i.e. a GoogleGroup. I'm only
saying that comp.lang.c is not a GoogleGroup. It's a usenet group.
Todd
Keith Thompson
I presume that by "googlegroups posts" he means articles posted to
Usenet via the Google groups interface.
Phil Carmody
> On Sat, 23 Jul 2011 01:14:08 +0300, Phil Carmody wrote:
>
> > I'm not quite sure how a post from googlegroups can be anything but a
> > googlegroups post, but if in your twisted little world that's how things
> > are, I hope you're happy there.
>
> Sheesh, don't get your panties in a bunch.
Hypocrite.
> While users on GoogleGroups may post to a usenet newsgroup, they also may
> post to groups that are not on usenet... i.e. a GoogleGroup. I'm only
> saying that comp.lang.c is not a GoogleGroup. It's a usenet group.
Care to cite where I said otherwise?
For a while I used to have aioe.org /en bloc/ in my killfile too due
to the low SNR therefrom, you have reminded me of those days.
Todd Carnes
> I presume that by "googlegroups posts" he means articles posted to
> Usenet via the Google groups interface.
Yeah, I get it now. I took it the wrong way at first.
Todd
Todd Carnes
[blah, blah, blah... snip]
> For a while I used to have aioe.org /en bloc/ in my killfile too due to
> the low SNR therefrom, you have reminded me of those days.
>
> Phil
Whatever.
Believe it or not, I really was sorry you took offense (at first), but if
you want to get all worked up over one little comment, go right ahead.
As for me, I consider the conversation (what little there was of it) to
be over.
Todd
Seebs
> On Sat, 23 Jul 2011 09:54:29 +1200, Ian Collins wrote:
>> A number of old school Usenet users ignore posts from groups.google.com.
> I see. I think it's a silly thing to do, but I guess it's no different
> than the way I refused for years to give in and get a cell phone.
Well, maybe. If people with cell phones called you, did it result in
conversations with them being broken up into 1-minute sub-conversations
scattered around apparently randomly?
... Come to think of it, maybe that is a sort of good analogy.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
Todd Carnes
> On 2011-07-22, Todd Carnes <toddc...@gmail.com> wrote:
>> On Sat, 23 Jul 2011 09:54:29 +1200, Ian Collins wrote:
>>> A number of old school Usenet users ignore posts from
>>> groups.google.com.
>
>> I see. I think it's a silly thing to do, but I guess it's no different
>> than the way I refused for years to give in and get a cell phone.
>
> Well, maybe. If people with cell phones called you, did it result in
> conversations with them being broken up into 1-minute sub-conversations
> scattered around apparently randomly?
>
> ... Come to think of it, maybe that is a sort of good analogy.
>
> -s
LOL... Yes, in the beginning, it often did. :)
Todd
Willem
) On Sat, 23 Jul 2011 00:12:38 +0000, Seebs wrote:
)> Well, maybe. If people with cell phones called you, did it result in
)> conversations with them being broken up into 1-minute sub-conversations
)> scattered around apparently randomly?
)>
)> ... Come to think of it, maybe that is a sort of good analogy.
)>
)> -s
)
) LOL... Yes, in the beginning, it often did. :)
ObRandomQuote:
Call-phone sex: Can you feel me now ? And now ? How 'bout now ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Robert Miles
Depends on how good you are at ignoring or filtering out the
heavy flow of spam from groups.google.com.