twitter: comp.lang.c - 25 new messages in 7 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* usage of size_t - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Experiment: functional concepts in C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* Any exit status without explicitely using return /exit - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
* Efficency and the standard library - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* Stylistic questions on UNIX C coding. - 8 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* C99 is widely used! - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
* Scope of a variable declared in for loop - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 9:44 am
From: "Ed Vogel"

"Ersek, Laszlo" <lacos@ludens.elte.hu> wrote in message
news:TfnzfiP9zzx4@ludens...
> In article <Xt8Bokvz0a6x@ludens>, lacos@ludens.elte.hu (Ersek, Laszlo)
> writes:
> So you worked on *the* C compiler for OpenVMS, then; I notice.
>
For *many* years.

Ed Vogel

== 2 of 2 ==
Date: Wed, Feb 24 2010 9:47 am
From: "Ed Vogel"

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
news:5ee86f72-218a-4b98-8871-7f651be05f9f@o30g2000yqb.googlegroups.com...
>People aren't going to be using 64 bits for long before they start
>asking for objects greater than 4GB.

Some have asked for it, most have not.
There are ways to get/access objects > 4GB, but one needs to
be careful.

Ed Vogel

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 9:50 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <4b8457d6.42569328@news.xs4all.nl>, raltbos@xs4all.nl (Richard Bos) writes:
> jacob navia <jacob@nospam.org> wrote:
>
>> Then, to read a 4 digit year from character into an integer you use
>> several temporary objects, by reading the characters into a list
>> container temp, that calls a general routine to convert a list
>> container into a boxed multi-precision integer that gives a boxed
>> integer that is converted into an unboxed one... eventually.
>
> ...and that is precisely why a generalised container library for C is
> exactly the wrong thing to write.

Funnily enough, I think this is overgeneralization. In my narrow view of
things (aka "tunnel vision"), I'd rather not rewrite my light-weight
red-black tree "library" each time I turn to it. And hey, it links to
user-allocated objects through (void *) and takes a comparison function,
so it's generic!

Cheers,
lacos

== 2 of 2 ==
Date: Wed, Feb 24 2010 10:05 am
From: ld

On 24 fév, 16:33, Ertugrul Söylemez <e...@ertes.de> wrote:
> ld <laurent.den...@gmail.com> wrote:
> > > > Nitpick: How is it possible to create an infinite data structure
> > > > on a machine with finite resources? (Maybe "unbounded" or
> > > > "arbitrarily long" would be a better term?)
>
> > > I think such languages work on a "lazy" principle- they only
> > > evaluate the things that are actually needed so if you create a
> > > couple of infinite structures you have no problem unless you try to
> > > output an infinite result.
>
> > You don't have problem either, it just takes an infinite time. This is
> > equivalent to an infinite loop which outputs something in C.
>
> Not exactly. Try to translate the following pair of functions to C:
>
> isPrime :: Integral i => i -> Bool
> isPrime n = all (\d -> rem n d /= 0) . takeWhile (\d -> d^2 <= n) $ primes
>
> primes :: Integral i => [i]
> primes = 2 : filter isPrime [3..]
>
> 'primes' is an infinite list of all prime numbers, calculated in a naive
> trial division manner, but the trial division uses only prime numbers.
> This is where lazy infinite data structures are more powerful than just
> infinite loops with finite data structures.

This doesn't contradict what I said. If you try to print primes, it
will take an infinite time, assuming an infinite memory since the CAF
(primes) cannot be garbage collected until the end of the printing
which never comes. The observable effect will be the same as an
infinite loop printing something. This is why I say that it is not a
problem (or equivalently, it is a problem in both C and Haskell
depending on your intend).

> > > So you might write a program that computes a list of all the primes,
> > > but you only output the first 1000. The compiler is smart enough not
> > > to evaluate all those primes you never look at.
>
> > I don't know if the compiler is smart, but it follows the language
> > principle which requires an "outermost reduction". C uses an
> > "innermost reduction" which evaluate the arguments first then call the
> > function. Haskell does the opposite which by definition evaluates only
> > the arguments used (when the value is needed).
>
> Note that there are two related, but separate concepts at work here:
> Firstly non-strict semantics. This is what you mentioned: Function
> arguments are not evaluated before the function is called.

