comp.lang.c - 23 new messages in 7 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* C - gets() function implementation help - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/7bd0bc765a2e9603?hl=en
* Gary Lee Burnore, databasix, and protecting the public. - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/cd36989f151808b8?hl=en
* C the complete nonsense - 7 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
* Son of Snarky Tirade: a response to Seebach's new CTCN: part 1 - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
* Test of a preprocessor symbol defined as nothing vs. zero - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
* lvalues and rvalues - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
* dynamic buffer allocation at char buf[1] - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/969816eb2d0fdbaf?hl=en

==============================================================================
TOPIC: C - gets() function implementation help
http://groups.google.com/group/comp.lang.c/t/7bd0bc765a2e9603?hl=en
==============================================================================

== 1 of 8 ==
Date: Sun, Apr 11 2010 11:22 am
From: Seebs

On 2010-04-11, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On 11 Apr, 18:24, Barry Schwarz <schwa...@dqel.com> wrote:
>> On Sun, 11 Apr 2010 17:56:54 -0000, "bartc" <ba...@freeuk.com> wrote:
>>
>> >How do you know you haven't made mistake before you hit Enter?
>>
>> The fact that no data has been sent to the processor doesn't mean you
>> can't read it on the screen.  One might consider the screen as the
>> buffer where the data is held until Enter is pressed.
>>
> In that case you have two processors, a little one which collects
> input from the keyboard, marshalls it into an input line, and updates
> the screen, and a big one which accepts the processed line input and
> solves protein folding (or whatever), sending the results back to the
> little processor which updates the scren.

Right -- but your C code is running on the big processor.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 8 ==
Date: Sun, Apr 11 2010 1:13 pm
From: Barry Schwarz

On Sun, 11 Apr 2010 19:15:15 -0000, "bartc" <bartc@freeuk.com> wrote:

>
>"Barry Schwarz" <schwarzb@dqel.com> wrote in message
>news:g904s5t7j11m616vh9ro8ulfsmpvdrvs7v@4ax.com...
>> On Sun, 11 Apr 2010 17:56:54 -0000, "bartc" <bartc@freeuk.com> wrote:
>>>"Barry Schwarz" <schwarzb@dqel.com> wrote in message
>>>news:cig1s5pmnjp3p7bs78c5h1uq7eol379erm@4ax.com...
>
>>>> That may be how it works on your system but my keyboard sends no
>>>> signals to the processor until enter is pressed. I wonder how it
>>>> works on the OP's system or if he even knows.
>>>
>>>It sounds quite difficult to use.
>>>
>>>How do you know you haven't made mistake before you hit Enter?
>>
>> The fact that no data has been sent to the processor doesn't mean you
>> can't read it on the screen. One might consider the screen as the
>> buffer where the data is held until Enter is pressed.
>
>OK, so maybe there's a local processor which reads or scans the keyboard and
>updates the display (unless your terminal is so old that it uses random
>logic).
>
>In that case, perhaps that can be considered the 'processor'. As far as the
>main processor is concerned, it doesn't have a proper interactive device
>attached, only something that might sporadically give a line of text.

Since you get to define what you mean by proper, your assessment is
obviously correct.

However, in the context of this discussion, my counter-example serves
to show conclusively that the original description of how often the
processor executing the C code is interrupted by the user typing was
hardly universal.

