Should we broaden the topicality of this group?

[Kenny McCormack]

....

Discussions of how horribly bad Windows is (either inherently or in
comparison to Unix), and about Microsoft being the Great Satan, or at
least the source of all buffer overflows, is certainly off-topic.
This is not the place for OS flame wars.

But referring to Windows as "your particular platform" is perfectly
appropriate, since that's exactly what it is. Unless there's more
context than that, I see nothing supercilious about it.

This just goes to show how totally clueless (or possibly, outright evil)
you really are. It is perfectly clear to most of us that referring to
Windows as "your particular platform" is intended as a slam. That it
is possible to interpret this meaning away (as you have done) is, of
course, part of what makes for a good slam. Something about "Aesopean
language"...

 

[CBFalconer]

.... snip ...

I should have expressed my view clearer, I didn't intend to say
provide a detailed answer to a completely platform specific
question which would be better answered elsewhere. I was
referring to the common form of question where there is an obvious
C language problem, but the posted code contains something non
standard, say <conio.h> or <curses.h>. More often than not, these
are dismissed as off-topic by virtue of the platform specific code
when there is a simple platform neutral answer.

Now there you normally have a serious problem. By using the
off-beat header the OP has made his code intrinsically uncompilable
by most participants. Conversion to compilable code may well be a
long and tricky operation, and should be done by the OP. You don't
even know anything about the routines in HIS conio.h. The initial
reaction here should be to advise the OP, and instruct him to
delete those components before reevaluating and reposting.

 

[Keith Thompson]

I didn't write about what csc or clc are for, I wrote about what I think
they should be for.

That would have been clearer if you had written "comp.std.c should be
for the theory" rather than "comp.std.c is for the theory".

It doesn't seem there are a lot of discussion about the typesetting, the
choice of paper and so on in that group.

No, but if you wanted to discuss the typesetting or choice of paper,
comp.std.c would be the place to do it. (The C90 standard, as
published, did have some typesetting problems.)

But most of the discussion there concerns possible errors and
ambiguities in the standard, proposals for changes in future versions
of the standard, activities of the committee, and so forth. The
language that's defined by the standard is discussed in comp.lang.c.

I never meant that. And I wonder how you could think I meant that. Is
there something lacking in my english expression or did you play some
language trick like I tried just above?

You referred to "the theory" in your description of what you think
comp.std.c should be for. I presume that was the source of Al's
misunderstanding. Can you clarify what you meant by "the theory"?

[snip]

 

[Keith Thompson]

What on Earth do you think comp.lang.c is now?

It's certainly messier than I'd like it to be, but there are still
some good topical discussions going on, and there's still a core group
of knoledgeable regulars who know what they're talking about and are
able and willing to answer questions.

I'm sure the judicious use of a killfile (per-user and per-thread)
would make it look much better, but I haven't chosen to use one.

 

[Alan Curry]

I would like to create a log file whose name contains the magic character. If
MAGIC_CHARACTER had been defined as a string ("x" instead of 'x') I could do
this:

logfp=fopen(MAGIC_CHARACTER ".log", "w");

char filename[] = {MAGIC_CHARACTER, '.', 'l', 'o', 'g', '\0'};
Ugly.


or

char filename[BIG_ENOUGH];
snprintf(filename, BIG_ENOUGH, "%c.log", MAGIC_CHARACTER);

I already mentioned that run-time building of the string is what I'm trying
to avoid.

or, in C99,

logfp = fopen((char[]) {MAGIC_CHARACTER, '.', 'l', 'o', 'g', '\0'}, "w");

Ugly. Anything that splits the long string into individual characters is ugly
enough that I'd rather use the sprintf. Actually what I have now is

char filename[]="?.log";
strchr(filename, '?')[0]=MAGIC_CHARACTER;

But that still sucks.

None of these are ideal of course.

Ideal would be if adjacent-string-concatenation also worked on character
literals!

 

[Alan Curry]

How about:

#define MAGIC_CHAR 'x'
#define MAGIC_STRG # (MAGIC_CHAR, '\0')

use as desired.

If only I could figure out how to use it. I don't understand how it's
supposed to work.

$ cat test.c
#include <stdio.h>

#define MAGIC_CHAR 'x'
#define MAGIC_STRG # (MAGIC_CHAR, '\0')

int main(void)
{
fopen(MAGIC_STRG ".log", "w");
return 0;
}
$ gcc -O3 -Wall -W -Wnested-externs -Wcast-qual -Wpointer-arith -Wshadow -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wformat=2 -std=c89 -pedantic test.c
test.c: In function 'main':
test.c:8: error: stray '#' in program
test.c:8: warning: left-hand operand of comma expression has no effect
test.c:8: error: expected ')' before string constant
test.c:8: warning: passing argument 1 of 'fopen' makes pointer from integer without a cast
test.c:8: error: too few arguments to function 'fopen'
$ gcc -O3 -Wall -W -Wnested-externs -Wcast-qual -Wpointer-arith -Wshadow -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wformat=2 -std=c99 -pedantic test.c
test.c: In function 'main':
test.c:8: error: stray '#' in program
test.c:8: warning: left-hand operand of comma expression has no effect
test.c:8: error: expected ')' before string constant
test.c:8: warning: passing argument 1 of 'fopen' makes pointer from integer without a cast
test.c:8: error: too few arguments to function 'fopen'

 

