Dynamic lists of strings in C

[Ian Collins]

(I assume you meant to write C++.) I find bugs in hoary C code quite
often while making it ISO compliant and compiling on a modern C
compiler.




I can't think of any reason that a C++ compiler should be inherently
better at finding bugs in C code. If your C compiler has insufficient
diagnostics, there's always the lint family of products.

Certain kinds of type abuse. The smelly code I had to fix made heavy
use of enums as function parameters. These were frequently abused by
passing inappropriate integer values. Lint and its ilk won't warns
about cases like

enum EA { A, B };

void fA( enum EA );

int main( void )
{
fA( 42 );

return 0;
}

 

[Peter Nilsson]

I think you're being needlessly pendantic here.

The word is obtuse. One day Richard may reread these old threads
and realise that.

Clearly the remark was meant in the same sense that one might call
a steam excavator a better shovel.

You seriously need a dictionary definition to understand the term
'better' in context? Personally, I think the phrase is Plain English
and the double quotes are only put in to avoid confrontation with
those who have demonstrated they are easily offended.

A preparation that you have shown little ability to apply yourself
when it comes to malloc casting.

Agreed. The (completely unknown) context was probably relevant
however.

Here's the summary:

- Richard proclaimed malloc casting as a bad idea here (sic) and
the simple fact that OP was aware of that is sufficient reason
to not assist the OP.

- The word 'here' implies he speaks for the whole of comp.lang.c.
[An intent further infered from later comments.]

- Curriously he has found little support for one of his own self-
imposed styles, and I challenged that his idea of blanket
initiailisation of all automatic objects was also considered
a bad idea here "but you do it anyway".

- I was trying to ascertain why a supposedly bad idea should be
sufficient reason for black balling. My concern is that clc is
about standard C and, whilst clearly not a popular one amongst
the regulars (for legitimate reasons!), malloc casting does not
in and of itself preclude correctness.

- Given that Richard only recently was prepared to post code
containing the Windows macro CALLBACK (aka __stdcall), a
macro that has no equivalent in ISO C, I found it hypocritical
that Richard should effectively call on a ban of a C construct
that can not only be performed correctly, but which is a
common construct amongst C programmers.

- One of Richard's objections to blanket initialisation being
labelled as a bad idea was a statement that implies that a
single additional supporting vote is enough to preclude the
presumption.

- I cited Plauger's objection (published in clc) in relation to
the malloc casting issue.

- Richard rejected the argument claiming that Plauger is an
implementor (of implementations) and as such his argument
is not relevant.

- I challenged Richard to show which statements in Plauger's
arguments are exclusive to implementors.

- Richard stated simply that C++ isn't C and that Plauger's
comment that C++ is a better C (in some ways) is wrong.

Richard is perfectly entitled to reject malloc casting. What I
don't think he is entitled to do is to issue what is tantamount
to a rallying cry to regulars to start blackballing any and all
code that includes a casted malloc. It makes no more sense than
me issuing a decree that all posts containing blanket
initialisation should be ignored.

I'll let readers draw their own conclusions, but I would be
disappointed if regulars started refusing to help people on
the basis of C style.

 

[Peter Nilsson]

Your signature is missing the space after the --.

It's yet another Google feature I'm afraid.

Google correctly trims trailing whitespace, but does not recognise
signature separators.

 

[Ian Collins]

It's yet another Google feature I'm afraid.

It can be fixed, one of the regulars on clc++ was berated for this and
managed to sort is signature when posting from google.

 

[Richard Heathfield]

[Peter - what follows is basically nit-picking. I'm not particularly
trying to pick a fight here, just straightening a few wonkies.]

Peter Nilsson said:

Here's the summary:

- Richard proclaimed malloc casting as a bad idea here (sic) and
the simple fact that OP was aware of that is sufficient reason
to not assist the OP.

It's a sufficient reason for me, anyway. I don't speak for clc, however.

- The word 'here' implies he speaks for the whole of comp.lang.c.

Um, no. You might have inferred it, but I certainly didn't imply it. I'm
not that stupid.

[An intent further infered from later comments.]

Again, I can't help your inferences but I can at least categorically say
that I would never deliberately imply, except perhaps in evident jest,
that I speak for comp.lang.c - not least because it's an impossible
task.

- Curriously he has found little support for one of his own self-
imposed styles, and I challenged that his idea of blanket
initiailisation of all automatic objects was also considered
a bad idea here "but you do it anyway".

Well, no, actually - some people think it's a bad idea and others don't.
And some people consider its opposite to be a bad idea. This isn't
something where clc has reached a consensus.

- I was trying to ascertain why a supposedly bad idea should be
sufficient reason for black balling.

Well, I'm not trying to black ball anyone. But when someone seeks advice
and says "by the way, here's an example of advice I rejected earlier",
it seems to me that there are better ways to spend my time than to give
them some more advice to reject.

My concern is that clc is
about standard C and, whilst clearly not a popular one amongst
the regulars (for legitimate reasons!), malloc casting does not
in and of itself preclude correctness.

Very true.

- Given that Richard only recently was prepared to post code
containing the Windows macro CALLBACK (aka __stdcall), a
macro that has no equivalent in ISO C, I found it hypocritical

Pfft. #define CALLBACK to nothing whatsoever and you're right back in
the land of ISO C, as I pointed out in my original reply to the guy
asking about wndprocs.

This is going on too long, so I'll

<snip>

to the chase...

I'll let readers draw their own conclusions, but I would be
disappointed if regulars started refusing to help people on
the basis of C style.

Sure. Nevertheless, nobody here is under any obligation to continue to
provide advice to people who make no effort to learn from it.

 

[Al Balmer]

You seriously need a dictionary definition to understand the term
'better' in context? Personally, I think the phrase is Plain English
and the double quotes are only put in to avoid confrontation with
those who have demonstrated they are easily offended.

That's a simplistic view acceptable only to those who already have
their mind made up. Complex things like languages can very well be
"better" in some respects and "worse" in others when compared to each
other. A measure of goodness is meaningful only after you define what
"good" is.

 

[Default User]

It can be fixed, one of the regulars on clc++ was berated for this and
managed to sort is signature when posting from google.

If you're refering to James Kanze, I don't believe I berated him.

"A small (but important) technical note. The proper separator for .sigs
is "-- " (dash dash space). Yours is missing the space. Correct
separators allow newsreaders to auto-trim signatures."





Brian

 

[Ian Collins]

If you're refering to James Kanze, I don't believe I berated him.

No, but I did!

 

[Default User]

No, but I did!

Ah. I seem to recall something about that now.

I also notice that Mr. Kanze had conforming .sigs for a short time
after the discussions about that, but now is back to the "no dash"
version.



Brian