>
>>>Typing a password with a conventional machine is also difficult but at
>>>least
>>>you can see how many characters you've typed.
>>
>> I assume by conventional you mean PC.
>>
>> Believe it or not, there are real security people who say that
>> displaying those cute little asterisks is a bad idea. It allows any
>> over-the-shoulder lurker to see how many characters are in your
>> password, thus making attempts to hack the password easier.
>
>(Does it? What word am I thinking of at this minute? I'll give you a clue:
>it's got 7 letters and not 6 or 8 or 9.

So now my exhaustive attack no longer has to deal with any password
length other than 7. Considering only letters and numbers, a
6-character password can contain any of pow(6,36) possible values.
Similar values for the longer ones. By restricting my effort, you
have reduced my task by 99.988%, from 2.28556E34 to 2.65173E30.
(Calculation performed using Excel 2003 with default options.) A
ten-thousand fold reduction in effort meets my definition of easier.

--
Remove del for email

== 3 of 8 ==
Date: Sun, Apr 11 2010 1:22 pm
From: Malcolm McLean

On 11 Apr, 21:13, Barry Schwarz <schwa...@dqel.com> wrote:
> On Sun, 11 Apr 2010 19:15:15 -0000, "bartc" <ba...@freeuk.com> wrote:
>
> So now my exhaustive attack no longer has to deal with any password
> length other than 7.  Considering only letters and numbers, a
> 6-character password can contain any of pow(6,36) possible values.
> Similar values for the longer ones.  By restricting my effort, you
> have reduced my task by 99.988%, from 2.28556E34 to 2.65173E30.
> (Calculation performed using Excel 2003 with default options.)  A
> ten-thousand fold reduction in effort meets my definition of easier.
>
Not really. 10^34 is the same as 10^30, if you can only submit one
password to the system at once. If you can try a billion passwords a
second, it's 10^21 versus 10^25 seconds. You'll be just as dead before
the shorter time is up than before the longer one is.

== 4 of 8 ==
Date: Sun, Apr 11 2010 1:27 pm
From: Nick Keighley

On 10 Apr, 16:41, brian <bec...@gmail.com> wrote:
> On Apr 10, 7:12 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > On 2010-04-10, brian <bec...@gmail.com> wrote:

> > > I am a newbie in C programming.
> > > I have to make an implementation of gets() function from stdio.h, but
> > > I am not sure where to start.
> > > Please advice, any help is welcome.
>
> > My first advice is:  This is a bad assignment, because the gets()
> > function is inherently broken.

google for it. Basically gets() has no way to know how large the
buffer you called it with is. Hence a user can type charcaters until
the buffer overflows and then Bad Things Happen. I believe the latest
draft standard is removing gets() from the standard C library. And
about time too.

> > Your instructor may not know this, but strictly speaking, you're not
> > allowed to make a function named gets() -- that name is reserved.  You
> > can try it, and it might even happen to work, but it's not really
> > the right thing to do.
>
> > Here's a thing to start with.
>
> > Describe what gets() does.  What parameters does it take?  What does
> > it return?  What does it *DO*?
>
> > For instance, I might start out with something like:
> >         The mygets() function takes as a parameter the address of a
> >         buffer assumed to be large enough to hold any input data.
> >         The function then gets characters from standard input until
> >         it sees either EOF or a newline, at which point it null
> >         terminates the string and returns.  If no characters are
> >         received before EOF, the function indicates an error.
>
> > That's not a very good spec -- see if you can find some of the flaws
> > in it and correct them.
>
> > Once you have the spec, it shouldn't be too hard to write the routine.
>
> > -s
> > --
> > Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

don't quote sigs- text that appears after "-- "

> Thank you for your thorough advice.
>
> For example a standard description of gets() function says:
> The gets() function shall read bytes from the standard input stream,
> stdin, into the array pointed to by s, until a <newline> is read or an
> end-of-file condition is encountered. Any <newline> shall be discarded
> and a null byte shall be placed immediately after the last byte read
> into the array.
>
> I would like to do the same. Some guy recommended me to use getc() and
> a loop,
> But I think I should to try to implement it without using standard
> stdio.h function, just pure C programming, if you know what I mean....
> What could you advice on that?

ask whoever set the assignment if this is what he intended. But I
doubt he intended the assignment to be as hard as that. You can't
write getc() completly in standard C. At some point you're going to
have to access the hardware and you can't do this in standard C. Plus
modern operating systems make direct access to the hardware quite
difficult (for very good reasons)

== 5 of 8 ==
Date: Sun, Apr 11 2010 1:42 pm
From: Nick Keighley

On 10 Apr, 16:11, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On 10 Apr, 11:04, brian <bec...@gmail.com> wrote:> Hi everyone,
>
> > I am a newbie in C programming.
> > I have to make an implementation of gets() function from stdio.h, but
> > I am not sure where to start.
>
> > Please advice, any help is welcome.
>
> Presumably you are allowed getchar.
> Simply read characters into the buffer passed to your mygets(),
> reading them one by one with getchar(). Stop when getchar() returns
> either EOF or a newline. terminate the buffer with a nul, not
> forgetting to suppress the trailing newline.
>
> As others have pointed  out, gets() will (probably) crash if you pass
> it a buffer shorter than the line you read.

if yer lucky
gts() has been implicated in various security breaches

> Given the specifications,
> there's no way to prevent this behaviour, so think of it as an
> undesireable feature rather than a bug.

I consider behaviour as bad as this to be a bug

== 6 of 8 ==
Date: Sun, Apr 11 2010 1:47 pm
From: Richard Heathfield

Malcolm McLean wrote:
> On 11 Apr, 21:13, Barry Schwarz <schwa...@dqel.com> wrote:
>> On Sun, 11 Apr 2010 19:15:15 -0000, "bartc" <ba...@freeuk.com> wrote:
>>
>> So now my exhaustive attack no longer has to deal with any password
>> length other than 7. Considering only letters and numbers, a
>> 6-character password can contain any of pow(6,36) possible values.
>> Similar values for the longer ones. By restricting my effort, you
>> have reduced my task by 99.988%, from 2.28556E34 to 2.65173E30.
>> (Calculation performed using Excel 2003 with default options.) A
>> ten-thousand fold reduction in effort meets my definition of easier.
>>
> Not really. 10^34 is the same as 10^30, if you can only submit one
> password to the system at once.

Malcolm, that isn't how password crackers work. You don't sit at the
keyboard and guess. You sit at the keyboard and run your
password-cracking program, which tries millions of passwords a second,
and it starts off by whizzing through the dictionary and minor
variations thereof.

> If you can try a billion passwords a
> second, it's 10^21 versus 10^25 seconds. You'll be just as dead before
> the shorter time is up than before the longer one is.

Anyone stupid enough to type in his password where an adversary can
count the asterisks may well be stupid enough to use a seven-letter
English word as his seven-letter password, in which case the castle wall
could well be breached in just a few seconds.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 7 of 8 ==
Date: Sun, Apr 11 2010 1:49 pm
From: Richard Heathfield

brian wrote:
> Hi everyone,
>
> I am a newbie in C programming.
> I have to make an implementation of gets() function from stdio.h, but
> I am not sure where to start.

Start off by finding out why gets() is an open invitation to adversaries
to stomp all over your system.

Once you know that, implementing gets() is easy - Just Say No.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 8 of 8 ==
Date: Sun, Apr 11 2010 1:52 pm
From: Keith Thompson

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On 11 Apr, 21:13, Barry Schwarz <schwa...@dqel.com> wrote:
>> On Sun, 11 Apr 2010 19:15:15 -0000, "bartc" <ba...@freeuk.com> wrote:
>>
>> So now my exhaustive attack no longer has to deal with any password
>> length other than 7.  Considering only letters and numbers, a
>> 6-character password can contain any of pow(6,36) possible values.
>> Similar values for the longer ones.  By restricting my effort, you
>> have reduced my task by 99.988%, from 2.28556E34 to 2.65173E30.
>> (Calculation performed using Excel 2003 with default options.)  A
>> ten-thousand fold reduction in effort meets my definition of easier.
>>
> Not really. 10^34 is the same as 10^30, if you can only submit one
> password to the system at once. If you can try a billion passwords a
> second, it's 10^21 versus 10^25 seconds. You'll be just as dead before
> the shorter time is up than before the longer one is.

And if I have any *other* information, it's quite possible that
knowing your password is 7 characters makes an otherwise infeasible
attack feasible.

Consider a system that requires all passwords to be exactly 7
characters, no more, no less. Is such a system more or less secure
than a system that allows longer passwords?

--
Keith Thompson (The_Other_Keith) kst-u@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"

==============================================================================
TOPIC: Gary Lee Burnore, databasix, and protecting the public.
http://groups.google.com/group/comp.lang.c/t/cd36989f151808b8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 12:02 pm
From: " Gregory Hall"

"Kent Wills" <compuelf@gmail.com> wrote in message
news:o364s55vsj0rs454r24tkqno7hfdc7cv98@4ax.com...

>
> Gary kissed his girlfriend's 17 year old daughter. Very
> inappropriate, but not anywhere near what you dishonestly try to
> imply.
> Is there a specific reason you are trying to make it appear as if
> Gary did that which he did not?

Maybe you should read this:

http://www.uffnet.com/mirrors/archives.mfn.org/images/batch_2/Doc3.JPG

--
Gregory Hall

==============================================================================
TOPIC: C the complete nonsense
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
==============================================================================

== 1 of 7 ==
Date: Sun, Apr 11 2010 12:04 pm
From: Malcolm McLean

On 11 Apr, 19:30, Willem <wil...@turtle.stack.nl> wrote:
> Malcolm McLean wrote:
>
> ) On 11 Apr, 18:49, Nick <3-nos...@temporary-address.org.uk> wrote:
> )>
> )> Does feof have a real use I've somehow missed (the examples above are
> )> clearly not it - they can all be improved by not using the function).
> )>
> ) You're parsing a file, eg a script file. You check for the "end of
> ) script" token, for the sake of argument the word "END". However if
> ) characters follow the "END" the script has a syntax error, which must
> ) be reported. So chomping whitespace and checking for feof() is a
> ) reasonable thing to do.
>
> You just made the same mistake as Schildt:
>
> After you read 'E' 'N' 'D' from the file, feof() will *not* be true,
> even if it were the last three characters in the file.
> The *correct* thing to do is to check if the next read returns EOF
> or not.
>
No, I chomped whitespace.

