Common misconceptions about C (C95)

[Keith Thompson]

Interesting that it has *no* values, since it could hold one
without requiring any space.

Yes, but how would that be useful?

 

[Seebs]

As of the last committee meeting, it now has "alignof", too.

Man, I am missing all the fun.

I just have to know: Was that a Thursday afternoon decision?

-s

 

[Ioannis Vranos]

C99 does the same thing, of course (I had forgotten about that).

Except that they're macros, not keywords, but it's the same idea.

Yes, macros in C, built in keywords in C++.

Or you can just write:

#include <iso646.h>
int main(void)
{
int x=5, y= 4, a=0;
/* ... */
if(x> 1 and y< 2)
/* Do something. */
else
if(x> 10 or y> 10)
/* Do something else. */
if(not a)
/* Do something. */
return 0;
}

None of the vertical whitespace in your code was necessary or helpful
in reading the code. (*Three* blank lines between #include <iso606.h>
and int main(void)? Why??)

Well, that whitespace didn't harm either.




--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Keith Thompson]

Keith Thompson wrote: [...]

None of the vertical whitespace in your code was necessary or helpful
in reading the code. (*Three* blank lines between #include <iso606.h>
and int main(void)? Why??)

Well, that whitespace didn't harm either.

Yes, it did. It made your code more difficult to read.

 

[Nick Keighley]

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.

does that constitute "justifying asctime()'s misgivings"? or
"downplaying the issue's importance"? It implies that people are
defending the flaws in asctime(). I don't use asctime() because the
output isn't in a form I find useful. asctime() isn't particularly
difficult to use correctly; it's a bit like complaining about strcpy()
or sprintf(). People should be aware it has issues (as do many other
standard library functions) and work around them. It simply doesn't
warrant navia levels of hysteria.

 

[Nick Keighley]

Strange.

Did nobody ever notice during debugging that object files contained mangled
names?

I wasn't aware that debuggers displayed mangled names.

(Or was a toolchain used with a more advanced linker that doesn't have
to mangle names?)

Nobody ever used ``new'', ``class'', or any other C++ keyword, as a name and
wonder why the compiler was rejecting a perfectly good C identifier?

the one that sneaked in was true and false. There wewre macros TRUE
and FALSE but some people started using true and false not aware that
they weren't C. Scarey huh?

How about linkage; didn't anyhone ever notice what libraries are being
linked to the code?

why? Why would they look?

Did their toolchain not have a separate C++ library
for C++ programs?

the build process produced an execuatable. Why would anyone care if
the C++ library was different from the C one?

 

[Keith Thompson]

does that constitute "justifying asctime()'s misgivings"? or
"downplaying the issue's importance"? It implies that people are
defending the flaws in asctime(). I don't use asctime() because the
output isn't in a form I find useful. asctime() isn't particularly
difficult to use correctly; it's a bit like complaining about strcpy()
or sprintf(). People should be aware it has issues (as do many other
standard library functions) and work around them. It simply doesn't
warrant navia levels of hysteria.

I think we're in agreement on asctime(); we're probably just not
agreeing on what "justifying asctime()'s misgivings" or "downplaying
the issue's importance" means. At this point, I'd say it's not
worth resolving.

 

[Nick Keighley]

For years the huge majority of programmers (yes, in my experience) have
used "sizeof(n)" . Where n is a number, type or "object",

One syntax that works, and is easy to read. There is nothing more "beautiful"
about

x=x+sizeof n;

than

x=x+sizeof(n);

I thought

thingy = malloc (sizeof *thingy);

looked quite odd when I first saw it. I'd still be a bit reluctant to
use it because it might cause confusion. On the other hand I really
dislike.

return (0);

though I tend to use brackets if it's an expression, especially (and
I'm not sure why) if its a" boolean" expression.

return (channel_type == CONTROL && channel_is_available
(channel));

 

[Nick Keighley]

(e-mail address removed) (Richard Harter) writes:



Why essential?
useful


A lot of programmers have gone through life not realising it no ill
affects.

What errors did they introduce by thinking that? It's not like there are
no bigger fish to fry.

I suppose they might be surprised that sizeof() didn't evaluate its
argument. People seem to be more likely to pass a type to sizeof()
rather than an identifier.

Channel *create_channel (int id)
{
Channel *channel = NULL;
channel = malloc (sizeof (*channel)); /* won't that deref a null
pointer? */
CHECK_PTR(channel);
return channel;
}


If they understood what sizeof() was they might be less surprised by
certain code and even write better code. But, yes, you can write an
awful lot of perfectly capable code without knowing this bit of
exotica.

 

[Nick Keighley]

As of the last committee meeting, it now has "alignof", too.