As I understand it, non-strict semantic _results_ from the reduction
strategy (and its properties). I am not aware of a strict semantic
being able to apply outermost reduction. Therefore, non-strict
semantic means to push the lambda expressions representing the
arguments first then call the function.

> But when are
> they evaluated then? This is where the lazy evaluation stategy comes
> in, the second concept. A computation is carried out as it is demanded.

As I understand it (;-),

lazy evaluation
= non-strict semantic + subgraph sharing
= optimal reduction strategy.

and it is not required to explain the behavior of primes.

regards,

ld.

==============================================================================
TOPIC: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 9:49 am
From: Keith Thompson

raltbos@xs4all.nl (Richard Bos) writes:
> Debanjan <debanjan4you@gmail.com> wrote:
>> On Feb 24, 2:02=A0pm, Keith Thompson <ks...@mib.org> wrote:
>> > Debanjan <debanjan4...@gmail.com> writes:
>> > > This actually bugging me from quite sometime now.The question is like
>> > > this : How to set the the exit status of a program to any value
>> > > without explicitly using return/exit in gcc ?
>
>> > A more relevant question: Why don't you want to use return or exit?
>> > That's what they're for.
>>
>> There are few online coding challenge contest where less the number of
>> character more the points you earned
>
> That is an _extremely_ bad idea. Don't do it. Write for legibility
> instead.