== 2 of 7 ==
Date: Sun, Apr 11 2010 12:16 pm
From: Nick <3-nospam@temporary-address.org.uk>

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-04-06, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>> On 6 Apr, 16:30, Seebs <usenet-nos...@seebs.net> wrote:
>>> Except that you have yet to show that even ONE of the nitpicks is actually
>>> wrong -- some of them may be overly picky, or not the most persuasive or
>>> best examples, but that doesn't make them "not even right".
>
>> Take the very first. The term "In general" means, "there are a few
>> specific cases where this does not apply, but these aren't
>> sufficiently important to concern us here".
>
> No, it means either that or "always". Both usages exist in English, and
> the phrase is ambiguous.

I have to say, purely as a point of English usage, that to me "in
general" (as a two word phrase, rather than other uses of "general")
means only "most of the time" or similar, not "always". There's no
point qualifying what would already be an absolute statement with it
unless it changes the meaning.

> The book is crap. Here, let's play Random Page!

Now this I agree with. So let's join in.

>
> Page 288... Whaddya know" In the 4th edition, if there's an error, it's
> too subtle for me. On the other hand, it's purely an enumeration of the
> C99 _Pragma() feature and the __VA_ARGS__ macro expansion feature. So
> let's look in the 3rd edition.
>
> The header file associated with the I/O functions defined by
> ANSI is called STDIO.H.