[Kenny McCormack]

Perhaps I read a different mix than you, but it seems just the
opposite to me. Many responders go out of their way to dig out the
question about C that's buried deep in the seemingly off-topic morass.
There may be some who dismiss the question because they didn't read
carefully, but that's why we allow more than one answer

More than once, I've skimmed, then skipped, a long message about
problems using some specialized library on Windows, then gone back
after I read a reply by someone who discerned the real question <g>.

Sure you have.

And I am the queen of Spain.

 

[Ben Pfaff]

There is a header file foo.h, which defines a macro like this:

#define MAGIC_CHARACTER 'x'

The main program #includes foo.h and does some stuff that depends on which
character is selected to be magic. The intent is that the user can change the
x in the header file and recompile to get a different result.

I would like to create a log file whose name contains the magic character. If
MAGIC_CHARACTER had been defined as a string ("x" instead of 'x') I could do
this:

logfp=fopen(MAGIC_CHARACTER ".log", "w");

and the adjacent strings would be merged into one string to make the
filename. But since MAGIC_CHARACTER is not a string, that won't work.

None of my previous suggestions made you happy, as I can well
understand, so let me try again. How about:
#define MAGIC_STRING "x"
#define MAGIC_CHARACTER ((MAGIC_STRING)[0])
and then:
logfp = fopen(MAGIC_STRING ".log", "w");
This does change the semantics of MAGIC_CHARACTER, in that it can
no longer be part of a constant expression, but perhaps that is
not important for your application.

 

[Keith Thompson]

How about:

#define MAGIC_CHAR 'x'
#define MAGIC_STRG # (MAGIC_CHAR, '\0')

use as desired.

Um, did that work for you?

Alan Curry is deliberately trying to hijack this thread. If you want
to discuss this particular C issue (which is perfectly topical for the
newsgroup), *please* start a new thread.

 

[Philip Potter]

Non-compliant does not exclude extensions. However syntax
extensions are automatically non-compliant, and require warnings.

I don't know the standard well; is this because a syntax error requires
a diagnostic? Does this mean that a C90 compiler can implement 'long
long' provided it warns that it is not standard C?

In any case, surely it can introduce new keywords from the
implementation namespace at will?

Connection to other routines requires the source of such routines
to be portable, and those routines themselves need to be written
(or at least writable) in standard C. If the code is not portable,
it does not belong in c.l.c. The point is dual - the readership
cannot intelligently comment on undefined things, nor can they
comment on the usage of such beasts.

I think you underestimate the intelligence of clc. When someone mentions
clrscr(), the standard makes no guarantees about what that function
does. I know that on the DS9K it is a nasal demon function, but I don't
see what's wrong with making a sensible reply assuming that clrscr() is
a clear screen function, provided that is mentioned.

If you refuse to help someone with a clrscr() in their program, even
though the symptoms of the error show it is likely to occur elsewhere
and there are visible errors in the rest of the program, you are being
quite petty.

A welcoming, friendly and useful response would politely point out that
clrscr() is not standard and may behave differently on different C
implementations, and then to debug the rest of the program.

It's fair enough to redirect if someone asks /how to use/ clrscr(), for
that is clearly offtopic. But if someone only /mentions/ it and you
redirect, when they get to the clrscr()-appropriate group they'll
rightly be told "That's a C problem, not a conio.h problem." It's
incredibly frustrating.

The parentheses around (faulty) were intended to imply a
possibility. Otherwise I would have simply omitted the
parentheses.

This seems to be a fairly silly discussion, since there is no
reason not to take the off-topic discussions to appropriate
newsgroups.

But we are trying to clarify /what/ is offtopic and what is not!

 

[Chris Hills]

Chris Hills wrote: *** and eliminated attributions - bad ***

You keep failing to realize the topicality.

I know the topicality. It is YOU who is trying to artificially restrict
it. That is the whole point of this lengthy debate.

There is adequate room
for discussion of those specialized compilers on
comp.arch.embedded.

Why? Who said these were embedded compilers. You make incorrect
assumptions

 

[Chris Hills]

I have no idea. I don't happen to know what 61508 SIL3, 60601-1-4,
and Do187B are. I do know a lot about C, which is the topic of this
newsgroup.

These are process standards used on safety critical projects. 61508 for
general use and Do178B for airborne. Both are standards that require the
tools used in the development of software are "certified" (ADA is more
commonly used than C for a lot of Do178B work)

So these compilers CBF is suggesting are "faulty" seem to be able to
get "certified" for safety critical use where lives are at stake.

