Common misconceptions about C (C95)

[Ioannis Vranos]

Not for many who do not like to rely on precedence or silly language
features. To many sizeof is a function and the HUGE majority of C code
assumes it too.

sizeof is not a function, it is an operator.

ptr = malloc(num * sizeof(*ptr));

is considered far more readable by many.


All very clever but most people use sizeof(*p) and from what I can see
there is no harm in that.

I'm yet to see a good reason for not using this way.

In the case of expressions, sizeof can only be used without parentheses.

However, an expression inside parentheses, is itself an expression.



For example:

int x;

size_t length= sizeof x;


length= sizeof(x);


In the case of sizeof x, x is the expression.

In the case of sizeof(x), (x) is the expression.





--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[frank]

For my part, given..

int x;
size_t length;
length = sizeof x; /* correct and beautiful */ length = sizeof(x);
/* correct but makes sizeof look like a function */ length = sizeof
(int); /* good use of parentheses */

Joe, you needed some newlines in there somehow

The ultimate form that Joe uses is the form recommended in H&S V.

 

[Ioannis Vranos]

No, they're not. The WHOLE POINT of Web pages is that they don't
depend on any particular hardware. The Web was thought up by a guy
who realised that there were lots and lots of people (well, okay, not
people - high-energy nuclear physicists, actually - but the principle
is the same) out there, with many many different kinds of system, who
needed to share data with each other *despite* those system
differences, and therefore they needed an information-sharing system
that did not depend on screen resolution, etc.

To put it another way: as a Web page designer, you are a server of
content. You don't get to choose what hardware the client uses. All
else being equal, if you provide content that looks ghastly on their
hardware because of your broken assumptions, they'll go to someone
else instead for their Web content.

And after all that, your Web page actually looks pretty good in my
browser:

http://www.cpax.org.uk/scratch/webshot.png


So what you'd really like is for anyone who wishes to read your Web
site to go out and buy a laptop like yours, yes? Well, that ain't
going to happen.

I ordered a brand new laptop yesterday. It should arrive today. It has
s 1280x800 display (which, frankly, I thought was unnecessarily
high). Despite being brand new, straight off the shelf, it has only
about half as many pixels as you say it should have. What do you
think I'm going to do? Send it back to the shop, and tell them "send
me a bigger screen; it turns out your normal model doesn't meet
Ioannis Vranos's Web page requirements"? Or do you think it's more
likely that I'll stick with what I've got?


That's nice. It's a bit like writing some instructions on how to open
a crate, and putting them *inside* the crate.

But if you write the page properly, it will run perfectly well on
resolutions of, say, 40x12. Which your page DOES, by the way. I
checked. It works fine.

The modern trend towards Web-page-as-fashion-statement instead of
Web-page-as-data is regrettable. Web-page-as-fashion-statement would
have you constantly updating your browser to take advantage of the
latest swish feature or updating your site to *demand* support for
the latest swish feature, and when would any of us ever have time to
get anything else done?

What I meant is that the pages display OK in other resolutions, but I
designed them for 1920x1080 resolution.



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Ioannis Vranos]

And after all that, your Web page actually looks pretty good in my
browser:

http://www.cpax.org.uk/scratch/webshot.png

Which program is your browser? Personally I viewed it with elinks, and it
doesn't appear pretty.

Is your system some old Mac?



Regards,

--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Oliver Jackson]

Option (1) is best but has a style issue.

(1) ptr = malloc(num * sizeof(*ptr));

It is lacking a space and has too many parens.

   ptr = malloc(num * sizeof *ptr);

is better form. The sizeof operator should never be followed immediately by '('
because it is not a function. Most arguments to sizeof do not require
parentheses. Only types, like 'sizeof (int)' do. I find 'sizeof(int)' ugly.

YEAH I been preaching that shit since 02! What I want to know is
that, how come all the big bad boys in this freaky biz don't listen?

 

[Keith Thompson]

Joe, you needed some newlines in there somehow

The newlines were there; your newsreader just didn't display them
properly. Joe's article had the following header line:

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

which seems like an odd combination, but it showed up correctly in
Gnus.

Quoting:
"""
For my part, given..

int x;
size_t length;
length = sizeof x; /* correct and beautiful */
length = sizeof(x); /* correct but makes sizeof look like a function */
length = sizeof (int); /* good use of parentheses */
"""

 

[Nick Keighley]

On Nov 18, 7:15 am, (e-mail address removed) (Kenny McCormack)

(The usual CLC arguments - seen many, many times over the years - snipped)

I understand these standard CLC arguments - I also understand the other
side of it.  

which is?