In the second edition, page 288 is the next page on from this. It's all
too dossy for me to know how right or wrong it is, but...

- there's an example of void main.
- double quotes are used to include a header file supporting a function
that "is commonly included in the library of DOS-based compilers" (this
seems widespread - stdio.h on the next page is treated similarly).
Maybe not an actual error, but none conventional to say the least.

> For many C compilers, the header file related to the UNIX-like file
> system is called IO.H.
>
> Never heard of such a header, even allowing for the bogus caps. Anyone
> know whether it's a DOSism?

That just sneaks onto the top of the page, so we can count this one as
well.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 3 of 7 ==
Date: Sun, Apr 11 2010 12:21 pm
From: Nick <3-nospam@temporary-address.org.uk>

J de Boyne Pollard <J.deBoynePollard@Tesco.NET> writes:

>> Possibly Jonathan playing around with headers.
>
> Time for you to read some Usenet FAQs. Moving a discussion of MS-DOS
> programming to the newsgroup for MS-DOS programming is hardly "playing
> around". Don't unthinkingly follow the bad example of Rod Pemberton's
> cluelessness, here. Put the thinking cap on and think!

From the man who consistently de-attributes everything this is just a
tad rich.

Time to move another local kill file entry global I see.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 4 of 7 ==
Date: Sun, Apr 11 2010 12:28 pm
From: Phil Carmody

Keith Thompson <kst-u@mib.org> writes:
> Colonel Harlan Sanders <Harlan@kfc.com> writes:
> [...]
>> Thanks, but I didn't really expect that a FAQ on DOS EOF markers would
>> be related to Whatever the Hell CIS URLs are, so I did not look at the
>> rest of that site. From the snarky tone of your reply I suspect now
>> that when you say "Frequently Given Answer" that you are in fact
>> referring to your website, not a generic "Frequently given answer",
>> if so, WHY NOT SAY SO?
>
> For anyone who still cares, the '.' in the URL is explained at
>
> <http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html>
...
> The "CIS" is an abbreviation for "Common Internet Scheme", a term
> defined in RFC 1738, <http://www.ietf.org/rfc/rfc1738.txt>.

An RFC which JdeBP violates on that very page! Classic.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 5 of 7 ==
Date: Sun, Apr 11 2010 1:02 pm
From: Malcolm McLean

On 11 Apr, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
> > On 2010-04-06, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
> >> On 6 Apr, 16:30, Seebs <usenet-nos...@seebs.net> wrote:
> >>> Except that you have yet to show that even ONE of the nitpicks is actually
> >>> wrong -- some of them may be overly picky, or not the most persuasive or
> >>> best examples, but that doesn't make them "not even right".
>
> >> Take the very first. The term "In general" means, "there are a few
> >> specific cases where this does not apply, but these aren't
> >> sufficiently important to concern us here".
>
> > No, it means either that or "always".  Both usages exist in English, and
> > the phrase is ambiguous.
>
> I have to say, purely as a point of English usage, that to me "in
> general" (as a two word phrase, rather than other uses of "general")
> means only "most of the time" or similar, not "always".  There's no
> point qualifying what would already be an absolute statement with it
> unless it changes the meaning.
>
Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.
People are like that.
Then I'm attacked for not analysing all of the errata.

== 6 of 7 ==
Date: Sun, Apr 11 2010 1:48 pm
From: James Harris

On 11 Apr, 17:30, Seebs <usenet-nos...@seebs.net> wrote:

...

> Schildt's bad explanations are, for the most part, quite consistent.
> Look at the way he "explains" EOF.  He shows sample code.  He explains that
> the sample code will fail "on binary files".  Sure enough!  If you run that
> code on a file people would typically think of as a binary file, on a
> typical MS-DOS or Windows system, it almost certainly fails in the way he
> describes.  He reveals a solution -- a way to avoid that failure.  Sure
> enough!  His proposed solution appears to mitigate the problem.
>
> The victim now believes that Schildt has imparted to him knowledge of a
> tricky pitfall in C, as well as a solution -- a way to avoid that pitfall.
> He notices that many other programmers don't know about this pitfall, or
> use that solution.  He concludes that Schildt's book is very good -- it
> covered something many people don't know about.
>
> He recommends Schildt's book, confidently... Unaware that there was never
> any problem except that Schildt didn't know what he was doing, and the simple
> standard code everyone else is using works fine and is both simpler and
> more reliable than what Schildt demonstrated.
>
> Basically, Schildt is living large off the low end of the Dunning-Kruger
> curve; people who think they learned C from his books are likely to imagine
> that they learned C very well, but in practice, most of them take years
> to recover.

