what is difference between sizeof and strlen

[Keith Thompson]

Re: what is difference between sizeof and strlen

"Emmanuel Delahaye" <emdel@YOURBRAn oos.fr> writes:[color=blue]
> Anton Petrusevich wrote on 08/08/05 :[color=green][color=darkred]
>>> "Undefined behaviour" is a technical term in the C standard. It's not
>>> really relevant whether *you* would call it that.[/color]
>>
>> I don't get it. I thought, and I still continue to think, that "undefined
>> behaviour" means just that: when the behaviour is undefined. If the
>> behaviour is dependent on some defined thing (platform) then it's
>> "defined". You (or I) just need to know the platform. Of course, there's no
>> such (defined) thing as "platform" in C standard, so they say "undefined
>> behaviour". "int main()" is a tough religion, isn't it?[/color]
>
> No matter what you think. Just stick to the facts. The C standard
> defines a number of behaviours. Some others are clearly under the
> responsability of the implementation (implementation-dependent). The
> rest is simply 'undefined'. It's a fact. Period. There is nothing
> really to argue about it.
>
> What is undefined can do anything. The result is not predictable and
> not reproducable. It's a bug. Period.[/color]

To clarify (and disagree slightly) ...

The phrase "undefined behavior", as used in this newsgroup, refers to
behavior that is not defined by the C standard. Such behavior might
or might not be defined by something else (the hardware, some
secondary standard, or whatever).

As far as the C standard is concerned, code that exhibits undefined
behavior can do anything; we jokingly talk about it making demons fly
out your nose. This doesn't mean that nasal demons are a real
possibility, just that if demons *do* fly out your nose it doesn't
mean the C implementation is non-conforming.

In some cases, it can make sense to do something that's UB as far as
the C standard is concerned, *if* you have some other guarantee that
it will behave as you expect. You just need to be aware that the code
is non-portable -- and you should probably spend some time thinking
about whether there's a portable way to do it (sometimes there isn't).

For example, a union of a double and a struct containing carefully
defined bitfields can be a good way to get at the components of a
floating-point variable (sign, exponent, mantissa) -- but only at the
risk of having the code break when you port it, or when you upgrade to
a new compiler, or when your sysadmin upgrades your compiler behind
your back.

In other cases, undefined behavior is truly dangerous with no
corresponding benefit. For example, gets() cannot be used safely; it
will overflow your input buffer at the whim of the user.

It can also be useful to understand the *likely* consequences of
particular forms of undefined behavior, in general or for a particular
platform. An example I've mentioned here before is void main(); it
invokes undefined behavior, and it should be corrected, but if your
program is blowing up on line 137 you should also look elsewhere for
the cause.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tim Rentsch]

Style isn't always religious

Chris Dollin <kers@hpl.hp.co m> writes:
[color=blue]
> Now, if you want /religious/ arguments, indentation, tab-size, global
> variables, ncspellingOfVar iableNames, i++ vs ++i vs i += 1, for(;;) vs
> while(1), &co, all seem to be waiting, fuel-soaked and steaming gently,
> in the wings.[/color]

Discussions about formatting and layout (not to mention the
others) often take on a "religious" tone, but they don't
have to. As an example consider the question of where to
put closing braces. Here are two common alternatives:


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice A */


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice B */


(To simplify the question we consider only these two
choices, and ignore the question of where to put the opening
brace; please imagine opening braces to be placed where
ever you believe they are most appropriate.)

Which choice do you prefer and why?

If your answer is along the lines of "choice A looks more
natural to me, so I write using choice A" -- that's a
statement that has a good chance of leading to a "religious"
argument.

If your answer is along the lines of "choice B is what I'm
used to, and choice A looks funny, so of course I write
using choice B (muttering 'any sensible person would') --
that's a statement that has a good chance of leading to a
"religious" argument.