Agreed. First, learn how to write *clear* code. Once you've done
that, contests where you try to minimize the number of source
characters can be entertaining (I've entered the IOCCC myself), but
you could be learning some very bad habits.

In this particular instance, there is *no* good reason to avoid the
use of exit and return. (You can get away with it if you have a C99
implementation and the status you want to return happens to be 0, but
even then I'd say that an explicit "return 0;" is a good idea.)

--
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"

== 2 of 2 ==
Date: Wed, Feb 24 2010 11:02 am
From: Seebs

On 2010-02-24, Debanjan <debanjan4you@gmail.com> wrote:
> Now it returns 0 implicitly,but I am unable to draw any firm
> conclusion from this,could anybody help to generalize ?

Yes:

Sometimes what happens when you invoke undefined behavior may be surprising,
unpredictable, or influenced by things which don't matter.

Seriously, anything you try to draw from this will be wrong on other systems,
or on the same system in a different phase of the moon. You're thinking about
this in a totally wrong way. The correct generalization is that, assuming
a C89 environment, the return value is undefined, and it could be anything.
It may appear to exhibit patterns. It may even exhibit patterns on some
systems, some of the time, at some optimization levels.

But since the code is wrong, who cares what it does?

-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!

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Feb 24 2010 10:10 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <hm3jt0$7rr$2@news.eternal-september.org>, santosh <santosh.k83@gmail.com> writes:

> Apparently though, unsigned long is still 32 bits even under 64 bit
> versions of Visual C. That's indeed a very strange choice, but I
> guess there was a compelling reason for it.

Yuck. So they can squeeze a long in an int, but not a pointer into a
long. This is none of ILP32, LP64, LPBIG. I'm curious what their off_t
is (if they have any).

http://www.unix.org/whitepapers/64bit.html

"The LLP64 data model preserves the relationship between int and long by
leaving both as 32-bit types. Data objects, such as structures, which do
not contain pointers will be the same size as on a 32-bit system. This
model is sometimes described as a 32-bit model with 64-bit addresses.
Most of the run-time problems associated with the assumptions between
the sizes of the data types are related to the assumption that a pointer
will fit in an int. To solve this class of problems, int or long
variables which should be 64-bits in length are changed to long long (or
int64), a non-standard data type. This data model is thus again
dependent on the introduction of a new data type. Again there is
potential for conflict with existing typedefs in applications."

Cheers,
lacos

== 2 of 5 ==
Date: Wed, Feb 24 2010 10:26 am
From: Ian Collins

Richard Heathfield wrote:
> Ian Collins wrote:
>> Richard Heathfield wrote:
>>> spinoza1111 wrote:
>>>
>>>> and follows the lead of most other
>>>> compilers, which don't get "picky" by default.
>>>
>>> Would that they did. Then the quality of software might improve a bit.
>>
>> Why should they?
>
> Because in picky mode they often point out real code problems that they
> don't point out in non-picky mode. The earlier you discover the bug, the
> cheaper it is to fix it.

I guess it depends on what you define as picky. I mainly works with Sun
CC, which issues considerably more warnings in default mode than gcc,
but significantly fewer than Sun's lint.

That gives me the best of both worlds, fast compilation during
development (I compile a lot) and pedantic application or library wide
warnings for daily builds.

>> If you want to analyse code, use a tool like lint. Let the compiler
>> focus on compiling legal code quickly and accurately.
>
> If I were writing (or, still pretty unlikely but rather less unlikely,
> specifying) a compiler, I'd want its default setting to be maximally
> picky. Anyone who doesn't want that could switch OFF warnings, either
> individually or by small inter-related groups.

I'd rather add warnings and have faster builds, but that's a matter of
personal preference.

--
Ian Collins

== 3 of 5 ==
Date: Wed, Feb 24 2010 11:15 am
From: Seebs

On 2010-02-24, Ian Collins <ian-news@hotmail.com> wrote:
> Richard Heathfield wrote:
>> spinoza1111 wrote:
>>> and follows the lead of most other
>>> compilers, which don't get "picky" by default.

>> Would that they did. Then the quality of software might improve a bit.

> Why should they?

Because it catches errors.

> If you want to analyse code, use a tool like lint.
> Let the compiler focus on compiling legal code quickly and accurately.

It turns out that in practice, a whole lot of the work needed to do that
overlaps heavily with the work needed to produce the warnings.

More pragmatically, people tend not to put tools like lint in their
compilation path, which means that they don't notice warnings until there
are too many to deal with, which means they don't get fixed.

== 4 of 5 ==
Date: Wed, Feb 24 2010 11:17 am
From: Seebs

On 2010-02-24, Richard Heathfield <rjh@see.sig.invalid> wrote:
> I didn't realise he'd got around to fixing that one. I don't have a copy
> of CTCR3, for obvious reasons.

To clarify:

2E: Both sizeof and use of <> as !=
3E: Sizeof still wrong, != fixed
4E: Sizeof fixed too, but as I recall in an unidiomatic way

== 5 of 5 ==
Date: Wed, Feb 24 2010 11:48 am
From: BruceS

On Feb 24, 9:06 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 24, 11:41 pm, BruceS <bruce...@hotmail.com> wrote:
>
>
>
> > On Feb 24, 8:09 am, Rob Kendrick <n...@rjek.com> wrote:
>
> > > On Wed, 24 Feb 2010 06:49:08 -0800 (PST)
>
> > >spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > On Feb 24, 11:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > > > Peter Nilsson wrote:
> > > > > > Richard Heathfield <r...@see.sig.invalid> wrote:
> > > > > >> That's an easy one. It's because he's an idiot.
>
> > > > > > Is that considered to constitute a promising technical
> > > > > > argument (sic)?
>
> > > > > Not in the slightest. :-)
>
> > > > Fuck you, asshole. These newsgroups are not set up so that you and
> > > > Seebach can harass and label their contributors. If you can't behave,
> > > > leave.
>
> > > But it's clearly OK for you to label contributors.
>
> > > > And fuck you very much indeed, for I regard profanity as a far lesser
> > > > evil than the deliberate destruction of reputations in which you
> > > > engage, while claiming to defend Holy Fucking C, a piece of shit on
> > > > its last legs.
>
> > > I think that book reviews are a good way of destroying people's
> > > reputations. Like, say, the reviews for your and Herb's books on
> > > Amazon.
>
> > > B.
>
> > Wow! I didn't realize thatspinoza1111had written a book. I guess a
> > more diligent reading of clc would have revealed that, but I have to
> > admit to not having nearly enough time for that. Given the quality of
> > his posts here, both in terms of technical competence and in writing
> > style (not to mention his quick resort to vulgarity, vitriol, and
> > petty flames), I'm truly amazed that he's been published. My hat is
> > off to you,spinoza1111. You've proven by example that *anyone* can
> > write a book and get it published. You can't imagine how inspiring
> > that is.
>
> The real vulgarity is the treatment that I and many others have been
> subjected to in this newsgroup. Others mistreated here include C
> compiler developer Jacques Navia, who has attempted to use this
> newsgroup, as I am, for technical discussion only to have his good
> name dragged in the mud by two incompetent programmers here, Richard
> Heathfield and Peter Seebach.

I think I recall Navia from some time back, as another who repeatedly
painted himself as an arrogant incompetent. If I'm confusing him with
someone else, I apologize in advance for my being too lazy to research
it. Otherwise, it makes perfect sense why you identify with him.
FWIW, to people like me, Heathfield and Seebach don't make you look
foolish or incompetent; you do that all by yourself.

> The former has written a poorly-received
> book with far more, and far more global, errors than Schildt, who is
> being scapegoated here for the incompetence of the regulars. The
> latter started the anti-Schildt canard by attacking his book when he
> could not extort money from McGraw Hill, and has repeatedly posted
> erroneous code, and Seebach is distinguished, if that is the word, by
> having taken a grand total of zero classes in computer science at
> university or thereafter.

I've only been in the business since the mid '80s, but in that time
have worked with several people who had taken no CS classes, yet
managed to be quite skilled as programmers. I also worked with some
who had great credentials, including one who had a Masters in CS from
(IIRC) Yale, but were demonstrably unqualified to write code. My own
degree is a BS in CSS from a third-rate school, but it did me no
harm. I still get great compliments from coworkers and customers, and
get paid enough to get lots of pretty trinkets. IME, there's little
correlation between formal education in CS and actual ability.

> Feminized males in corporations don't defend their reputations: this
> is "disruptive". I defend mine.
>
> Feminized, disempowered, weak and soft males have been taught by bimbo
> feminism and the corporation to simply look the other way when evil
> occurs whether here, in the corporate world, or in Palestine. They
> reason that if someone's getting his ass kicked, he must have deserved
> it. They reason that if someone fights back, he must be a terrorist.

Feminized males, Palestinians, terrorists? Weren't we discussing
programmers and authors? Is this where you start calling me an anti-
Semite, or a Zionist, or maybe veer off into another direction and
accuse me of being part of some bizarre conspiracy?

> You have poor reading comprehension indeed, because you have read one
> or two posts

At times I think that would have been wiser, but I'm afraid the count
is rather higher than that.

> and jumped to a conclusion. When I am treated with
> dignity, collegiality, and respect, I respond in kind to people like
> Professor Massengill and others right here. I conducted myself with
> enough dignity, collegiality, respect and technical acumen to be
> selected to assist John Nash with C at Princeton University.

Name dropping is not very impressive. It appears to me that you
resort to vulgarity quickly when your repeated failure to understand
something leads another to frustration far short of your own rage.
This doesn't seem to impress anyone with your qualifications, but
rather make them more likely to just tune you out. I suggest you'd do
better with less vitriol, more careful fact checking, and a greater
attempt to understand what's being explained to you.

> However, I am quite past the point of showing patience with break-room
> antics here: back-stabbing, childish name-calling insults, and
> scapegoating others for errors we ALL make in a complex business.
>
> And you can take it as read that I will fight fire with fire. I will
> call people "names". The difference is my evidence. When I call Peter
> Seebach an "incompetent" my evidence, if needs be in a court of law,
> will be his attempt to simulate strlen() with a newbie's off by one
> bug, his "replace %s" that replaces all percent signs, and his self-
> confessed lack of ANY academic qualifications.
>
> When I call Richard Heathfield a thug, I repeat my evidence of his
> false "humility" unlinked to charity, his enabling of others'
> bullying, his name-calling, and his lack of any substantive technical
> contributions to this newsgroup other than break room programming
> saws.
>
> My book, "Build Your Own .Net Language and Compiler" is still selling
> well and has in the past ranked among the top ten compiler books on
> Amazon. It describes technology that is a complete mystery to the regs
> here. I suggest you buy a copy: I can use your money, and it would be
> a worthwhile investment on your part.

I doubt that. If I were interested in building a .NET language, I'd
get a book that actually addressed it. From what I've read about
yours, it sounds like it doesn't do that. As it is, I have little
enough interest in building a new language that I won't spend time on
confirming or countering those reviews. I *did* buy a copy of C99,
and consider that a good use of my money. We all have different
special interests, which is of course in no way an invalidation of
others' special interests.

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 24 2010 10:35 am
From: Poster Matt

Hi,

I've a few questions concerning style when programming C on UNIX systems. I
don't want to look like an amateur. :)

1. Having been programming in higher level languages for the last 15 years, I'm
finding it hard to get used to DEFINES in all capitals. Is it really frowned on
not to do so? Is CamelCase acceptable?

EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.

2. My personal variable and function naming style is camel case, with variable
names beginning with a lower case char and function names not. Is that
acceptable, if not what is?

EG:
Variables: int numFiles = 0;
Functions: int CountNumFilesInDir(char* path);

3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
120 chars I start thinking this might not look great in someone else's editor.

4. Does anyone care where the pointer * is? I prefer keeping to next to the
type, rather than next to the variable name.

EG. I like: char* firstName; and not so much: char *firstName;

5. On a slightly different note, I've been handling my error messages by using
#define string constants in a header file. I saw some code which did this and it
looked good to me. Is that standard practise, if not what is?

EG. #define ErrorDirNotFound "The directory was not found."

There are so many style guides out there, most of them say contradictory things
at one point or another. What do the pros do?

Finally, before someone points this out... I know if I'm coding for myself, and
not following somebody else's stylistic requirements, I can do whatever I want.
However I'd like my code to be 'acceptable looking' to the wider UNIX C community.

Thanks and regards, etc.

== 2 of 8 ==
Date: Wed, Feb 24 2010 11:10 am
From: Julienne Walker

On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.

All caps is merely a convention so that macros are easier to see. If
you don't want to follow that convention, feel free. Though keep in
mind that conventions are there for a reason. The preprocessor has
proven troublesome enough over the years to warrant having macros
stand out a bit. ;-)

> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);

That's fine. I see that style often.

> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.

I try to keep each line under 100 characters (80 if possible). It's
less about monitor size than it is about easily reading my code at a
glance.

> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;

Just make sure you're consistent and nobody will care. :-)

> 5. On a slightly different note, I've been handling my error messages by using
> #define string constants in a header file. I saw some code which did this and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."

That's acceptable. Though keep in mind that in the age of
internationalization and localization, hard coding string literals
makes your code harder to port to other spoken languages.

> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?

The pros are just as contradictory as the style guides. Pick a style
you like and run with it, with the caveat that over time your tastes
(and as a result, your style) will evolve.

> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.

You can make bad code look pretty and it's still bad code. But in my
experience, good code has never looked ugly. Good aesthetics seems to
come naturally if you focus on writing the best code possible.

== 3 of 8 ==
Date: Wed, Feb 24 2010 11:21 am
From: Fred

On Feb 24, 11:10 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>
> > Hi,
>
> > I've a few questions concerning style when programming C on UNIX systems. I
> > don't want to look like an amateur. :)
>
> > 1. Having been programming in higher level languages for the last 15 years, I'm
> > finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> > not to do so? Is CamelCase acceptable?
>
> > EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
>
> All caps is merely a convention so that macros are easier to see. If
> you don't want to follow that convention, feel free. Though keep in
> mind that conventions are there for a reason. The preprocessor has
> proven troublesome enough over the years to warrant having macros
> stand out a bit. ;-)
>
> > 2. My personal variable and function naming style is camel case, with variable
> > names beginning with a lower case char and function names not. Is that
> > acceptable, if not what is?
>
> > EG:
> > Variables: int numFiles = 0;
> > Functions: int CountNumFilesInDir(char* path);
>
> That's fine. I see that style often.
>
> > 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> > 120 chars I start thinking this might not look great in someone else's editor.
>
> I try to keep each line under 100 characters (80 if possible). It's
> less about monitor size than it is about easily reading my code at a
> glance.
>
> > 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> > type, rather than next to the variable name.
>
> > EG. I like: char* firstName; and not so much: char *firstName;
>
> Just make sure you're consistent and nobody will care. :-)

