Warnings in lcc-win

[CBFalconer]

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main() {
char x[4];
memset(x, sizeof x, 100);
}

Why did you delete the example I gave? That was a proper
definition, with proper definition of parameters etc. And it did
not use the reserved std. library name. You are using an ancient
K&R1 declaration.

 

[Flash Gordon]

Old Wolf wrote, On 01/10/07 23:51:

gcc does not conform to the C standard at default
warning level either.

Agreed. However Jacob was only talking about default level and maximum
warning level. Maximum warning level normally includes lots of
diagnostics which are not required by the standard which, whilst it does
not break conformance, does IMHO make it appropriate to comment on the
conformance of the only other level mentioned. IIRC I also asked about
what it does in standards conforming mode in this post.

I don't think it's a compiler's job to enforce the
writer to write portable code. I'm quite happy with
compilers accepting code that is guaranteed to work
on that particular implementation, in their default
mode of operation. Another example is // comments
in C90 code.

Those programmers who do want portability can invoke
the compiler in the mode that conforms to the C standard.

Agreed. However I still believe (and think I mentioned, but could be
wrong) that a diagnostic for the above code should be provided at
default warning level as a matter of QoI.

 

[Charlie Gordon]

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

for the second time in two days, memset arguments are mem, c, count.
the above code invokes undefined behaviour.

 

[Mark L Pappin]

Old Wolf wrote:
Now why would you say that? To my mind, prototypes have just
two purposes: 1. Expose the calling sequence to other files,
and 2. Resolve indirect recursive calls.
Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and
receive the return value correctly.
No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

for the second time in two days, memset arguments are mem, c, count.
the above code invokes undefined behaviour.

Old Wolf's point, I think.

The code shown has a declaration of 'memset()' before its use, which
CBF claimed handled the checking the number and type of arguments.

The code shown has no prototype for 'memset()', and thus the compiler
is not required (but may, since that function is defined by the
standard and thus the compiler may have "special" knowledge of it) to
check the number and type of arguments.

ml "reading for comprehension" p

 

[Eric Sosman]

Keith Thompson wrote On 10/01/07 16:00,:

[...]
I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

Yabbut, if the question concerns fork() in any
essential way, like "Does a successful call to fork()
double the swap space allocation?" or "Does the new
process preempt the old one immediately, or does the
old keep on executing for a while?" then the question
really really really isn't about C. Even if you know
something about fork(), the best answer you can give
is probably "It depends."

Personally, I've no reluctance to answering questions
that involve stat() or open() or whatever, if I perceive
them as being involved "incidentally." If a code snippet
shows input being obtained from recv() and the question
is about how to manage memory allocation for the received
data, I see no reason not to discuss the proper use of
malloc() et al. On the other hand, a question about how
to use recv()'s MSG_PEEK flag is a clear candidate for
"Try another newsgroup; you'll get better answers."

IMHO, fork() is a function for which practically all
serious questions fall into the second category.

 

[Keith Thompson]

Keith Thompson wrote On 10/01/07 16:00,:

[...]
I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

Yabbut, if the question concerns fork() in any
essential way, like "Does a successful call to fork()
double the swap space allocation?" or "Does the new
process preempt the old one immediately, or does the
old keep on executing for a while?" then the question
really really really isn't about C. Even if you know
something about fork(), the best answer you can give
is probably "It depends."

Personally, I've no reluctance to answering questions
that involve stat() or open() or whatever, if I perceive
them as being involved "incidentally." If a code snippet
shows input being obtained from recv() and the question
is about how to manage memory allocation for the received
data, I see no reason not to discuss the proper use of
malloc() et al. On the other hand, a question about how
to use recv()'s MSG_PEEK flag is a clear candidate for
"Try another newsgroup; you'll get better answers."

IMHO, fork() is a function for which practically all
serious questions fall into the second category.

I agree completely.

My point is that there is a great deal of common knowledge about
various system-specific functions, at least to the extent of having a
pretty good idea where most of them come from. If someone asks about
how to use fork(), I'm not going to explain *here* how to use fork(),
even though it's very likely that I know the answer. But I'm also not
going to go to the other extreme and pretend that fork() doesn't
exist, and ask the OP to provide portable source code that implements
it.

If there's also a directly C-related problem in the code, I'll point
that out. For example, if the program includes only C standard
headers, it's likely that no prototype for fork() is visible, which
might be the cause of the problem. (The same applies to clrscr() or
xYzPdQ().) I won't necessarily mention that <unistd.h> is the correct
header; I'll merely suggest that the OP should read the documentation
for fork() to find out what headers are reqiured. <OT>Yes, <unistd.h>
declares fork(), but you probably also need <sys/types.h> for the
declaration of pid_t, the type that fork() returns. That's normally
too much system-specific detail for this group.</OT>

I happen to know that the name "fork" *almost certainly* refers to the
Unix-specific function. That information is, strictly speaking,
off-topic here, but I won't hesitate to use it to suggest the
appropriate forum for the question, namely comp.unix.programmer.

It's conceivable that "fork" is really the "File Or Resource Key"
function from some OS I've never heard of, but in that case the OP
will probably be able to figure out where to ask questions about his
OS anyway.

 

[Old Wolf]

No it isn't; e.g.

int memset();

int main() {
char x[4];
memset(x, sizeof x, 100);
}

Why did you delete the example I gave?

Because it was not relevant. You made an assertion, and provided
a corroborative example. I provided a counterexample, proving
the assertion false.

That was a proper
definition, with proper definition of parameters etc. And it did
not use the reserved std. library name. You are using an ancient
K&R1 declaration.

That's the whole point.

 

[Mark McIntyre]

No, because that is handled by the declaration before use
requirement.

Declaration before use doesn't provide this unless you have
prototypes.

The definition of foo acts as a declaration and prototype.

NB: declaration is different to definition.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Why did you delete the example I gave? That was a proper
definition, with proper definition of parameters etc.

What you provided was a function definition and a prototype - which
would seem to support Old Wolf's position. Presumably he deleted it to
demonstrate the broken ness of your assertion that _declaration_
before use provided the required functionality.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[CBFalconer]

Declaration before use doesn't provide this unless you have
prototypes.


NB: declaration is different to definition.

Well, I normally mix up the use of 'declaration' and 'definition'
as applied to functions At least I know what I mean!

 

[Charlie Gordon]

Old Wolf wrote:
CBFalconer <[email protected]> wrote:

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main() {
char x[4];
memset(x, sizeof x, 100); /* BUG */
}

Why did you delete the example I gave?

Because it was not relevant. You made an assertion, and provided
a corroborative example. I provided a counterexample, proving
the assertion false.

That was a proper
definition, with proper definition of parameters etc. And it did
not use the reserved std. library name. You are using an ancient
K&R1 declaration.

That's the whole point.

memset can be abused even in presence of a proper declaration from
<string.h>

#include <string.h>
int main(void) {
char x[4];
memset(x, 4, 100); /* arguments in wrong order */
return 0;
}

Also, what I was complaining about earlier is the counterproductive effect
your post may have on newbies: many people rely on visual memory, it is
disingenious to post bogus code without properly tagging it as such.