If your answer is along the lines of "there have been
studies done on this question, and all the studies I'm aware
of have concluded that choice B has lower error rates;
lower errors rates are clearly beneficial, and I write using
choice B for that reason" -- that's a statement that is less
likely to lead to a "religious" argument.

If your answer is along the lines of "our in-house coding
standards mandate use of choice A; I don't have any
preference for either choice, except that I prefer to keep
my job, so I write using choice A" -- that's a statement
that is less likely to lead to a "religious" argument (even
if it might be less than completely satisfactory for other
reasons).

We've all heard and read so many times (including even the
original K&R) statements to the effect that questions of
style are just personal preference, and can't be resolved
one way or the other, that we accept these statements as
fact. Worse, whenever there is an unresolvable difference
in minor programming choices, it often gets chalked up as a
"style preference". I don't mean to suggest that there is
always a single "right" answer; to the contrary, different
people have different weighting functions for the costs and
benefits of various style guidelines (or other development
practices) and a choice that's a net win for me might very
well turn out to be a net loss for one of my co-workers.

However, we can try to be objective about what the costs and
benefits are for different choices; if the C&B are person
dependent, so be it, but those statements also can be made
objective. The main thing is attitude. If someone insists
on saying nothing more than "choice X seems right to me"
then that someone is encouraging "religious" discussion.
Conversely, trying to find a rational basis for choices
made, and to be objective about both the costs and the
benefits of each of the different choices possible, is more
likely to lead to shared understanding of what choices to
make, and why.

The C development community is both very diverse and (I
believe) very emphatic in their opinions, both individual
and collective; hence the comments here are especially
important for developers working in C.

[Baxter]

Re: Style isn't always religious

"Style" should aid readability. Translate those marks into words and
punctuation and see how it reads.

For instance:
var++;
or
++var;

Translated into English:
"var increment."
vs.
"increment var."

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------



"Tim Rentsch" <txr@alumnus.ca ltech.edu> wrote in message
news:kfnslwwlxb j.fsf_-_@alumnus.calte ch.edu...[color=blue]
> Chris Dollin <kers@hpl.hp.co m> writes:
>[color=green]
> > Now, if you want /religious/ arguments, indentation, tab-size, global
> > variables, ncspellingOfVar iableNames, i++ vs ++i vs i += 1, for(;;) vs
> > while(1), &co, all seem to be waiting, fuel-soaked and steaming gently,
> > in the wings.[/color]
>
> Discussions about formatting and layout (not to mention the
> others) often take on a "religious" tone, but they don't
> have to. As an example consider the question of where to
> put closing braces. Here are two common alternatives:
>
>
> if/for/while ...
> ... body line goes here ...
> ... another body line goes here ...
> ...
> } /* choice A */
>
>
> if/for/while ...
> ... body line goes here ...
> ... another body line goes here ...
> ...
> } /* choice B */
>
>
> (To simplify the question we consider only these two
> choices, and ignore the question of where to put the opening
> brace; please imagine opening braces to be placed where
> ever you believe they are most appropriate.)
>
> Which choice do you prefer and why?
>
> If your answer is along the lines of "choice A looks more
> natural to me, so I write using choice A" -- that's a
> statement that has a good chance of leading to a "religious"
> argument.
>
> If your answer is along the lines of "choice B is what I'm
> used to, and choice A looks funny, so of course I write
> using choice B (muttering 'any sensible person would') --
> that's a statement that has a good chance of leading to a
> "religious" argument.
>
> If your answer is along the lines of "there have been
> studies done on this question, and all the studies I'm aware
> of have concluded that choice B has lower error rates;
> lower errors rates are clearly beneficial, and I write using
> choice B for that reason" -- that's a statement that is less
> likely to lead to a "religious" argument.
>
> If your answer is along the lines of "our in-house coding
> standards mandate use of choice A; I don't have any
> preference for either choice, except that I prefer to keep
> my job, so I write using choice A" -- that's a statement
> that is less likely to lead to a "religious" argument (even
> if it might be less than completely satisfactory for other
> reasons).
>
> We've all heard and read so many times (including even the
> original K&R) statements to the effect that questions of
> style are just personal preference, and can't be resolved
> one way or the other, that we accept these statements as
> fact. Worse, whenever there is an unresolvable difference
> in minor programming choices, it often gets chalked up as a
> "style preference". I don't mean to suggest that there is
> always a single "right" answer; to the contrary, different
> people have different weighting functions for the costs and
> benefits of various style guidelines (or other development
> practices) and a choice that's a net win for me might very
> well turn out to be a net loss for one of my co-workers.
>
> However, we can try to be objective about what the costs and
> benefits are for different choices; if the C&B are person
> dependent, so be it, but those statements also can be made
> objective. The main thing is attitude. If someone insists
> on saying nothing more than "choice X seems right to me"
> then that someone is encouraging "religious" discussion.
> Conversely, trying to find a rational basis for choices
> made, and to be objective about both the costs and the
> benefits of each of the different choices possible, is more
> likely to lead to shared understanding of what choices to
> make, and why.
>
> The C development community is both very diverse and (I
> believe) very emphatic in their opinions, both individual
> and collective; hence the comments here are especially
> important for developers working in C.[/color]