Except that it is very error-prone to do so.

In C, the asterisk is associated with the variable name, not the type
specifier.
I've seen this so many times:

char* x, y;

Here, x a pointer to char, but y is a char.

Much clearer to show what you really intended:

char *x, *y; /* Both pointers */
or
char *x, y; /* One a pointer, one not */

>(snip)

--
Fred K

== 4 of 8 ==
Date: Wed, Feb 24 2010 11:29 am
From: James Harris

On 24 Feb, 18:35, Poster Matt <postermatt@no_spam_for_me.org> wrote:
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)

As a fellow amateur in C....

> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.

While I use them I don't like all caps for #defined values for two
reasons

1) #defined values don't seem to me too far removed from global
parameters. Indeed if we change them to parameters in a function call
they lose upper case status. The two uses are similar. To my mind the
format of the names should also be similar.

2) I'd prefer to reserve all caps for macros. Then they serve as a
warning that parameters are not guaranteed to be evaluated exactly
once.

Many libraries use all caps for their constants.

You could also define constants in enums rather than in #defines.

>
> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?

You'll probably get advised to stick to whatever coding standards your
project team members use. Also, when changing someone else's code,
stick to the standards used therein. For your own projects you could
use

first_name
firstname
FirstName
firstName

> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.

Again, use existing coding standards if there are any. My monitor is
also wide but I prefer to keep to 80-columns because you never know
what size monitor the code will subsequently be edited on.

