Re: Illegal internal write?

On Sun, 05 Mar 2006 23:00:33 -0800, glen herrmannsfeldt
<gah@xxxxxxxxxxxxxxxx> wrote:

Richard Maine wrote:

glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:

Dave Thompson wrote:

(Aside: you also need <string.h> for strcpy.)

Technically, that is true. On the other hand, it seems to
work without it.

Just like many nonstandard things can happen to work in many contexts.
"It seems to work" is not a very good criterion for professional work.
Have you verified that it works on all compilers in all cases? That's a
rhetorical question, of course.

Well, the standard does say what happens if there is no prototype in
scope, which is necessary for pre-ANSI compatibility.

If no declaration is in scope, the C89/90 standard says that the
function is implicitly declared to return int and take unspecified
K&R1-compatible arguments. Technically it is Undefined Behavior to
call a function returning char* as if it returned int, although on
most if not all systems it does work, especially if you don't (try to)
use the returned value, as here IIRC. C99 deletes the implicit
declaration feature, and requires a diagnostic, after which a C99
implementation is likely to implement the C89 way for compatibility.

There are also many nonstandard things in Fortran that "seem to work"...
that is, until they don't.

It is similar, as far as I can tell, to not having an INTERFACE when
no newer than F77 features are being used.

I think it is -- both in the feature itself, and the reason it is
there. Which provides us (me?) with a tenuous link back to topic.

Calling strcpy with parameters that are not (char*), such as (unsigned
char*), would require the prototype.

Actually, that one wouldn't. Although in C's type system char * and
unsigned char *, and for that matter char * and const char *, are not
formally 'compatible', they are required to have the same
representation; in C89/90 this is nonnormatively 'intended' to allow
interchangeability as unprototyped arguments among other things; in
C99 this is explicit 6.5.2.2p6 and 7.15.1.1p2 for the similar varargs
case. Signed versus unsigned integers of the same 'rank' (informally,
size) have the same special dispensation for nonnegative values.

A reference to sqrt(2) should fail without #include <math.h>, as sqrt
expects a double. Anything with a (FILE*) argument pretty much requires
the #include file that defines (FILE*).

To be contrarian, you _could_ have a machine where int is a subset of
and shares the representation of double, and then the implicit wrong
declaration of sqrt() would actually work. But that's damn rare.

OTOH, FILE in practice almost always is a struct, although not
formally required to be, and all struct pointers must have the same
representation, so you can probably get away with "struct fakefile *".
OT3H, why bother? It's easier as well as safer to #include <stdio.h>.\


- David.Thompson1 at worldnet.att.net
.

Relevant Pages