Sorry to quote almost the whole post but it's a fascinating
suggestion. Setting up supposed problems with the language and showing
how to solve them possibly gives his readers the feeling that they are
learning some secret knowledge. After all no other book shows this
'insider' information. As you say, readers may be unaware that the
problems didn't really exist in C. Judged in isolation the book would
appear immensely valuable.

And if the examples are complex enough and not easy to remember people
would want to keep the book around in case they are ever faced with a
similar problem and need to look it up.

Maybe there's a suggestion in there for potential authors: use the
same style of showing problems and solutions but do so with real
issues the readers are likely to encounter. Would it work? I don't
know. With a well-designed language there are probably fewer real
issues than imaginary ones.

Regardless, it's an intriguing insight into why Schildt's book may be
popular.

James

== 7 of 7 ==
Date: Sun, Apr 11 2010 1:49 pm
From: Keith Thompson

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Nearly 400 posts to this thread later, and we still haven't quite
> established that Seebs wrote a spurious first entry to his errata.
> People are like that.

We haven't estblished it because there are legitimate differences of
opinion on the point, something I don't recall seeing you acknowledge.

> Then I'm attacked for not analysing all of the errata.

No, you're criticized for judging the entire list based on the first
one or two entries.

--
Keith Thompson (The_Other_Keith) kst-u@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"

==============================================================================
TOPIC: Son of Snarky Tirade: a response to Seebach's new CTCN: part 1
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 12:38 pm
From: Nick Keighley

On 11 Apr, 17:36, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-11, Willem <wil...@turtle.stack.nl> wrote:
>
> > spinoza1111 wrote:
> > ) This is my reply (part 1) to Peter Seebach's new edition of "C: the
> > ) Complete Nonsense" athttp://www.seebs.net/c/c_tcn4e.html. Further
> > ) parts of my complete reply will be forthcoming.
> > <snip>
> > ) At this point, I shall end the first part of my reply to Seebach?s
> > ) Snarky Tirade.
> > Your *entire* reply consisted of nothing but ad-hominem attacks.
>
> This is excellent news.  One of my goals was to explain the technical
> details well enough that there would be less room for nitpicking against
> my document.  Another was to, while preserving many nitpicks, identify
> them as such and point out their limitations.  I appear to have done so.
>
> > It reads like you desire to find fault with every little thing that
> > Seebs writes and if you can't, you go for the man behind the words.
>
> The straw man behind the words, for the most part.  I do think it would
> be fascinating to meet the seebs he writes about, though!
>
> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Test of a preprocessor symbol defined as nothing vs. zero
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 1:36 pm
From: Francois Grieu

On 11/04/2010 10:25, Keith Thompson wrote:
> Mark Adler<madler@alumni.caltech.edu> writes:
>> On 2010-04-10 17:22:35 -0700, Seebs said:
>>> On 2010-04-11, Mark Adler<madler@alumni.caltech.edu> wrote:
>>>> However I'd wonder if there won't be a compiler that would complain
>>>> about "-+1" as an expression.
>>>
>>> Why would it? - - - - - - - - - - - 5 is a perfectly valid expression.
>>
>> I wasn't worried about the minus, I was worried about the plus. Unary
>> plus was not always valid in C. K&R and the old Sun C didn't allow it.
>
> Unary + was introduced by ANSI in the C89 standard. If you're using a
> compiler so old that it doesn't support it, then it doesn't conform to
> *any* standard, and you're likely to have worse problems than that.

Making the preprocessor standards-conformant is an area the compiler vendors tend to neglect. Two examples that hit me in the last 6 months:

1) An admittedly obscure embedded C compiler, claiming C90 conformance with traces of C99, under active maintenance, recognized unary + in the compiler, but not the preprocessor, due to a defect; the vendor fixed it within hours of my report.

2) A non-obscure compiler (if you visualize what I mean) won't compile:

// return the smallest of x y z
#define MIN3(x,y,z) ( (x)>(y) ? (y)>(z) ? (z) : (y) : (x) )

#define ALPHA 5
#define BETA 4
#define GAMMA 6

#if MIN3(ALPHA,BETA,GAMMA) < 2
#error "check ALPHA BETA GAMMA"