>
> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;

It's normally as the latter due to

char* FirstName, ch, *p;
char *FirstName, ch, *p;

Regardless of which form is used I think only ch will be a char
variable - i.e. "char*" can be misleading. The other variables will be
pointers. Someone will correct me if I'm wrong. Though you are right
in principle, C does not cleanly segregate type and name. For example

int func(int);

This declares the name func but the type information is scattered all
over such declarations.

That's much better than sprinkling messages throughout the code. If
followed consistently it makes clear what messages the code can issue.
Apart from clarity that would help if you ever want to release your
code in another human language. There are better ways with more
mechanism.

You may need a way to include variable values in your messages.

>
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
>
> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.

Check some examples: K&R2, C Unleashed, books by Douglas Comer, the
Linux source etc. Also there is a FAQ entry for style issues:

http://c-faq.com/style/index.html

James

== 5 of 8 ==
Date: Wed, Feb 24 2010 11:29 am
From: Lew Pitcher

On February 24, 2010 13:35, in comp.lang.c, postermatt@no_spam_for_me.org
wrote:

> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems.
> I don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is it
> really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.

CamelCase is acceptable, with the caveat that the programmer (you, or
whomever reads your code) should be able to distinguish the difference
between a macro and a variable.

> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names not. Is
> that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);

Again, CamelCase is acceptable.

> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I
> reach 120 chars I start thinking this might not look great in someone
> else's editor.

Somewhere around 80 characters per line is the norm. That facilitates both
on-screen review and editing as well as printing and emailing of code.

> 4. Does anyone care where the pointer * is? I prefer keeping to next to
> the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;

That's acceptable, but prone to error.
Given
char* firstName lastName;
what is the type of <lastName>?

If you read the declaration and answered that <lastName> is of char* type,
then you would be wrong. The language groups type modifiers to the defined
object, and not to the base type. Visually grouping the modifiers contrary
to how the language groups them can lead to programmer mis-interpretation
and error.

> 5. On a slightly different note, I've been handling my error messages by
> using
> #define string constants in a header file. I saw some code which did this
> #and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."

Most development groups I've worked with would find that practice
acceptable.

> There are so many style guides out there, most of them say contradictory
> things at one point or another. What do the pros do?

Usually, the pros do what the other pros that they are working with do.
Computer languages are a convenience to the /programmer/, not to the
computer. The rules (both at a language level, and at a developer level)
are set to make it easy for a programmer to write code, and for other
programmers to read (and often rewrite) it. So long as you apply your style
rules consistently (so that there are no unexpected deviations), things
should work out.

> Finally, before someone points this out... I know if I'm coding for
> myself, and not following somebody else's stylistic requirements, I can do
> whatever I want. However I'd like my code to be 'acceptable looking' to
> the wider UNIX C community.

/Which/ "UNIX C community"? Some communities have their own coding styles
("the one true style", or the K&R style, or the "Linux Kernel stye", for
instance), and no one set of rules will make your code acceptable to all of
the communities out there.

The best I can give you is to
a) be consistant, and
b) be simple
in your coding. Don't do the unexpected; once you've established a pattern,
stick with it until there is good reason to change. Document the change
ahead of time. Don't over-complicate things. The point is to make your code
easy to read and understand at the /human/ level.