doesn't offsetof() qualify as reflective? It needs compiler magic.

 

[Phil Carmody]

This is one of those cases where "you" is ambiguous. I shall do
you the honor of assuming that you weren't violently misreading
what I wrote. That said, I disagree. It is not a matter of
"should", it is a matter of "is". In C there is a wall between
the program and the compiler's information; there is very little
access to compiler metadata. It is a hack because it is an
ad-hoc device to get a piece of metadata.

If you're going to make a hard-to-support argument, and then
try to defend it, at least try to keep it the same argument
both times. You can't magically swap 'program' for 'programmer'.

Phil

 

[Nick Keighley]

Richard wrote:

I'm OK providing entertainment. Can you provide an instance of a voids
holding anything at all?

There is no void type. There is however a void* type. I don't find where a
function pointer can be assigned to a variable of type void*. Do you?

Richard's simply saying he's seen code that does this.

void add (int n)
{ ... }

void *func_list[] = {(void*)add, (void*)step, (void*)halt};

[the usual disclaimer about checking it works]

It might be a poor idea but it exists all the same.

 

[Phil Carmody]

"Must every little keyword have a jargon all its own?" (With
apologies to Jerome Frank).

The `while' keyword -- and `for' and `if' and `return' and
others not mentioned -- are a part of the required syntax of the
statements in which they appear, that's all. We don't need a
special name for the white space that separates `int' from `main';
why should we need a special name for `while'?

They're hardly similar. The 'while' is keyword, the whitespace isn't;
the while survives tokenisation in tact, the whitespace doesn't;
possibly other distinctions too.

'while' may clearly be called an operator in a meta-linguistic
context - it's just that one of the things it operates on is not
necessarily an expression, similarly sizeof(type) is an operator
on an unusual domain - but given that 'operator' has a clear and
long-standing interpretation in C, it's really not useful to
force definitions from a broader domain into discussions purely
about C.

My argument boils down to this: The Standard does not use the
term "operator" to refer to `while', so we shouldn't use it that
way either.

Works for me.

Phil

 

[Phil Carmody]

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.

Yes, Gnus fails to flow the content correctly. File a bug!

Phil

 

[Phil Carmody]

You're just being lazy when you should be doing something as simple as the
following


struct num {
enum id { Character, Short, Int, Long } id;
union {
char c;
short s;
int i;
long l;
} u;
};

Wow, thanks for making my characters take up 16 bytes rather than 1.
A vector of chars shouldn't need any more type information than a
single char.

Phil

 

[Phil Carmody]

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

But that is totally meaningless. You're not sending me pixels, you're
sending me text, and I get to chose how big that text is in pixels.
It's also totally meaningless as 800 pixels on my n900 is, at about
7cm, completely different from 800 pixels on the monitor attached
to my server, namely about 20cm. If you specify anything in pixels,
you've completely failed to specify the angle subtented in my view,
which is the only absolute definition of the size of what is being
rendered.

Phil

 

[Phil Carmody]

I know that.

Now we've got the definition of 'void', we're left wondering
what the definition of 'know' is.

Phil

 

[Eric Sosman]

Richard wrote:
[ snip ]

For sure. But I don't see how that has any impact on the fact that for
years voids have been used for holding "unsuitable" things. Joe
Wright's
incredulous demand for a "citation" had me in stitches.

I'm OK providing entertainment. Can you provide an instance of a
voids holding anything at all?

There is no void type. There is however a void* type. I don't find
where a function pointer can be assigned to a variable of type void*.
Do you?

There *is* a void type, saith 6.2.5p19:

The void type comprises an empty set of values; it is
an incomplete type that cannot be completed.

I know that. So it can't hold anything.

Since there are no values of type void, however, it is not
possible to have a void variable that holds one.

There is no guarantee that a function pointer can be converted
to or from a void* (or any other data pointer) "meaningfully."
That is, the converted pointer need not be usable, and converting
it back to the original type need not produce the original value
undamaged.

I know that too. Why are you telling me this instead of Richard?

Was it not you who wrote "There is no void type?" That's
wrong; I replied to correct.

 

[Eric Sosman]

Interesting that it has *no* values, since it could hold one
without requiring any space.

That's why sizeof(void) isn't zero. ;-)

 

[Ioannis Vranos]

I suppose they might be surprised that sizeof() didn't evaluate its
argument. People seem to be more likely to pass a type to sizeof()
rather than an identifier.

Channel *create_channel (int id)
{
Channel *channel = NULL;
channel = malloc (sizeof (*channel)); /* won't that deref a null
pointer? */
CHECK_PTR(channel);
return channel;
}

sizeof(*channel) doesn't derefer channel, the same way that sizeof(x)
doesn't read the value of x.




--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net