The point is that the "not casting the return value of
malloc()" thing is clearly a shibboleth.  That is, a thing by which the
in-crowd recognizes each other, and thus a thing you need to profess to
believe in order to be accepted in the in-crowd.

A point on Kenny's side is that at least one (and I think maybe two)
clc regulars do cast malloc(). One of them may be Plauger who writes
code that runs under both C and C++.

 

[Richard Tobin]

The sizeof operator should never be followed immediately by '('
because it is not a function. Most arguments to sizeof do not require
parentheses.

On the contrary, it should always use parentheses so as not to follow
C's mistake of having an operator which (unlike all the others) looks
like an identifier.

I find 'sizeof(int)' ugly.

I find "sizeof int" ugly.

In other words, it's just a matter of taste, with no "should"
about it.

-- Richard

 

[Nick Keighley]

Sounds to me idiotic not to cast. Strong typing better than weak
typing.

and casting *weakens* the effectiveness of the type system. Casting
turns off type checking.

But the cool, studly kids don't cast. I cast because I'm good
at C and I don't even use it much (which is a sign of a programmer
who's good at C, paradoxically enough).

riight. For the same reason I'm an expert pilot

 

[Nick Keighley]

Richard Harter a écrit :

If you care to search in the archives, Kenny has sometimes given
very good answers to questions posed here.

he occaisionally gives reasonable answers.


I liked the phrasing of this

I have posted code here, proposing a container library for C.

and just because someone doesn't like your container library doesn't
mean there's some sort of conspiracy against you.

Heathfield answered that he did not want to be involved
"with a looser"

I don't recall this could you give a cite?

and never participated in a meaningful way
in those discussions. Neither Mr Thompson, nor most of the
clique in c.l.c. They have nothing to say about an improvement
of C, or about software engineering or about just anything
positive.

I'm happy to discuss software engineering

I was surprised that the standards committee decided to fix asctime(),
and I suspect strongly that my personal campaign against it was
one of the reasons the committee decided to fix it. Heathfield and
the others of the clique were always trying to justify asctime()
misgivings or downplaying the issue's importantce.

this is untrue.

What the evolution of C is concerned, Heathfield (and Co) are
always complaining that standard C is not widely implemented,
ignoring all the implementations of the standard.

like? GCC still isn't fully compliant. Microsoft have no attempt to be
compliant.

Heathfield
uses a compiler version from the last century, and then it says
that gcc doesn't implement C99 even if he knows (as everybody
else) that C99 is quite well implemented in gcc, in the
linux versions at least.


Thousands of messages about those "questions" pollute this group
and the insistence of the regulars to discuss those "issues"
AD NAUSEAM makes this group specially boring.

yes, people should be pointed to the FAQ more often.

In my posts I try to improve the technical level of this group by discussing
interfaces, ways of doing things, abstract data types, etc. Neither
Mr Thompson nor Mr Heathfield are ever present in those discussions.

I read your posts.

This is your unjustified personal opinion.

....based on his posts

I could say that YOU
have no interest in C either. You never bring your code here, or
bring subjects about programming in C in general. Can you please
tell me when was the last time you proposed something to discuss here?

I wasn't aware this was a rule.

Thanks.


Obviously there are many other errors that could be dicussed. But
they aren't.

why don't you name some of them then. You have your own little hobby
horses. I don't really care about
asctime() for instance.

Only those are selected, to recognize who is a member
of their group.


Weeding the garden is the activity of failed philosophers, unable to
grasp what makes us human: Infinity.

your garden must be a mess

 

[Nick Keighley]

So? *First* decide the language you will write your code in, *then* design
your code. If you choose C, write C. If you choose some other language,
write in that language.

/If/ you choose C, then
  foo = malloc(n_foo * sizeof(*foo));
is the proper way to write the statement so that you can later change the
type of "foo" without (a) having to revise this statement, and (b) masking
other problems (like missing #include statements).

I've written code in C that was compiled with a C++ compiler. It
wasn't my idea but it goes on.

 

[Nick Keighley]

this could be argued, yes


I think you can do both early type assignment /and/ make it easy to
change types by using typedefs.

typedef int Call_identity;
typedef int Location_area;

Most data is either numbers, strings, or foreign keys.

er, stucts?

That's the level at
which the typical person requesting a program understands things.

not in terms of what the OO crowd would call classes?

 

[Nick Keighley]

I agree with your general point about "autopilot" programming, but in
this specific case I never bother with the parentheses because I so
rarely need them. On a relatively recent inspection of my code base I
found only *one* instance of sizeof being used on a type. (It is in a
much-used macro, safely tucked away in a header.) I don't consider it
particularly likely that I will need to do it again in the
foreseeable future, or even for a week or two after that. So I save
myself a miniscule amount of typing by omitting the parentheses.

and lose the time saved by typing

if (x == WONGA)
{
do_wonga_processing();
}

when the curly brackets are plainly not needed.

 

[Nick Keighley]

I think it used to be char*


ah, BCPL...

Nice come back.

For someone that professes no desire to be in a clique he sure uses the
"we" word an awful lot.

that's "we the C programming language" not "we the clique"

<snip>

 

[Nick Keighley]

Perhaps. But I don't think so. And contrary to the caricature, crazy
people don't usually have the ability to reply in verse, esp. not
comic verse.

one of my friends is crazy (in the diagnosed sense) and he writes
poetry. And some of it rhymes. And some of it's funny.

 

[Dik T. Winter]

> Heh. If I think back to C code in the past I know for a fact that if
> ever a function pointer does NOT resolve to a void * then there will be
> a LOT of broken systems out there should they be recompiled ...

In the part tons of code *have* been rewritten when ported to a different
machine, and not only for function pointers not being similar to void
pointers.

 

[Keith Thompson]

On the contrary, it should always use parentheses so as not to follow
C's mistake of having an operator which (unlike all the others) looks
like an identifier.

Perhaps C's mistake is having only *one* operator whose symbol looks
like an identifer. If C used "$" rather than "sizeof", this wouldn't
be an issue; similarly, if C had *more* operator keywords, "sizeof"
wouldn't be exceptional.

I've worked in languages where some operator symbols are punctuation,
and some are keywords. Ada, for example, has "not", "and", "or",
"mod", "rem", "abs", and probably others. Writing "not(x)" rather
than "not x" would be silly. In Perl, the distinction between
operators and built-in functions is a bit blurry.

And C's "return" could have been an operator, except that it's used to
form a statement rather than an expression. I don't use superfluous
parentheses either for "return x;" or for "sizeof x".

I find "sizeof int" ugly.

I find "sizeof int" to be a syntax error.

I consider "sizeof(type-name)" to be a different kind of expression
than "sizeof expr". In the latter, "sizeof" is the operator and
"expr" is the operand. In the former, the whole thing can be thought
of a nullary operator, one with no operands (a type name can't really
be an operand); it could easily have used a different syntax, like

In other words, it's just a matter of taste, with no "should"
about it.

Agreed. And as in all such matters, my taste is correct. }

 

[Keith Thompson]

this is untrue.

[...]

Is it? Which part? I've certainly argued that asctime()'s behavior
was already well defined, and that its problems, including its
undefined behavior given exotic arguments, are not terribly
important.

 

[Ben Bacarisse]

There is a silly reason for not using parentheses, and that is
that you somehow need to prove to the world that you know that
sizeof is an operator rather than a function.

Fortunately no one here does it for that reason!

There is point missing from your discussion: the fact that sizeof is
an operator is essential to understanding what it does in important
corner cases. If it were a function

if (numbers == NULL)
numbers = malloc(lots * sizeof(*numbers));

would be invalid -- functions have their arguments evaluated; sizeof
inhibits evaluation (in most cases). Some people choose to emphasise
this important information with spaces, but since some people have the
truly peculiar habit of spacing after a function name, I don't think a
space is sufficient. Omitting the parentheses does the job very well.

<snip>

 

[Kaz Kylheku]

On the contrary, it should always use parentheses so as not to follow
C's mistake of having an operator which (unlike all the others) looks
like an identifier.

C has other operators, like while, for, if, return, ...

These also differ from others in other regards: they are coupled to
special case syntax, and restricted in how they combine with others.
So they are not actually called operators, but in fact that is
what they are.

What makes ``return x;'' a statement? Simply the arbitrary restriction
that it requires a semicolon and can't be usd in the middle of an
expression.

For a model of (near) consistency, look at Lisp. In Lisp we have a
generic syntax which can model any syntax tree, and then the trees
are mapped onto any kind of construct. So the effect is that
statements, definitions, expressions, et ceteral all look uniform.

(defclass c (a b) ...) ;; class c with bases a b

(let (a b) ...) ;; lexical variables a b

(a b) ;; call function a with argument b

(dolist (a b) ...) ;; loop variable a over list b

A program is just a tree of symbols, lists, string literals, numbers and other
things, so let's just annotate the tree as a bracketed list, with some
kind of lexical syntax for the symbols, string literals, numbers, etc.

So, if you learn the above, then you can ``get over'' whatever esthetic
issues you have with other languages, like sizeof being ugly in C.

All ugliness acn be traced to people trying to be clever with how they
mangle the nice and uniform abstract syntax tree into some kind of soup
of different competing lexical conventions.