> Thanks and regards, etc.

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

== 6 of 8 ==
Date: Wed, Feb 24 2010 11:32 am
From: Seebs

On 2010-02-24, Poster Matt <postermatt@no_spam_for_me.org> wrote:
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?

It'll work, but people will find it surprising. All-caps as a warning that
something is a macro or other manifest constant is pretty canonical.

But you'd normally spell that one "MAX_FILES".

> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?

I dislike it, anyway. Convention is words_with_underscores().

> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);

Also, "Num" doesn't need to be there.

> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.

80ish is preferred. Lines exceeding 80 will generally not be accepted by a
lot of projects unless there's a VERY good reason.

> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.

> EG. I like: char* firstName; and not so much: char *firstName;

You are wrong.

I mean, sure, it compiles, but consider:

char* x, y;

By contrast:
char *x, y;
makes it clear that you are aware that the * modifies the variable, not the
type.

> EG. #define ErrorDirNotFound "The directory was not found."

No. Look into gettext() if you need to do this, or just put them in
literally.

> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?

I use the Linux kernel style guide and/or the BSD style guide, which are
basically compatible. Ignore the GNU coding standards, they're awful.

It's a good effort. I do have to say, though... It's odd that you've managed
a complete sweep of, for every stylistic decision described above, picking
the opposite of the general convention in the UNIX world. Where did you pick
up these preferences?

== 7 of 8 ==
Date: Wed, Feb 24 2010 11:42 am
From: Julienne Walker

On Feb 24, 2:21 pm, Fred <fred.l.kleinschm...@boeing.com> wrote:
> On Feb 24, 11:10 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> > On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>
> > > 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> > > type, rather than next to the variable name.
>
> > > EG. I like: char* firstName; and not so much: char *firstName;
>
> > Just make sure you're consistent and nobody will care. :-)
>
> Except that it is very error-prone to do so.