That is how far out of touch CBF is.

One has to be exact in safety critical work however there is no room for
some of the pointless pedantry I see here.

 

[Richard Heathfield]

Philip Potter said:

CBFalconer wrote:


But we are trying to clarify /what/ is offtopic and what is not!

Indeed. To clarify the clarification, what we're trying to determine is
whether the group wishes to consider as topical aspects of C programming
that are not defined by ISO or K&R.

I'll start preparing a summary.

 

[Jean-Marc Bourguet]

You referred to "the theory" in your description of what you think
comp.std.c should be for. I presume that was the source of Al's
misunderstanding. Can you clarify what you meant by "the theory"?

When making a opposition between the practice of X and the theory, it seems
obvious that it is the theory of X which is implied and not a bigger theory
which can take X as an object. And calling the C standard its theory
doesn't seem far fetched.

So yes, I meant the standard and reading csc, I don't think there is a
mismatch between what I think that group should be and what it is.

There is a mismatch for clc. At times it seems it is a group for flame
about what is topical for the group.

Yours,

 

[Philip Potter]

Ian Collins wrote:
... snip ...

Now there you normally have a serious problem. By using the
off-beat header the OP has made his code intrinsically uncompilable
by most participants. Conversion to compilable code may well be a
long and tricky operation, and should be done by the OP. You don't
even know anything about the routines in HIS conio.h. The initial
reaction here should be to advise the OP, and instruct him to
delete those components before reevaluating and reposting.

This attitude is deliberately obtuse. There is one particularly common
conio.h, and while there may be others, I've certainly never come across
one. Admittedly, knowledge of conio.h is not required to be a C expert,
but you can at least assume good faith on behalf of the header and the
nonstandard functionality.

I realise it is possible that the header contains the lines:

#ifndef CONIO_H
#define CONIO_H
#include <stdio.h>
int main(void) { start: printf("Throatwobbler-mangrove\n"); goto start;
return 0;}
#define main notmain
#endif

...and thus changes the entire apparent behaviour of the program. Nothing
in the C standard prevents this. But I'd rather try to help someone in
case the obvious errors in their code, and not the nonstandard header,
are the problem; rather than tell them to shove off until they have
fully standard code, in case it is the header which is the problem. If
necessary I'll add a disclaimer saying that I don't know what the header
contains and it could affect things.

 

[Philip Potter]

1. The single sentence answer may be wrong, and not caught by others
in the group because they aren't the people who know the subject. When
that wrong answer is given with apparent authority, chances are the
questioner will not follow up with the suggested group.

I think we need to distinguish between cases where the error is in
ordinary C code within a program which uses extensions, and cases where
the error is in the extensions. In the former case, the wrong single
sentence answer /may/ be caught by others who don't know the subject, in
the latter, it may not.

2. People participate in groups to learn more about the subject of the
group. By answering the off-topic question here, you are depriving the
people in the group where the question would be topical.

But when the problem is a C problem and not a problem with the
extension-using code, if this isn't the right group, which group is?

 

[Philip Potter]

I can't overlook this ludicrous remark. As I've bothered to read up on
who some of the people Richard complains about are, I can say with
some comfort that most of them have more real world experience in
their little fingers than the rest of us can dream of.


However given that this is a false situation, the question was
disingenuous at best.

The most likely answer in this case would be "how can we tell without
knowing what mstruct.h contains?"

While you can never be /certain/ about code which uses a header you
don't know about, you can be pretty sure that if the poster is trying to
print /any/ pointer as an integer (as the snipped code indicated) that
this is most likely a problem.

Perhaps you like to be absolutely sure about everything. I can cope with
that small element of risk that <mstruct.h> might screw everything up,
but probably doesn't.

 

[Philip Potter]

char filename[]="?.log";
strchr(filename, '?')[0]=MAGIC_CHARACTER;

But that still sucks.

Why not replace the strchr() line with filename[0] = MAGIC_CHARACTER?

 

[Richard Heathfield]

Philip Potter said:

There is one particularly common
conio.h, and while there may be others, I've certainly never come across
one.

You might want to look a little harder. At least two mainstream vendors,
Microsoft and Borland, habitually provide <conio.h> with their
implementations, and the contents are very different (although there are
similarities). For example, we frequently see clrscr() cited as a
"screen-clearing function", but IIRC Microsoft have never provided one in
their <conio.h> - ever.

<snip>

 

[Richard]

While you can never be /certain/ about code which uses a header you
don't know about, you can be pretty sure that if the poster is trying
to print /any/ pointer as an integer (as the snipped code indicated)
that this is most likely a problem.

Perhaps you like to be absolutely sure about everything. I can cope
with that small element of risk that <mstruct.h> might screw
everything up, but probably doesn't.

And the point is that even IF we remove that header from the code posted
here, in the real word, headers like that WILL be included in real
code. MM inadvertently supported my point about how ridiculously
pedantic people can be in this NG.