[Richard Tobin]

Re: Style isn't always religious

In article <11gudpgmg6jr38 8@corp.supernew s.com>,
Baxter <lbax02.spamgua rd@baxcode.com> wrote:[color=blue]
>"Style" should aid readability. Translate those marks into words and
>punctuation and see how it reads.
>
>For instance:
> var++;
> or
> ++var;
>
>Translated into English:
> "var increment."
> vs.
> "increment var."[/color]

But you haven't translated it, you have just transliterated it according
to your idiosyncratic correspondence between C tokens and English
words. I don't use such a transliteration , so I don't find the difference
in readability you suggest.

-- Richard

[Michael Wojcik]

Re: Style isn't always religious


[Heavily snipped for the sake of concision; hopefully I've retained
the flavor of Tim's post.]

In article <kfnslwwlxbj.fs f_-_@alumnus.calte ch.edu>, Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
>
> As an example consider the question of where to put closing braces....
>
> Which choice do you prefer and why?
>
> ... "choice A looks more natural to me, so I write using choice A"
> [is likely to lead to a religious argument]
>
> "choice B is what I'm used to, and choice A looks funny, so of
> course I write using choice B" [religious]
>
> "there have been studies done on this question, and all the studies
> I'm aware of have concluded that choice B has lower error rates"
> [less religious]
>
> "our in-house coding standards mandate use of choice A"
> [less religious][/color]

True, and there are other possible answers with varying degrees of
subjectivity. For example, I use vi-derived editors; those editors
have useful commands for finding braces in the first column, so I
always write functions with their opening and closing braces in the
first column. That particular choice is not especially subjective,
though my choice of tool is.

Because my function-body braces are indented at the same level as
their "controllin g" line of code, I also like to indent opening and
closing braces for control structures at the same level as their
controlling line. That *is* subjective, but I have a slightly
stronger justification for it (consistency) than a simple "it looks
better to me".

Obviously, though, deciding "how subjective" any of these arguments
are (or even what metric to use for gauging subjectivity) is itself a
subjective matter. So while I think many of us can agree that there
are some reasons for style choices which are less idiosyncratic and
more rational than others, arriving at a consensus on how to rank
specific reasons could be difficult.

I don't think that means the question should just be abandoned - I
still find it interesting - but it is a difficulty.

--
Michael Wojcik michael.wojcik@ microfocus.com

Push up the bottom with your finger, it will puffy and makes stand up.
-- instructions for "swan" from an origami kit

[Richard Heathfield]

Re: Style isn't always religious

Baxter said:
[color=blue]
> "Style" should aid readability. Translate those marks into words and
> punctuation and see how it reads.
>
> For instance:
> var++;[/color]

This reads "var plus plus" to me.
[color=blue]
> or
> ++var;[/color]

And that reads "plus plus var".

Really, that's how I say them in my head thing. I have no particular
preference of one over the other in places where either may be used. In
C++, I would tend (paradoxically! ) to use ++var, and I suspect this is
rubbing off in my C code too, even though I don't use C++ terribly often
and thus have little reason to develop this "habit".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999

http://www.cpax.org.uk

Email rjh at the above domain

[Tim Rentsch]

Re: Style isn't always religious

richard@cogsci. ed.ac.uk (Richard Tobin) writes:
[color=blue]
> In article <11gudpgmg6jr38 8@corp.supernew s.com>,
> Baxter <lbax02.spamgua rd@baxcode.com> wrote:[color=green]
> >"Style" should aid readability. Translate those marks into words and
> >punctuation and see how it reads.
> >
> >For instance:
> > var++;
> > or
> > ++var;
> >
> >Translated into English:
> > "var increment."
> > vs.
> > "increment var."[/color]
>
> But you haven't translated it, you have just transliterated it according
> to your idiosyncratic correspondence between C tokens and English
> words. I don't use such a transliteration , so I don't find the difference
> in readability you suggest.[/color]

The important thing is that he explained his metric. This
particular metric may be somewhat person-dependent, and you
might think it's not an especially good metric for measuring
readability, but at least we know what it is.

The problem with the response is it doesn't counter-propose
a different metric. If all you say is "I don't find it
readable", that moves the discussion in the direction of
being more "religious" . Conversely, to move the discussion
in the direction of being less "religious" , suggest a
different metric. Sometimes this requires a bit of
introspection to discover what qualities are important. But
however you come up with one, if you want the discussion to
stay in the rational half plane rather than the "religious"
half plane, it's important to offer another metric for
consideration.

By the way, I don't think using "increment" for '++' is
especially idiosyncratic. I expect many C developers might
say something along these lines, and essentially all would
understand it if they heard it or read it. But that's
incidental to the main point about proposing another metric
in response.

[Baxter]

Re: Style isn't always religious


"Tim Rentsch" <txr@alumnus.ca ltech.edu> wrote in message
[color=blue]
>
> By the way, I don't think using "increment" for '++' is
> especially idiosyncratic. I expect many C developers might
> say something along these lines, and essentially all would
> understand it if they heard it or read it. But that's
> incidental to the main point about proposing another metric
> in response.[/color]

"++" is known as the "increment operator". It can be either prefix or
postfix.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------

[akarl]

Re: Style isn't always religious

Tim Rentsch wrote:[color=blue]
> Chris Dollin <kers@hpl.hp.co m> writes:
>
>[color=green]
>>Now, if you want /religious/ arguments, indentation, tab-size, global
>>variables, ncspellingOfVar iableNames, i++ vs ++i vs i += 1, for(;;) vs
>>while(1), &co, all seem to be waiting, fuel-soaked and steaming gently,
>>in the wings.[/color]
>
>
> Discussions about formatting and layout (not to mention the
> others) often take on a "religious" tone, but they don't
> have to. As an example consider the question of where to
> put closing braces. Here are two common alternatives:
>
>
> if/for/while ...
> ... body line goes here ...
> ... another body line goes here ...
> ...
> } /* choice A */
>
>
> if/for/while ...
> ... body line goes here ...
> ... another body line goes here ...
> ...
> } /* choice B */[/color]

With tools like GNU Indent the whitespace issues of coding style is not
very important as the code can be transformed to anyones liking.

August

[Richard Bos]

Re: Style isn't always religious

Richard Heathfield <invalid@invali d.invalid> wrote:
[color=blue]
> Baxter said:
>[color=green]
> > "Style" should aid readability. Translate those marks into words and
> > punctuation and see how it reads.
> >
> > For instance:
> > var++;[/color]
>
> This reads "var plus plus" to me.
>[color=green]
> > or
> > ++var;[/color]
>
> And that reads "plus plus var".
>
> Really, that's how I say them in my head thing.[/color]

YAMeAICM5Euros.

Richard

[Mabden]

Re: Style isn't always religious

> "Baxter" <lbax02.spamgua rd@baxcode.com> wrote in message
news:11h185es93 u7h2a@corp.supe rnews.com...[color=blue][color=green][color=darkred]
> > >"Style" should aid readability. Translate those marks into words[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > >punctuation and see how it reads.
> > >
> > >For instance:
> > > var++;
> > > or
> > > ++var;
> > >
> > >Translated into English:
> > > "var increment."
> > > vs.
> > > "increment var."
> > >[/color]
> > "Tim Rentsch" <txr@alumnus.ca ltech.edu> wrote in message[/color]
>[color=green]
> >
> > By the way, I don't think using "increment" for '++' is
> > especially idiosyncratic. I expect many C developers might
> > say something along these lines, and essentially all would
> > understand it if they heard it or read it. But that's
> > incidental to the main point about proposing another metric
> > in response.[/color]
>
> "++" is known as the "increment operator". It can be either prefix or
> postfix.[/color]

I don't like postfix on a single variable. I always see it as:
var++ : Do nothing with var, then increment var before the next
instruction.

Instead of just doing what you are there to do:
++var : Increment var.

No need to wait until after "var;" is executed (a null operation), IMO.

--
Mabden

[Michael Wojcik]

Re: Style isn't always religious


In article <otiQe.145089$d P1.501277@newsc .telia.net>, akarl <fusionfive@com hem.se> writes:[color=blue]
>
> With tools like GNU Indent the whitespace issues of coding style is not
> very important as the code can be transformed to anyones liking.[/color]

This plays havoc with typical source-code change control mechanisms,
as it produces a vast number of non-substantive changes, which in
turn makes it difficult to identify the substantive ones. While
the change control software will happily deal with a revision where
90% of the lines have changed, human maintainers will not.

--
Michael Wojcik michael.wojcik@ microfocus.com

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen

[Richard Heathfield]

Re: Style isn't always religious

Michael Wojcik said:
[color=blue]
>
> In article <otiQe.145089$d P1.501277@newsc .telia.net>, akarl
> <fusionfive@com hem.se> writes:[color=green]
>>
>> With tools like GNU Indent the whitespace issues of coding style is not
>> very important as the code can be transformed to anyones liking.[/color]
>
> This plays havoc with typical source-code change control mechanisms,
> as it produces a vast number of non-substantive changes, which in
> turn makes it difficult to identify the substantive ones.[/color]

Well, that's easily fixed. On checking out, you indent the code to your
liking. Before checking in, you indent it to the house style. Problem
solved.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999

http://www.cpax.org.uk

Email rjh at the above domain

[Tim Rentsch]

Re: Style isn't always religious

mwojcik@newsguy .com (Michael Wojcik) writes:
[color=blue]
> [Heavily snipped for the sake of concision; hopefully I've retained
> the flavor of Tim's post.]
>
> In article <kfnslwwlxbj.fs f_-_@alumnus.calte ch.edu>, Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
> >
> > As an example consider the question of where to put closing braces....
> >
> > Which choice do you prefer and why?
> >
> > ... "choice A looks more natural to me, so I write using choice A"
> > [is likely to lead to a religious argument]
> >
> > "choice B is what I'm used to, and choice A looks funny, so of
> > course I write using choice B" [religious]
> >
> > "there have been studies done on this question, and all the studies
> > I'm aware of have concluded that choice B has lower error rates"
> > [less religious]
> >
> > "our in-house coding standards mandate use of choice A"
> > [less religious][/color]
>
> True, and there are other possible answers with varying degrees of
> subjectivity. For example, I use vi-derived editors; those editors
> have useful commands for finding braces in the first column, so I
> always write functions with their opening and closing braces in the
> first column. That particular choice is not especially subjective,
> though my choice of tool is.[/color]

I would put this under the heading of "increased productivity."
Putting function open braces at the left edge is a better match
to your tools, and so allows you to write code faster (or write
code at the same rate, but with less effort, which is almost the
same thing).

[color=blue]
> Because my function-body braces are indented at the same level as
> their "controllin g" line of code, I also like to indent opening and
> closing braces for control structures at the same level as their
> controlling line. That *is* subjective, but I have a slightly
> stronger justification for it (consistency) than a simple "it looks
> better to me".[/color]

Other things being equal, more consistent expression is normally
better, again because more consistency usually translates into
increased productivity.

Of course there is the qualifying phrase, "other things being
equal". For myself I find that putting opening braces on lines
by themselves lowers my productivity, both because my eyes have
to work a little bit harder skipping the extra vertical space
and because my hands and fingers have to work a little bit
harder doing "page turning" (scrolling commands). It's also
possible (less common, but possible) to put a line of code on
the same line as an open brace, which doesn't use any extra
vertical space. I find this form also lowers my productivity
somewhat, although for different reasons; the most obvious is
what work needs to be done in an editor when cutting/pasting,
etc. I haven't done objective measurements; I'm confident
though that objective measurements would bear out my informal
observations.

In this particular area, consistency has moved me in the other
direction: open braces for functions go just after the close
parenthesis following the function parameters. This placement
seems more consistent with K&R-style placement; given how other
braces are placed in K&R, I suspect they would have put braces
at the end of the line with function parameters if the
ANSI-style function prototypes had been used in the original
language. I don't usually use vi-based tools, so that isn't a
factor for me. It seems to me that some vi-based tools offer
some degree of extensibility/programmability ; can commands be
added that know how to deal with function braces placed at the
end of the line for function parameters?

[color=blue]
> Obviously, though, deciding "how subjective" any of these arguments
> are (or even what metric to use for gauging subjectivity) is itself a
> subjective matter. So while I think many of us can agree that there
> are some reasons for style choices which are less idiosyncratic and
> more rational than others, arriving at a consensus on how to rank
> specific reasons could be difficult.[/color]

There are two factors: what is the metric, and is the metric
"any good"? Sometimes there are multiple metrics, in which
case some sort of weighting function of the different metrics
is taken; this situation can be thought of as just one larger,
more elaborate, metric.

The first question, "what is the metric?", is most often
answered in one of three ways: increased productivity, lower
defect rate, or better expression of programmer intent. (The
expression of programmer intent usually is expected to yield
improvements in the other areas, either directly, or indirectly
through improved team morale, lower turnover, or other similar
factors.) Each of these can be measured, and measured fairly
objectively. Note that the "expression of programmer intent"
needs to be measured relative to the set of people who will be
reading the code in question, perhaps by having questionnaire
surveys done; but still it can be measured.

The second question, "is the metric any good?", isn't an
objective question, and doesn't have to be. Whether a metric is
good or not depends on the goals of the group or company writing
the software, and those goals can change from company to
company, or even in the same company over time or from project
to project. Naturally we would like there to be agreement that
a particular metric is the right choice; even without that,
however, there is great value in having shared understanding of
what metric is to be followed, or what metrics are being
proposed. The key first step is to make the metrics explicit
rather than left as unstated assumptions.

[color=blue]
> I don't think that means the question should just be abandoned - I
> still find it interesting - but it is a difficulty.[/color]

Certainly it's difficult to reach unanimous agreement or even
just consensus. What I think is the important point is that
making the metrics objective and explicit allows the discussion
to proceed, rather than get stalled as often happens otherwise.

[Ben Pfaff]

Re: Style isn't always religious

Richard Heathfield <invalid@invali d.invalid> writes:
[color=blue]
> On checking out, you indent the code to your
> liking. Before checking in, you indent it to the house style. Problem
> solved.[/color]

Does anyone do this in practice? I have not, but I suspect that
it would lead to a large number of whitespace-only changes,
because adherence to style is not normally done religiously.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}