It's only error prone if you have multiple variables in a declaration
statement (which the OP's example did not). That itself is often
viewed as an unsafe practice.

== 8 of 8 ==
Date: Wed, Feb 24 2010 11:35 am
From: Rich Webb

On Wed, 24 Feb 2010 11:10:21 -0800 (PST), Julienne Walker
<happyfrosty@hotmail.com> wrote:

>On Feb 24, 1:35�pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>> Hi,
>>
>> I've a few questions concerning style when programming C on UNIX systems. I
>> don't want to look like an amateur. :)

>> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
>> 120 chars I start thinking this might not look great in someone else's editor.
>
>I try to keep each line under 100 characters (80 if possible). It's
>less about monitor size than it is about easily reading my code at a
>glance.

Typographers, who study this thing with the fervor that programmers
bring to brace styles, would tend to agree. There are always reasonable
exceptions but a line length that's 70-80 characters (monospaced) seems
to be a sweet spot for comprehension.

>> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
>> type, rather than next to the variable name.
>>
>> EG. I like: char* firstName; and not so much: char *firstName;
>
>Just make sure you're consistent and nobody will care. :-)

Except there's the danger in having one's thoughts focused elsewhere
when adding the next piece, and getting

char* firstName, lastName;

--
Rich Webb Norfolk, VA

==============================================================================
TOPIC: C99 is widely used!
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 11:09 am
From: Seebs

On 2010-02-24, jacob navia <jacob@nospam.org> wrote:
> That is a typical post. Well, if you care to investigate those claims
> a bit you find immediately that they are completely WRONG. I cared to
> go to Green Hills Software web site and there I found this statement from
> 2007:

I find it surprising.

> The Green Hills compiler was the first compiler for embedded systems to achieve 100% conformance to
> ANSI/ISO standards for C and C++. In addition, the new compiler supports the latest C99
> specification and the latest MISRA C standard.

Interesting. I wonder which compiler they're using for C99. I had not heard
of anyone passing C99 tests.

> That version was out in 2007!!!!

> How can this guy tell us that "there is no C99 support" in Green Hills
> compilers?

Possibly relevant:
1. Embedded systems are quite often billed as "freestanding", meaning they
don't have to have a working standard library -- and that's where a lot of
the work goes.
2. If you read that carefully, technically it never claims to be 100%
conformant to the CURRENT standard. "Was the first..." could mean that,
in 1992 or so, they achieved 100% conformance to the ISO standard for C,
before any other embedded compiler had done so. And that, now, they support
C99 -- but not with 100% conformance.
3. I do not, in general, trust the marketing blurbs produced by vendors.

I know that we have occasionally had issues with marketing making claims
which were not what we told them, but which were similar enough to a layman
that I do not suspect malice.

== 2 of 2 ==
Date: Wed, Feb 24 2010 11:12 am
From: Seebs

On 2010-02-24, jacob navia <jacob@nospam.org> wrote:
> gwowen a écrit :
>> We do not support: C95, C99, C++ 2003, C++ TR1.
>> Though we do support, as language extensions, some C99 features. Two
>> examples are the restrict keyword, and the header file stdint.h.

> No. Green Hills upgraded to C99 3 years ago. That you are broke and
> can't afford the new version has nothing to do with C99 support.

It does for other people who might be using the same compiler.

> You can use gcc-1.0, but then, you can't argue that gcc doesn't support
> C++ or C99. What counts is the version ABAILABLE. Besides, that version
> is already 3 years old. Enough time to upgrade.

In embedded systems, it's quite common to stick with a stable, known, version
for 3-5 years, or even 10, because changes would require extremely expensive
revalidation.

> Ans so what? That is an old small embedded processor that surely
> doesn't support the full standard of C89 because the run time must
> fit in a very small RAM place. Functions like double arithmetic or long
> double are probably absent.

Probably not. Keep in mind that most embedded targets are freestanding,
meaning they'll tend to have most of the underlying language features,
but not always all. (Note that stdint.h and restrict are, by the way, both
things that can be implemented purely by adding headers or keyword parsing,
with NO additional compilation logic and NO additional runtime!)

==============================================================================
TOPIC: Scope of a variable declared in for loop
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 24 2010 11:21 am
From: Seebs

On 2010-02-24, Mark Bluemel <mark.bluemel@googlemail.com> wrote:
> Thanks for the correction. I should have checked C99, but given its
> absence from my day-to-day existence, I tend to forget about it.

Fair enough. If someone asked me whether you could do that in C, the
"right" answer, IMHO, is the qualified one. If you MUST give an unqualified
answer, "no" is safer.

== 2 of 4 ==
Date: Wed, Feb 24 2010 11:22 am
From: Seebs

On 2010-02-24, jacob navia <jacob@nospam.org> wrote:
> gwowen a �crit :
>> Green Hills compiler 424 for ARM9 does not support that extension.

> You are talking nonse or just LYING

> I cite from
> http://www.ghs.com/news/20070131_compiler_version5.html

Can you check something for me in lcc-win?

If I have the code:
if (4 == 5) {
printf("You are talking nonse or just LYING\n");
}

will it usually produce output?

== 3 of 4 ==
Date: Wed, Feb 24 2010 11:23 am
From: Seebs

On 2010-02-24, jacob navia <jacob@nospam.org> wrote:
> The "Piccolo dsp" is not a stand alone processor and must be used with an
> ARM7 processor, a product line introduced in 1992, 7 YEARS BEFORE the C
> standard was out in 1999. We see here the bad faith of this people when
> complaining about C99.

I don't see how. I mean, we're still compiling for i386...

== 4 of 4 ==
Date: Wed, Feb 24 2010 11:28 am
From: Seebs

On 2010-02-24, Keith Thompson <kst-u@mib.org> wrote:
> jacob, if someone disagrees with you, please stop for just a moment
> and consider the possibility that they might not be deliberately
> lying.

http://work911.com/communication/miller.htm

"To understand what another person is saying, you must assume
that it is true and try to imagine what it could be true of."

This is an extremely effective strategy.

More useful than accusing gwowen of lying would be to observe that what he
said was definitely true *of the compiler he mentioned*, and then ask the
question of whether that compiler is generally relevant. I suspect it
probably is to many people.

Look at it this way: I do compiler support. We're about to take delivery
of a toolchain based on gcc 4.4.x. We are still supporting toolchains based
on gcc 3.4. We will be for some time. It's only relatively recently that a
majority of incoming support requests have involved the 4.x toolchains -- and
4.1.x may still be outnumbering 4.3.x in our world.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, February 24, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts