Re: man 3 switch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/16/2009 01:06 PM, Steven W. Orr wrote:
On 11/16/09 13:54, quoth Rick Stevens:
On 11/14/2009 01:55 PM, Frank Cox wrote:
On Sat, 14 Nov 2009 14:50:57 -0500
Steven W. Orr wrote:

There's nothing wrong with perl having all kinds of perldoc pages.
But perl
comes from one place. C, OTOH could come from lots of places besides
FSF and
the switch statement in gcc may not be exactly the same as the switch
statement in some other dialect.

As C is an ISO standard, I sincerely doubt there would be any
difference in the
syntax and behaviour of the keywords between C compilers on any Unix-like
operating system.

Incorrect.  C, for example, does not guarantee the order of evaluation
of arithmetic operators of equal precedence in the same statement (in
other words, is something like "a + b + c" evaluated left to right, or
right to left?).  This can have significant effects if some of the
operands have "side effects"

Another example is that a null pointer (or the value "NUL") is not
necessarily zero, only that it is guaranteed to not point at any valid
datum.

C allows quite a bit of leeway to the compiler implementation.


I think I disagree on this one. We jumped from standardization of keywords to
how operators perform. I quote from page 53 of K&R: Table of Precedence and
Associativity of Operators: a + b + c *always* goes from left to right. K&R is
not the standard, but does the standard say otherwise? Lots of things are up
to the compiler writer, but I'd be surprised if this was one of them. Sometime
people worry about things like

a++ + b++ + c++

but even there, the precedence and the associativity are defined. In this case

a++ + b++ + c++

becomes (in psuedo stack code):

a++
b++
c++
a b +
c +

because binary + is lower precedence than ++.

No?

I probably should have added "...subject to standard rules of arithmetic". AFAIK, there's no guarantee to the order that any given
operand to an arithmetic operator will be evaluated if they're at the
same level of precedence.  In the examples you give, the binding of "++"
is higher than addition so that's unambiguous. But if a, b or c are, say, pointers that depend on the values of one of the others, then side
effects can be dangerous (the classic example of that is "getc(3)").

What I was trying to get across is, while the library is pretty standardized (with the exceptions usually called out in the man pages),
there are some things that different compilers will do differently and
one should take reasonable care to make sure to use order enforcing
syntax to make things work properly.

However even that is off the point of this thread.  The C _library_
is documented, but that's because it is the underpinnings of many of
the high-level languages used (C, C++, Fortran and most of the others).
The languages themselves normally aren't.  The perl, python and several
other groups do create man pages for their languages (which can be
massive) and that's a nice thing, but IMHO it's somewhat inappropriate.
If you need to know C, get a book.  Ditto C++ or python or other high-
level language.  Don't rely on man pages.

I'm not even sure I like all the stuff you get with "man bash", but you all know that I'm a curmudgeon. :-)
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks@xxxxxxxx -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-    If your broker is so damned smart...why is he still working?    -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux