Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: programi parsing question

Reply
Thread Tools

Re: programi parsing question

 
 
Willem
Guest
Posts: n/a
 
      08-06-2008
Phlip wrote:
) I suspect there are style guidelines saying "always initialize every variable".
) Maybe they only apply to C++, and C is exempt.

On the other hand, explicitly not initializing variables give static code
analyzers the chance to find uses of uninitialized variables. (As opposed
to uses of default-but-wrong-initialized values).


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
 
Reply With Quote
 
 
 
 
fjblurt@yahoo.com
Guest
Posts: n/a
 
      08-06-2008
On Aug 6, 5:49 am, CBFalconer <(E-Mail Removed)> wrote:
> santosh wrote:
> > CBFalconer wrote:
> >> (E-Mail Removed) wrote:

>
> >>> void fooB(void) {
> >>> int fd = open(...);
> >>> if (fd < 0) {
> >>> fail();
> >>> }
> >>> }

>
> >> Considering the crosspost, I won't complain about using the
> >> non-standard open in place of fopen. However it is inappropriate
> >> on comp.programming.

>
> > You surely mean comp.lang.c?

>
> No. My last sentence referred to the subject, not the open. My
> fault for failing to be sufficiently specific. The question about
> formatting was relevant on c.l.c.


Insofar as this is a discussion about programming style, which applies
to any language which allows variables to be initialized, it seemed to
me that it was still on-topic for comp.programming. I agree that the
behavior of historical versions of C is not.

Non-c.u.p readers worried about the `open' function may read it as an
arbitrary function returning `int', which has significant side
effects, and for which a negative return value indicates some
unspecified sort of "failure". The choice of 'fd' for the variable
holding its return value is likewise an arbitrary choice. Any
similarity to actual functions, living or dead, is purely
coincidental.
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      08-06-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> On Aug 6, 5:49 am, CBFalconer <(E-Mail Removed)> wrote:
>> santosh wrote:
>> > CBFalconer wrote:
>> >> (E-Mail Removed) wrote:

>>
>> >>> void fooB(void) {
>> >>> int fd = open(...);
>> >>> if (fd < 0) {
>> >>> fail();
>> >>> }
>> >>> }


<snip>

> Non-c.u.p readers worried about the `open' function may read it as an
> arbitrary function returning `int', which has significant side
> effects, [ ... ]


Since these side effects have not been specified, nor are derivable from
anything in the C Standard, the function effectively invokes undefined
behaviour, and there is very little that can be said about the program,
from that point onwards. Therefore the previous "non-portable" verdict
now becomes "undefined" and thus, "no comment".

<snip>

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      08-06-2008
santosh <(E-Mail Removed)> writes:
> (E-Mail Removed) wrote:
>
>> On Aug 6, 5:49 am, CBFalconer <(E-Mail Removed)> wrote:
>>> santosh wrote:
>>> > CBFalconer wrote:
>>> >> (E-Mail Removed) wrote:
>>>
>>> >>> void fooB(void) {
>>> >>> int fd = open(...);
>>> >>> if (fd < 0) {
>>> >>> fail();
>>> >>> }
>>> >>> }

>
> <snip>
>
>> Non-c.u.p readers worried about the `open' function may read it as an
>> arbitrary function returning `int', which has significant side
>> effects, [ ... ]

>
> Since these side effects have not been specified, nor are derivable from
> anything in the C Standard, the function effectively invokes undefined
> behaviour,


Something which can be invoked is still necessarily defined.
Indepedently of this, your statement means any use of an identifier
not defined by the C-standard implies that the behaviour of the
program using the identifier must be undefined, or shorter, that
programming in C is not possible.

Follow-up ignored for obvious reasons. Ludcicrous claims about C are
(at best) on topic in clc.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-06-2008
Rainer Weikusat wrote:

> santosh <(E-Mail Removed)> writes:
>> (E-Mail Removed) wrote:
>>
>>> On Aug 6, 5:49 am, CBFalconer <(E-Mail Removed)> wrote:
>>>> santosh wrote:
>>>> > CBFalconer wrote:
>>>> >> (E-Mail Removed) wrote:
>>>>
>>>> >>> void fooB(void) {
>>>> >>> int fd = open(...);
>>>> >>> if (fd < 0) {
>>>> >>> fail();
>>>> >>> }
>>>> >>> }

>>
>> <snip>
>>
>>> Non-c.u.p readers worried about the `open' function may read it as
>>> an arbitrary function returning `int', which has significant side
>>> effects, [ ... ]

>>
>> Since these side effects have not been specified, nor are derivable
>> from anything in the C Standard, the function effectively invokes
>> undefined behaviour,

>
> Something which can be invoked is still necessarily defined.
> Indepedently of this, your statement means any use of an identifier
> not defined by the C-standard implies that the behaviour of the
> program using the identifier must be undefined, or shorter, that
> programming in C is not possible.


I suppose you didn't not my smiley at the end?

> Follow-up ignored for obvious reasons. Ludcicrous claims about C are
> (at best) on topic in clc.


Hmm, seems my newsreader added followups to c.u.p automatically. Am
setting followups to clc, since this thread long ago ceased to be
topical on cup.

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      08-06-2008
(E-Mail Removed) wrote, On 06/08/08 05:38:
> Crossposting this to comp.lang.c because it's become relevant.
>
> Our story so far, for c.l.c people:
>
> There is a discussion about the stylistic advantages and disadvantages
> of the following two snippets:
>
> void foo (void) {
> int fd;
> if ((fd = open(...)) < 0) {
> fail();
> }
> }
>
> versus
>
> void foo (void) {
> int fd = open(...);
> if (fd < 0) {
> fail();
> }
> }
>
> Phlip prefers the latter, and claims that the former gained popularity
> because early versions of C did not guarantee the order in which
> initializations occurred, or had other problems, and therefore
> initializations in declarations were discouraged.


I also prefer the latter but cannot comment on the reasons why the
former is often used. I refer the latter for the following reasons:

I like initialising on declaration, no chance of using it uninitialised

I like separating out assignment from test for readability

This is purely personal preference. It is not something I would normally
comment on either way when looking at code on comp.lang.c (although if
providing an alternative piece of code I might use my preference).

<snip>

> For an assignment like our example that involves a nontrivial function
> call, I think most people would not expect to see it in an
> initializer,


Well, they would be surprised by some of my code then

> because oftentimes nontrivial function calls will require
> more computations to be done first, even though this example happens
> not to.


<snip>

struct vector required_thrust(struct pos mypos) {
int x = funcky_function();
int y = clever_stuff();
int z = get_altitude();
struct target_vector = calc_relative_pos(mypos,x,y,z)

/* calculate and return thrust vector */
}

The "more computations to be done first" are not always a problem.
--
Flash Gordon
 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      08-07-2008
On Aug 6, 2:11*pm, Chris Dollin <(E-Mail Removed)> wrote:
> CBFalconer wrote:
> > ... I
> > disapprove of initialization code more complex than a
> > simple value, such as 0, and discourage even that.

>
> You're bonkers.


Perhaps like the clock that ' s right twice a day ,CBF
has the right idea on this issue
.

OP ' s question seems to be :which is less objectionable
? An initialization in the declaration section ,or an
assignment embedded inside the predicate of an" if `
.Obviously ,you needn ' t do either :you could consume
an extra line of vertical space by placing variable
declaration ,assignment ,and" if `all on separate
lines
.The code is almost the same in each case ,and very
self - explanatory ;the only concerns ,therefore ,are
( minor )readability issues
.Doing the" fopen `in the declarations is very bad
:you separate the function which needs error - checking
from its error - checking
;embedding an assignment in a predicate is slightly
bad :you end up with a long line ,slightly hard - to
- read because of( otherwise - unneeded )parentheses
;using a third line to avoid these faults is( very
very slightly )bad
:you waste vertical space ,and slightly less code will
fit on the screen or page
.Thus readability is always about tradeoffs

.I ,personally ,avoid initializers for several reasons
and would regard that version as by far the worst

.As to saving vertical space by using more complicated
expressions ,each case needs to be judged on its own
merits
.The case where I ' m likely to use OP ' s formula is
when it simplifies the surrounding syntax ,for example ,by
replacing an" else { ... if } `with an" else if `as in
:
if (!strcmp(filename, "-")) {
infile = stdin;
} else if ((infile = fopen(filename, "r"))) {
printf("Opened %s\n", filename);
} else {
/* he didn ' t give us a valid file :try to
* teach him a lesson
* .
*/
system("format c:");
}
Since we ' re on the topic of minor stylistic issues ,note
that I arranged spaces and braces in the above code
fragment using the One True Style(tm) for C code
.Some of us oldsters are set in our ways ,but you
youngsters should adopt it ,if you have a choice
.The point isn ' t ,so much ,that One True Style(tm) is
slightly better than alternatives( though it is
! )but that standards are *useful*
!! Why should one have to adapt to every Tom ,Dick ,or
Harry who has a peculiar fetish for arranging white space
in C code
? We don ' t do that in English
.I might think it adds clarity to use different quote marks
for beginning and ending of quotes( as we do in" real `text
) but others don ' t do this in Ascii ;I might think that
commas ,representing spoken pauses ,belong
before the word that causes the pause ,but I don ' t write
that way ,except now ,to make a point
.Some will object that there is no style standard ,that
it ' s a messy world out there ,and the C community hasn ' t
settled on a proper arrangement for white space
.You ' ll have trouble convincing many of us of that
.Essentially all The Great Names(tm) in C programming
use the One True Style(tm) ;and when the topic arose in
this ng ,the 2 or 3 most respected posters here admitted (
after wasting bandwidth on the obvious :follow the
employer ' s dicta ,don ' t change the style of existing code
) that they prefer One True Style(tm)
.

I hope that the way I ' ve arranged white space around the
punctuation in this message annoys some of you ,and makes you
think I ' m an idiot
.Then you ' ll know how some of your C code appears to me
.

Hope this helps ,
James Dow Allen
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-07-2008
James Dow Allen wrote:

> On Aug 6, 2:11*pm, Chris Dollin <(E-Mail Removed)> wrote:
>> CBFalconer wrote:
>> > ... I
>> > disapprove of initialization code more complex than a
>> > simple value, such as 0, and discourage even that.

>>
>> You're bonkers.

>
> Perhaps like the clock that ' s right twice a day ,


A clock cannot be right twice a day.

<snip>

What's happened to your formatting? There are all sorts of colons and
semi-colons, commas after a space, fullstops after a newline,
mismatched quote characters etc.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-07-2008
James Dow Allen wrote:

<snip>

> I hope that the way I ' ve arranged white space around the
> punctuation in this message annoys some of you ,and makes you
> think I ' m an idiot
> .Then you ' ll know how some of your C code appears to me
> .


Ah, okay, I didn't read this bit. Ignore my previous message please.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-07-2008
Richard Heathfield wrote:

> santosh said:
>
>> James Dow Allen wrote:
>>
>>> On Aug 6, 2:11 pm, Chris Dollin <(E-Mail Removed)> wrote:
>>>> CBFalconer wrote:
>>>> > ... I
>>>> > disapprove of initialization code more complex than a
>>>> > simple value, such as 0, and discourage even that.
>>>>
>>>> You're bonkers.
>>>
>>> Perhaps like the clock that ' s right twice a day ,

>>
>> A clock cannot be right twice a day.

>
> A /stopped/ clock can be right twice a day.


Oops yes, I see that you mean a 12-hour clock. I was thinking about the
case of a 24-hour clock, which is strange, since I myself use 12-hour
ones.

<snip>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: programi parsing question Phlip C Programming 41 08-15-2008 04:22 PM
[ANN] Parsing Tutorial and YARD 1.0: A C++ Parsing Framework Christopher Diggins C++ 0 07-09-2007 09:01 PM
[ANN] Parsing Tutorial and YARD 1.0: A C++ Parsing Framework Christopher Diggins C++ 0 07-09-2007 08:58 PM
SAX Parsing - Weird results when parsing content between tags. Naren XML 0 05-11-2004 07:25 PM
Perl expression for parsing CSV (ignoring parsing commas when in double quotes) GIMME Perl 2 02-11-2004 05:40 PM



Advertisments