Hello,
I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:
d=(double *) malloc(50*sizeof(double));
why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?
thanks,
Brian Blais
Nov 14 '05
231  22873 
On 30 Jan 2004, Daniel Haude wrote: On Wed, 28 Jan 2004 18:49:52 +0000,
Tak-Shing Chan <es***@city.ac.uk> wrote
in Msg. <Pine.GSO.4.33.0401281740480.18387-100000@swindon> double *x; /* Wrong declaration */
x = (int *) malloc(sizeof *x);
When you start casting x here, why not cast it everywhere you use it? This
doesn't have to do with malloc().
It has to do with the fact that malloc returns a void *,
which can be assigned to any pointer including the wrong ones.
Tak-Shing
In <bv**********@news.tudelft.nl> Sidney Cadot <si****@jigsaw.nl> writes: Daniel Haude wrote:
On Thu, 29 Jan 2004 01:08:46 +0100,
Sidney Cadot <si****@jigsaw.nl> wrote
in Msg. <bv**********@news.tudelft.nl>
That way, I don't have to rely on the semantics of C with regard to
allowing void*-to-any* assignments,
When programming in C you have to rely on the semantics of C with regard
to pretty much anything.
Not at all. For example, I do not have to rely on the semantics of
trigraphs, since I avoid them like the plague.
You may still inadvertently fall upon them, if you're not extremely
careful. E.g.
puts("Huh??!");
This is more of an issue when automatically encoding binary data in
string literals (e.g. using a base64-style algorithm) that are supposed
to be used by C programs. You *must* check that you're not inadvertently
inserting a trigraph sequence in that string literal.
See, their semantics are haunting even the trigraph haters...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: Not at all. For example, I do not have to rely on the semantics of
trigraphs, since I avoid them like the plague.
You may still inadvertently fall upon them, if you're not extremely
careful. E.g.
puts("Huh??!");
Like for accidental failure to include <stdlib.h>, my compiler help me
by warning about such mishaps. And yes, this /has/ prevented mayhem once
or twice :-)
Best regards,
Sidney
Dan Pop wrote: [...]
If you don't use the appropriate command line options to enable such
warnings, that's more of a problem than casting malloc results can ever be.
In short, I think this argument is stale, and is getting staler all the
time.
Try a reality check: how many newbies have you seen enabling such
warnings when they show the way they compiled their code (quite often,
people posting here show their compilation command line)?
All too many, for sure. I wouldn't necessarily recommend malloc casting
to newbies. I wouldn't recommend C to newbies, for that matter.
And keep in mind that this discussion is focused on newbies, experienced
programmers have already defined their preference pro or con casting
void pointers and it is not this thread that is going to make them change
their minds (you will keep casting when this discussion is over, I will
keep avoiding such casts as the plague).
I agree on this for most part, except that this shows a level of
subtlety on this issue that does not rhyme well with the kind of
reactions that code samples with malloc casts invariably evokes
around here.
Best regards,
Sidney
[..snip...] to the comp.lang.c newsgroup. I find his argument compelling
because it is sound and *not* because of his "reputation".
[...snip...]
Hmmm...why do we _always_ find you on the opposite bank of the river ? ;)
Cheers,
Amarendra
--
Elementary, my dear Watson. -Holmes.
Ben Pfaff <bl*@cs.stanford.edu> wrote in message
[...snip...] This also avoids a potential problem wherein the roll resists
turning, thereby leading to excessive fragmentation ;-)
To avoid all such issues (mentioned here, as where as elsewhere in
this thread), we use water instead. ;)
Cheers,
Amarendra
In article <bv**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes: You are right. Stroustrup's opinion matters on C++, and your opinion
matters on C2, but neither of your (neither's of you?) opinion matters
on C. C++ is Stroustrup's language and C2 is yours, fine, you can keep
them. Neither of you has claim over C.
Yes, that was rather my point. (The "C2" language is purely an imaginary
invention, created for purposes of withering sarcasm - that may not have
been clear.) And actually, while I respect Stroustrop's opinions on C++,
I wouldn't follow them blindly either.
--
Michael Wojcik mi************@microfocus.com
In article <ls********************************@4ax.com>, Bob Doherty <rd*******@earthlink.net> writes: On 26 Jan 2004 20:50:02 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
I am continually amazed at people who think Stroustrop (I assume this
is whom you meant) magically gets the last word in this argument.
Stroustrop uses English carefully, and what he stated (in "The C++
Programming Language Third Edition") is subtly different, and compared
to Mark Bruno's statement above, defensible and correct.
Defensible, certainly, but I disagree with "correct".
He actually
states "However, *good* C programs tend to be C++ programs. For
example, every program in Kernighan and Ritchie, The C Programming
Language, 2nd Edition, is a C++ program."(emphasis in the original).
Yes, I've read that (in the Special Edition, but I believe it's the
same text there), and some of his other writings on the subject.
The second sentence may be correct (I haven't checked every program
in K&R2 to verify this claim). The former, however, is both subjective
("good") and vague ("tend"), so it has no claim to correctness.
Some of the features which make C programs not C++ programs are in fact
attributes of good C programs, as I define them; thus for me good C
programs tend not to be C++ programs.
In an appendix he gives an exhaustive treatment of when, and why, C
programs are not C++ programs, and when the two are semantically
different.
Indeed. I do not find this a compelling argument for his position
either. I also know the differences between the two languages - which
is good, since I write both C and C++ programs and I like to get them
as right as I can. Yet I have arrived at a different conclusion.
Stroustrop has his opinion on this subject. I don't think it's an
arbitrary, foolish, or malicious one (though I do suspect it's partly
motivated by his relationship to C++ - which is perfectly natural,
and of course he might well hold the same opinion in other circum-
stances). I just don't believe it's a matter of fact, as some people
seem to do.
--
Michael Wojcik mi************@microfocus.com
Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas
In article <news:40**********************@news.club-internet.fr>
magesh <ma*****@club-internet.fr> writes: ... I would like to know [why]
double* p = malloc(8*sizeof(double));==>OK for some here because
implicit coversion is well enough
but why
double* p = (double*) malloc(8*sizeof(double));==>NOK for some.
It is not so much a "not OK" as "causes more problems than it solves".
Consider, for instance, a (rather weak) analogy. Suppose that for
some reason you have an urgent need to travel 200 miles (or 300 km
in Europe :-) ) in about an hour. You can:
- drive your car at 200 mph (300 kph), or
- take a 500-mph plane, giving you about 30 minutes to get on
and off the plane at the two ends of the travel.
There are tradeoffs here, and neither solution is absolutely perfect
-- but one is statistically quite a bit more risky than the other.
Perhaps driving at 200 mph kills 17% of the people who do it, while
flying at 500 mph kills 0.0034% of people who do it.
In *my* experience -- which dates back to 1981, when I first
started using C -- it is "casting malloc" that is like "driving 200
mph". *Many* more programs that have a cast have been discovered
to be broken, yet produced no compile-time diagnostics at all.
Specifically, I have seen at least dozens, if not hundreds (I never
kept a count), of cases of code that failed at runtime due to casts
hiding a missing "#include <stdlib.h>" or other declaration of
malloc(). In the compilers we used in the 1980s (including VAX
PCC, Plauger's own Whitesmiths C, VAX/VMS C, and a number of C
compilers for IBM PCs), malloc() had type:
char *malloc();
and casts were required for all situations except "assigning the
result to a variable of type `char *'". Without the cast, you got
a diagnostic, contrary to what Dennis Ritchie's earliest C compilers
did. (Apparently, in the Bad Old Days of:
int i 3; /* initialize i to 3 */
and
printf(2, "error\n"); /* write to file descriptor 2 */
no diagnostics occurred for:
int malloc(); char *p; ... p = malloc(N);
I never used these compilers myself -- by 1981, it was apparently
clear to C compiler writers that this was a bad idea.)
Accordingly, in "K&R-1 C" -- i.e., C as described by the original
White Book and implemented by compilers like PCC and VAX/VMS C --
one usually had to cast malloc(). As a result, if one failed to
declare malloc(), it acquired the "implicit int" declaration. C
being C, writing:
int malloc(); /* implicit */
double *p = (double *)malloc(N * sizeof *p);
normally compiled warning-free. On many machines, it even worked --
but on some machines it failed. If you declared malloc correctly,
either by hand or by including some header file (stdlib.h did not
exist yet and the name and even existence of this header varied),
the code would work on those other machines too.
In December 1989, the ANSI X3J11 committee finalized the original
ANSI C standard; and in this C, the type of malloc() had changed
from:
char *malloc();
to:
void *malloc(size_t);
Moreover, "void *" (which had been a useless type that even caused
some compilers to core dump!) now existed, and had a special
assignment-conversion property. Because of this property, it was
now possible to remove the casts from old code, and create new code
without casts:
#include <stdlib.h>
...
double *p = malloc(N * sizeof *p);
Such code immediately drew a "diagnostic" -- always a "warning" in
every compiler I used in the 1990s -- if and only if you had
forgotten the "#include" (or a programmer-supplied declaration,
but if you had a Standard C compiler, including the standard header
was the obvious best choice).
In particular, this meant that programs could now be written such
that a VERY COMMON MISTAKE was found at compile time. And -- as
I said earlier -- I subsequently observed what I believe to be
thousands of potential runtime failures, and least dozens of actual
runtime failures, prevented in code in which the (existing) casts
were *removed* and the warning diagnostic fixed by adding the
missing "#include" line.
Had those casts been left in, or had new code been written using
those casts, I believe much more code would have eventually failed
during porting or testing or (most expensively) after distribution.
This leads to what *I* believe is an inescapable conclusion:
IF ONE WRITES IN ANSI C89 (or ISO C90), casting malloc
is not necessary, and adds HUGE amounts of risk.
There are some who argue (see other postings in this thread,
particularly those by Tak-Shing Chan) that, even in strict C89,
there are possible situation in which casting malloc also removes
some risk. But in the the last decade, while I have personally
observed huge numbers of of "failure to include <stdlib.h>" errors,
including dozens of cases in which real, in-use code DID fail
because of this combined with an unnecessary cast, I have never --
NOT ONCE -- seen a situation in which real, in-use code failed in
a way that would have been diagnosed at compile time had a cast
been used. In other words, we might restate the above as:
In C89, casting the result of malloc() has proven over time to
add significant risk of error, and has a theoretical chance of
reducing error. Statistically, code that does cast malloc()
contains many more errors than code that does not.
The only sensible conclusion to the above is that one should not
cast malloc()'s return value in this case -- only some sort of
external constraint (such as "I am not always using C89") could
change this.
Now, in C99, that huge risk -- the failure to declare malloc()
using "#include <stdlib.h>" -- has changed from a frequently-undiagnosed
error to a required-diagnostic error. In other languages that
vaguely resemble C, it has always required a diagnostic. Thus, in
these non-C89 languages, the biggest risk in casting malloc() has
been removed. So we can add:
IF ONE WRITES ONLY IN C99 (or some other non-C language),
casting the result of malloc() adds little if any risk of
error.
Of course, no one yet has a decade of experience in "time-tested"
or "proven" C99 risk-assessment -- the new standard has been in
existence for less than four years, and few compilers implement it
even today. (Whether you believe my own "time-tested, proven" C89
risk-assessment above is up to you, of course.)
In any case, each programmer (or person directing programmers and
thus setting standards for them) must make his own risk/reward
analysis. The risks of casting malloc() in C89 are, I think,
well-established and significant. The rewards are, I think,
nonexistent in practice -- the theoretical situations in which it
helps never occur in real code. The risks in C99 are far smaller;
and if you have additional constraints, or believe you will never
use a C89 compiler that lacks a "warn on implicit int" diagnostic,
your own risk may be smaller than that in "generic C89". In this
case, whether to cast becomes purely a style issue:
While there are many *wrong* styles, there is no single
*right* style.
My own style will continue to be "do not cast", because the casts
are still unnecessary (in C -- I am not writing C++ here and when
I write C++ I almost never use malloc()), and I find that removing
all unnecessary source code produces programs that are smaller,
faster, more comprehensible, and/or more maintainable. But just
as there are English-language styles in which one does not "omit
needless words" (see Strunk&White), there are such code styles too.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote: [snipped a well-balanced article concerning malloc() casting]
Amen to all that. I think you have accurately conveyed the majority view
here, while at the same time giving some attention to opposing views
without dismissing them out of hand. If something along these lines
could end up in the FAQ, that would be great.
Best regards, Sidney
In article <40**********************@news.club-internet.fr>,
magesh <ma*****@club-internet.fr> wrote: Well I am not sure to measure upto u guys, my question may be redundnant.
My question is this, if people pretend with their own arguments
that casting malloc return may cause undefined behaviour, I would like
to know
double* p = malloc(8*sizeof(double));==>OK for some here because
implicit coversion is well enough
but why
double* p = (double*) malloc(8*sizeof(double));==>NOK for some.
I assume that casting the malloc's return is just an indication for my
codevelopers who may see an assignement of p from a malloc a 500 or more
lines after my pointer declaration p.
If we prentend that implicit conversion is safe and the fact of casting
may cause UB due to probable alignement problems, its a bit difficult to
understant why implicit conversion may be safer than an explicit more
than a matter of style.
You missed the point completely. Correct casts are not a problem at all.
Incorrect casts are a problem. The compiler doesn't know whether a cast
is correct or incorrect. That leads to the principle that you should
_never_ use a cast unless you cannot avoid it.
int* p = malloc (2 * sizeof (int));
int* p = (int *) malloc (2 * sizeof (int));
do exactly the same thing. The cast has been used correctly. It didn't
do any damage, but it didn't help either.
extern int nalloc (size_t size);
int* p = nalloc (2 * sizeof (int));
int* p = (int *) nalloc (2 * sizeof (int));
In this case, the compiler can catch the error in the first statement,
but not in the second one. The cast did hide the error.
Apply the general principle (never cast unless it cannot be avoided),
and it is obvious that you shouldn't cast the result of malloc.
In article <bv**********@news.tudelft.nl>,
Sidney Cadot <si****@jigsaw.nl> wrote: Richard Bos wrote:
magesh <ma*****@club-internet.fr> wrote:
Well I am not sure to measure upto u guys, my question may be redundnant.
My question is this, if people pretend with their own arguments
that casting malloc return may cause undefined behaviour,
Nonsense - nobody has "pretended" that. Casting malloc() may _hide_
undefined behaviour which is present in the code whether there is a cast
or not. If you call malloc() without a declaration in scope for it, you
always invoke undefined behaviour. The cast doesn't change that fact.
What it does do is stop the compiler from telling you about it.
No, it does not actually. This argument may have been relevant 10 years
ago, but it is no longer. Sure, it's not a required diagnostic in C89
mode, but any halfway decent compiler is able to warn about an
undeclared malloc() nowadays.
If you don't use the appropriate command line options to enable such
warnings, that's more of a problem than casting malloc results can ever be.
In short, I think this argument is stale, and is getting staler all the
time.
It helps you in case you spelt the function name incorrectly.
In article <bv**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote: In <bv**********@news.tudelft.nl> Sidney Cadot <si****@jigsaw.nl> writes:
Dan Pop wrote:
If you ever have to change identifier names in your code, there is
something very wrong with your coding methodology.
To me, that sounds like a bizarre statement. Please elaborate.
The only *good* reason for renaming an identifier is because the original
name was improperly chosen. Hence my "bizarre" statement above.
The original name may have been chosen properly according to the
requirements that you knew at that time. When requirements change,
meanings can change and a name may not be chosen properly anymore.
Christian Bau wrote: extern int nalloc(size_t size);
int* p = nalloc(2*sizeof(int));
int* p = (int*)nalloc(2*sizeof(int));
In this case, the compiler can catch the error in the first statement,
but not in the second one. The cast did hide the error.
In this case, your example begs the question,
"What was the error in this example?"
Was nalloc supposed to return a pointer to an int?
In article <40**********@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote: Christian Bau wrote:
extern int nalloc(size_t size);
int* p = nalloc(2*sizeof(int));
int* p = (int*)nalloc(2*sizeof(int));
In this case, the compiler can catch the error in the first statement,
but not in the second one. The cast did hide the error.
In this case, your example begs the question,
"What was the error in this example?"
Was nalloc supposed to return a pointer to an int?
I'll have to repeat myself:
"Tisdale, you idiot, go away!"
magesh <ma*****@club-internet.fr> wrote in message news:<40**********************@news.club-internet.fr>...
I completely agree with the fact that proper header files should be
included, I would be amazed a proper C file that never calls a function
from stdlib, so normal programmers include them, if they give attention
to warnings from the compiler or else this thread is not meant for them.
But that's the whole point! Assume the programmer makes a mistake
and forgets to include the header. If he casts the return value from
malloc() he does not necessarily get a diagnostic; some compilers
give one if invoked in certain ways, many do not give one by default,
some do not give one no matter how they are invoked. On the other
hand, if he does not cast the return from malloc(), all C compilers
must give a diagnostic. Without the cast you will always get a
message; with the cast you might or might not get a message.
I remember one poster here presenting some sample code that included
a cast on malloc(). He was advised to remove the cast, and patiently
explained that he'd had to add the cast because without it he got
some strange message about 'invalid assignment'. If the mantra
'never cast malloc()' had been burned into his brain, he would have
had to think a little more or ask around to find what his bug was.
declaration of p 1000 lines before.
1001: p= malloc(sizeof(*p)*10);
could you tell me what type is p, while u are going through just this
part of ur code.
1) It is atrocious style to declare a pointer 1000 lines earlier,
especially if it is not used regularly enough for the reader to
already know what it is. Such code is unmaintainable.
2) Why do you care what type it is at the point where you malloc()
it? You might need to know soon afterwards, but I don't regard a
cast on a call to malloc() as an apropriate way of commenting code!
Reagrding code maintenance, the other solution p= malloc(sizeof(*p)*10);
may be easy to change the type of p without changing the malloc line in
ur code, after that?? the fact that the type of p has changed may have
more impact on other lines where u use them, than those on one malloc
statement!!!
Indeed, and the fewer such changes there are to be made, the more
likely that they'll be made correctly. The fewer changes there are,
the more quickly the overall update can be made. The fewer changes
there are, the lower the risk of introducing bugs. Maintainable
reliable code is written to adapt itself automatically to changes
as much as possible.
J. J. Farrell wrote: magesh wrote:
I completely agree with the fact that proper header files should be
included, I would be amazed a proper C file that never calls a function
from stdlib, so normal programmers include them, if they give attention
to warnings from the compiler or else this thread is not meant for them.
But that's the whole point! Assume [that]
the programmer makes a mistake and forgets to include the header.
If he casts the return value from malloc(),
he does not necessarily get a diagnostic;
some compilers give one if invoked in certain ways,
many do not give one by default,
some do not give one no matter how they are invoked.
Why should C programmers cobble their code
just to accommodate inferior C compilers?
On the other hand, if he does not cast the return from malloc(),
all C compilers must give a diagnostic.
A cryptic an misleading diagnostic if it doesn't tell the programmer
that the definition of malloc is missing.
Dan Pop <Da*****@cern.ch> wrote: In <bv**********@news.tudelft.nl> Sidney Cadot <si****@jigsaw.nl> writes:
Dan Pop wrote: Casting to double * not only doesn't add anything, because there is no
place left for the error you're talking about, but it is a maintenance
headache if the type of x ever needs to be changed, say to pointer
to long double: instead of making one change, you have to make two,
That's true. In fact, it's more of a "maintenance headache" than what
your preferred notation introduces when changing the identifier name
(but only slightly).
If you ever have to change identifier names in your code, there is
something very wrong with your coding methodology.
I admit that from time to time it becomes necessary to change an
identifiers name. That would IMHO be probably only be necessary with
file scope identifiers, as the usage of local identifiers is probably so
clear when you first type its name that it happens rather seldom to me
that I have to change its name. Sometimes when a file scope identifier
is not named carefully, it may become necessary to change its name, but
than there are tools to change one string into another, most editors can
do this within one step and if the usage is split over more files
"sed"-like tools are your friend.
IMHO it is very much easier to change an idenitifier everywhere it is
used, than searching all the code for "assumptions" about the type of an
identifier.
--
Z (Zo**********@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Someone notes that, if one follows the "comp.lang.c accepted
practice" of not casting malloc() return values, and uses most
ordinary C89/C90 compilers in their default non-warning modes
so that one gets only the required diagnostics, forgetting to
"#include <stdlib.h>" produces: A cryptic an misleading diagnostic if it doesn't tell the programmer
that the definition of malloc is missing.
For example, if one were to write:
struct zorg *new_zorg(double degree_of_evilness) {
struct zorg *new = malloc(sizeof *new);
new->degree = degree_of_evilness;
return new;
}
and feed it to the Generic C Compiler, one might get:
% cc -c zorg.c
zorg.c: In function `new_zorg':
zorg.c:4: warning: initialization makes pointer from integer without a cast
It is certainly true that this warning leaves something to be
desired. The problem is not making a "pointer from integer",
but rather with "malloc never explicitly declared, thus implicitly
declared instead". Nonetheless, this is hardly a *new* problem:
% cc -c oops.c
oops.c:6: syntax error before `for'
% cat oops.c
/* kind of like strlen() but returns an int *./
int like_strlen(const char *p) {
int i;
/* we just need to find the first p[i] that is '\0' */
for (i = 0; p[i] != 0; i++)
continue;
return i;
}
There is nothing wrong on line 6, nor line 5, nor 4 (blank), nor
3, nor even line 2 -- the problem is all the way back on line 1,
where a typographic error inserted a period between the * and /
meant to close the comment. There are all kinds of constructs like
this, where a compiler issues the wrong message. Programmers *need*
to learn not to trust where the machine points, in the same way
that automobile mechanics need to learn not to assume that, if the
On Board Diagnostics in an engine computer says "oxygen sensor
failure", it is not necessarily the sensor itself that failed.
(The problem can be in the wire connecting the sensor to the
computer. The sensor is a "replacement item" -- the ones in the
exhaust system in particular may have only a few years' lifetime
-- so the diagnostic is *usually* right, but not always.)
It is always a good idea to compare the machine's complaint against
what you (believe you) know to be the case. If the machine says
"you are making a pointer from an integer", but you know malloc()
does not return an integer, then you should ask yourself: where is
this integer? Why does the compiler believe there is an integer
here? Then, if all else fails, you could even post to comp.lang.c:
"I have this C code here, and the compiler is giving me a
message involving an `integer' when there is no integer.
Why is that?"
Ideally, you should include a complete, compileable chunk of code,
and the exact text of the error or warning message, too. But the
goal here -- besides fixing the problem -- is learning why a C
compiler might think there is an integer here, when you are certain
there is none. Then you will hear all about "implicit int function
declarations", why they are bad, that your compiler needs a tuneup
(e.g., "-Wmissing-declarations") if not a complete replacement,
and of course the inevitable cascade of "don't cast malloc in C /
compile your C code with an Ada-I-mean-C++-compiler" flamage. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote: Someone notes that, if one follows the "comp.lang.c accepted
practice" of not casting malloc() return values, and uses most
ordinary C89/C90 compilers in their default non-warning modes
so that one gets only the required diagnostics, forgetting to
"#include <stdlib.h>" produces:
A cryptic an misleading diagnostic if it doesn't tell the programmer
that the definition of malloc is missing.
For example, if one were to write:
struct zorg *new_zorg(double degree_of_evilness) {
struct zorg *new = malloc(sizeof *new);
new->degree = degree_of_evilness;
return new;
}
and feed it to the Generic C Compiler, one might get:
% cc -c zorg.c
zorg.c: In function `new_zorg':
zorg.c:4: warning: initialization makes pointer from integer without a cast
The problem is that you are using an inferior C compiler
or that you have forgotten the appropriate options:
cc -Wall -c zorg.c
zorg.c: In function `new_zorg':
zorg.c:6: warning: implicit declaration of function `malloc'
zorg.c:6: warning: initialization makes pointer from integer \
without a cast
This provides an *explicit* warning
of the implicit declaration of function `malloc'.
It is certainly true that this warning leaves something to be
desired. The problem is not making a "pointer from integer",
but rather with "malloc never explicitly declared, thus implicitly
declared instead". Nonetheless, this is hardly a *new* problem:
% cc -c oops.c
oops.c:6: syntax error before `for'
% cat oops.c
/* kind of like strlen() but returns an int *./
int like_strlen(const char *p) {
int i;
/* we just need to find the first p[i] that is '\0' */
for (i = 0; p[i] != 0; i++)
continue;
return i;
}
There is nothing wrong on line 6, nor line 5, nor 4 (blank), nor
3, nor even line 2 -- the problem is all the way back on line 1,
where a typographic error inserted a period between the * and /
meant to close the comment. There are all kinds of constructs like
this, where a compiler issues the wrong message. Programmers *need*
to learn not to trust where the machine points, in the same way
that automobile mechanics need to learn not to assume that, if the
On Board Diagnostics in an engine computer says "oxygen sensor
failure", it is not necessarily the sensor itself that failed.
(The problem can be in the wire connecting the sensor to the
computer. The sensor is a "replacement item" -- the ones in the
exhaust system in particular may have only a few years' lifetime
-- so the diagnostic is *usually* right, but not always.)
It is always a good idea to compare the machine's complaint against
what you (believe you) know to be the case. If the machine says
"you are making a pointer from an integer", but you know malloc()
does not return an integer, then you should ask yourself: where is
this integer? Why does the compiler believe there is an integer
here? Then, if all else fails, you could even post to comp.lang.c:
"I have this C code here, and the compiler is giving me a
message involving an `integer' when there is no integer.
Why is that?"
Ideally, you should include a complete, compilable chunk of code,
and the exact text of the error or warning message, too. But the
goal here -- besides fixing the problem -- is learning why a C
compiler might think there is an integer here, when you are certain
there is none. Then you will hear all about "implicit int function
declarations", why they are bad, that your compiler needs a tuneup
(e.g., "-Wmissing-declarations") if not a complete replacement,
and of course the inevitable cascade of "don't cast malloc in C /
compile your C code with an Ada-I-mean-C++-compiler" flamage. :-)
I know that you worked a long time on this
but it is a fallacious argument.
http://www.don-lindsay-archive.org/s...arguments.html
Your first example shows that you are using an inferior C compiler
or that you didn't know about the option that would give you
and explicit diagnostic of the true problem
or that you knew about the option and suppressed it:
Argument By Half Truth (Suppressed Evidence)
Your second example is a straw man and a bad analogy
because, unlike the first example, the compiler cannot recognize it
as an *acceptable* C program.
It probably isn't reasonable to expect a C compiler
to parse comments and diagnose typographical errors.
You can't compile your second example, but the first example:
expand zorg.c
#include<stdio.h>
struct zorg {
double degree;
};
struct zorg *new_zorg(double degree_of_evilness) {
struct zorg *new = malloc(sizeof *new);
new->degree = degree_of_evilness;
return new;
}
int main(int argc, char* argv[]) {
struct zorg* p = new_zorg(666.0);
fprintf(stdout, "%f = p->degree\n", p->degree);
free(p);
return 0;
}
compiles:
cc -Wall -std=c99 -pedantic -o zorg zorg.c
zorg.c: In function `new_zorg':
zorg.c:8: warning: implicit declaration of function `malloc'
zorg.c:8: warning: initialization makes pointer from integer \
without a cast
zorg.c: In function `main':
zorg.c:16: warning: implicit declaration of function `free'
and links and runs:
./zorg
666.000000 = p->degree
just fine on my system.
"E. Robert Tisdale" wrote: Chris Torek wrote:
.... snip ...
For example, if one were to write:
struct zorg *new_zorg(double degree_of_evilness) {
struct zorg *new = malloc(sizeof *new);
new->degree = degree_of_evilness;
return new;
}
and feed it to the Generic C Compiler, one might get:
% cc -c zorg.c
zorg.c: In function `new_zorg':
zorg.c:4: warning: initialization makes pointer from integer without a cast
The problem is that you are using an inferior C compiler
or that you have forgotten the appropriate options:
.... snip ...
I know that you worked a long time on this
but it is a fallacious argument.
Chris, I trust you are making suitable notes. Has anyone got a
decent Ascii Art version of 'His Masters Voice'. The ineffable
joy of sitting at the feet of the master!
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote: http://cbfalconer.home.att.net
Hi Chuck,
I found your resume: http://cbfalconer.home.att.net/cbf/cbfres03.htm
It says:
Education: McGill University, Honors Mathematics and Physics.
But it doesn't say when you graduated or what degree(s) you got.
It doesn't mention any formal training in computer science?
Did you retire after consulting for Otis Elevator in 2001?
Or have you simply neglected to update your resume?
In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote: CBFalconer wrote:
http://cbfalconer.home.att.net
Hi Chuck,
I found your resume:
http://cbfalconer.home.att.net/cbf/cbfres03.htm
It says:
Education: McGill University, Honors Mathematics and Physics.
But it doesn't say when you graduated or what degree(s) you got.
It doesn't mention any formal training in computer science?
Did you retire after consulting for Otis Elevator in 2001?
Or have you simply neglected to update your resume?
I think we have found ourselves a nice little stalker here?
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote in message news:<ch*********************************@slb-newsm1.svr.pol.co.uk>... In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
CBFalconer wrote:
http://cbfalconer.home.att.net
Hi Chuck,
I found your resume:
http://cbfalconer.home.att.net/cbf/cbfres03.htm
It says:
Education: McGill University, Honors Mathematics and Physics.
But it doesn't say when you graduated or what degree(s) you got.
It doesn't mention any formal training in computer science?
Did you retire after consulting for Otis Elevator in 2001?
Or have you simply neglected to update your resume?
I think we have found ourselves a nice little stalker here?
No, I think Mr. Tisdale is recruiting for NASA. They need a Canadian
for their one-way Mars mission.
[editing partly by me, partly by CBFalconer] Chris Torek wrote:[by omitting a needless cast, on] the Generic C Compiler, one might get:
zorg.c: In function `new_zorg':
zorg.c:4: warning: initialization makes pointer from integer without a cast
(which is not a very *good* diagnostic, but is at least a diagnostic.)
"E. Robert Tisdale" wrote: The problem is that you are using an inferior C compiler
or that you have forgotten the appropriate options:... snip ... I know that you worked a long time on this
but it is a fallacious argument.
In article <news:40***************@yahoo.com>
CBFalconer <cb********@worldnet.att.net> writes:Chris, I trust you are making suitable notes. Has anyone got a
decent Ascii Art version of 'His Masters Voice'. The ineffable
joy of sitting at the feet of the master!
Actually, he is not even a particularly good troll, in this case.
Note the attempt to specify the amount of time I "worked" on the
above (it is wrong; had I taken more time, I could have written a
much shorter article, to paraphrase Blaise Pascal). Old Usenet
hands should spot this sort of thing from miles away. :-)
More on topic, however (the only reason for a followup), ERT *does*
have a point, if not very well expressed.
Earlier, someone (I have forgotten who) quoted the old adage, "it
is a poor workman who blames his tools" -- and it is true that a
*good* workman can make do even with klunky or "inferior" tools,
such as the Generic C Compiler (which does not *have* "the appropriate
options" -- the error message's resemblance to another compiler's,
one that does have such an option, is sheer coincidence). But it
is also true that a good workman -- or "workperson", or perhaps
even "workunit" if we wish to be non-animist as well as nonsexist
:-) -- with good tools can do a better, faster, more thorough,
less-frustrating, and/or less-tiring job than the same entity with
the poor tools.
If Mr Tisdale simply said that he has neither sympathy nor empathy
for anyone stuck with a low-quality compiler, or even that he
personally refuses to use any compiler that lacks a "warn on use
of unprototyped function" diagnostic, I would have no argument.
Indeed, I encourage those with poor tools to obtain better ones.
At the same time, however, I acknowledge that these lower-quality
tools exist and are used every day; and I argue that "not casting
malloc" is the "belt-and-suspenders" approach, if you will, to
avoiding one particular common error. If one is sure of the quality
of one's suspenders, one should feel free to go about belt-less.
As another example, I myself refuse to limit my own code to six
monocase characters in external identifiers. I find this quite
constraining, and none of the systems I have dealt with in the last
15 to 20 years have had this limit -- though I did use a few that
had 7 or 8 characters, dual-case, in the mid-1980s. But while I
choose to do this, I do not tell others that they *should*. This
is one of thousands of tradeoffs one must make every day. The
trick when making such tradeoffs is comparing costs and benefits,
and "spending" the least for the most benefit. Some even choose
to spend effort compiling what they claim to be C code with C++
compilers -- which of course makes it C++ code instead, unless they
expend quite a lot more effort to avoid the various pitfalls that
can occur here. Presumably they find some benefit that I do not.
In short (perhaps too late for that, unless I were to work a long
time on this article), good tools are a good thing -- but if you
can easily write your code so that even the not-so-good tools catch
errors, you should consider doing so. In this case, the cost is
low, perhaps even zero or negative, and the benefit varies from
none (in the "good tools" case) to significant.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
On Sun, 01 Feb 2004 01:29:35 GMT, CBFalconer <cb********@yahoo.com>
wrote: Chris, I trust you are making suitable notes. Has anyone got a
decent Ascii Art version of 'His Masters Voice'. The ineffable
joy of sitting at the feet of the master!
WWKKWWWWWWKKWWWWWWKKWWWWWWKKWWKKWWWWKKWWWWKKWWWWWW WWKKWWWWKKWWWWWWWWWW
WWWWWWKKWWWWWWKKWWWWWWKKWWWWWWWWWWWWWWWWWWWWWWKKWW WWWWWWWWWWWWKKWWKKWW
WWKKWWWWKKWWWWWWWWKKWWWWWWWW.. WWWW WWWWWWKKWWKKWWKKWWWWWWWWWW
WWWWWWWWWWWWKKWWWWWWWWWW WWWWWWWWWWWWWWKKWWWWKK
WWKKWWKKWWWWWWWWKKWWWW WWWWKKWWKKWWWWWWWWWW
WWWWWWWWWWKKWWWWWW WWWWWWWWWWKKWWKKWW
WWKKWWKKWWWWKKWW WWWWKKWWWWWWWWWW
WWWWWWWWWWWWWW.. ,,::::.. WWWWWWWWKKWWWW
WWKKWWWWKKWWWW ,,iittttii,,::.. WWWWKKWWWWWWKK
WWWWWWWWWWKK ,,;;;;iittii;;,,,,,,:: ..,, WWWWKKWWWWWW
WWKKWWKKWWWW .. ::;;;;,,;;,,,,,,,,::.. :::: WWWWWWWWKKWW
WWWWWWWWWWWW ,,;;,,,,,,,,,,,,,,:: ,,.. ..KKWWWWWWWW
WWKKWWKKWW ..,,;;;;,,,,,,,,,,,,::.. ..,,,, ..WWKKWWKKWW
WWWWWWWWWW ::;;;;ii;;,,,,::,,::::::.. ::::;; WWWWWWWWWW
WWKKWWWWWW ..iiiiii;;,,,,,,::,,::,,::,,,,;;;;.. WWKKWWKKWW
WWWWWWKK ..;;iiiiii;;;;,,;;,,,,,,;;iiiiii;;.. WWWWWWWWWW
WWKKWWWW ,,;;iiiiii;;;;,,,,,,,,,,;;iiiiiiii.. WWWWKKWWWW
WWWWWWWW ::iiiiiiiiii;;;;;;,,,,,,;;;;;;;;ttii,, WWWWWWKK
WWKKWWKK ..;;;;iittLLGGttttttiiiiiiiittjjttiiiiii.. WWKKWWWW
WWWWWWWW ..;;;;iiffLLDDEEEEDDffttLLEEKKKKEELLfftt::.. WWWWWWWW
WWKKWWWW ..;;iittjjffffDDEEGGjjiiDDKKDDGGDDDDffjj;; WWKKWWWW
WWWWWWKKWW ..::;;;;iijjGGEEEEEEGGjj;;LLEEEEEEEEEELLjjii:: WWWWWWKK
WWKKWWWWWW ..,,;;;;iittiitttttttttt;;ffGGffffLLtt,,tttt:: WWWWKKWWWW
WWWWWWKKWWWW,,,,;;;;;;iiiiiiiiiitttt,,;;LLtttttt,, ;;ttLL,,WWKKWWWWWWWW
WWKKWWWWWWKKii,,;;ii;;;;,,;;,,iiii;;;;,,jjjjii;;;; ;;ttGG::WWWWWWWWKKWW
WWWWWWKKWWWWttiiiiii;;;;;;;;ttLLffttjjLLGGDDffiiii ttttLL WWKKWWWWWWWW
WWKKWWWWWWWWiiii;;;;;;ii;;ttGGLLEEEEEEKKKKDDLLjjff ffffff..WWWWWWKKWWWW
WWWWWWKKWWWWjjtt;;iiiiiittLLGGffLLLLDDEEDDDDGGLLff LLGGGG;;WWKKWWWWKKWW
WWKKWWWWKKWW;;iiiiiiiiiiffDDDDLLLLLLGGGGDDEEEEGGff GGGGGGttWWWWWWWWWWWW
WWWWWWWWWWWW,,iiiiiittttffDDEEDDEEEEGGEEKKKKEEffLL DDDDDDffKKWWKKWWKKWW
WWKKWWKKWW,,,,iittiiiittffGGttttttffLLGGGGGGLLjjLL DDEEEEttWWWWWWWWWWWW
WWWWWWWWiiiiiijjjjjjttffffffjjttjjGGGGGGLLGGLLGGDD DDEEEE;;WWWWKKWWKKWW
WWKKWWfftt;;LLjjffLLffffLLLLjjiittttjjLLffLLDDEEEE EEEEff;;iiWWWWWWWWWW
WWWWWW;;..ttEEttffLLGGGGLLLLffjjttttjjffLLDDEEKKKK KKKKLL,,ttttWWKKWWWW
WWWW::..,,ffEEffjjLLLLLLGGDDGGLLffLLLLLLDDEEKKKKKK EEKKDD,,::;;;;WWWWii
;;....;;ffLLEEDDttffLLGGLLLLGGEEEEEEEEKKKKKKKKEEKK EEEEEEii;;..,,,,;;tt
.....::jjGGGGDDEEffjjffLLLLffffffGGEEEEEEEEEEKKEEK KEEKKEEfftt;;::..::tt
...::;;jjDDDDGGEEGGiijjffGGffLLLLLLGGGGDDEEKKEEKKE EKKKKDDLLjjtt;;::::..
,,,,iiiiEEDDDDDDDDttttffLLLLLLGGLLGGDDEEEEEEKKEEDD KKEEDDffjjLLGGtt,,..
,,;;ttffDDEEDDDDEELLttjjLLLLLLGGLLDDEEEEEEEEEEDDDD KKDDLLffGGEEEEtt,,::
,,;;iiGGGGEEKKEEEEDDjjttffffLLLLDDGGDDDDEEGGDDDDEE GGLLjjDDEEKKLLii,,,,
;;iiiiLLEEDDEEEEDDDDffffffjjffLLGGGGDDGGLLGGGGDDLL GGLLEEEEKKGGjjii;;;;
iiiittttLLEEEEEEKKKKjjttffffjjffffffjjffffLLDD;;GG KKKKKKEEDDffttii;;;;
iiiiiittffLLGGDDEEKKDDffffffjjjjttttiittffjjiittKK KKEEEEGGLLttiiii;;;;
iiiittiiffffjjffjjLLDDEEDDLLttjjjjjjttjjttffKKKKDD GGGGLLLLttttiiii;;;;
iiiiiittttjjffjjffffffLLDDEEEELLffffjjttDDKKKKDDGG GGffffffttiiii;;;;ii
iiiiiittttttjjjjjjjjffffffLLLLGGDDffffEEEEDDGGGGLL LLffjjttiiii;;iiiiii
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote: J. J. Farrell wrote: If he casts the return value from malloc(),
he does not necessarily get a diagnostic;
some compilers give one if invoked in certain ways,
many do not give one by default,
some do not give one no matter how they are invoked.
Why should C programmers cobble their code
just to accommodate inferior C compilers?
Then again, why should C programmers cobble their code just to
accomodate inferior C++ compilers?
Richard
Severian <se******@chlamydia-is-not-a-flower.com> wrote in message news:<fd********************************@4ax.com>. .. On Sun, 01 Feb 2004 01:29:35 GMT, CBFalconer <cb********@yahoo.com>
wrote:
Chris, I trust you are making suitable notes. Has anyone got a
decent Ascii Art version of 'His Masters Voice'. The ineffable
joy of sitting at the feet of the master!
WWKKWWWWWWKKWWWWWWKKWWWWWWKKWWKKWWWWKKWWWWKKWWWWWW WWKKWWWWKKWWWWWWWWWW
WWWWWWKKWWWWWWKKWWWWWWKKWWWWWWWWWWWWWWWWWWWWWWKKWW WWWWWWWWWWWWKKWWKKWW
WWKKWWWWKKWWWWWWWWKKWWWWWWWW.. WWWW WWWWWWKKWWKKWWKKWWWWWWWWWW
WWWWWWWWWWWWKKWWWWWWWWWW WWWWWWWWWWWWWWKKWWWWKK
WWKKWWKKWWWWWWWWKKWWWW WWWWKKWWKKWWWWWWWWWW
WWWWWWWWWWKKWWWWWW WWWWWWWWWWKKWWKKWW
WWKKWWKKWWWWKKWW WWWWKKWWWWWWWWWW
WWWWWWWWWWWWWW.. ,,::::.. WWWWWWWWKKWWWW
WWKKWWWWKKWWWW ,,iittttii,,::.. WWWWKKWWWWWWKK
WWWWWWWWWWKK ,,;;;;iittii;;,,,,,,:: ..,, WWWWKKWWWWWW
WWKKWWKKWWWW .. ::;;;;,,;;,,,,,,,,::.. :::: WWWWWWWWKKWW
WWWWWWWWWWWW ,,;;,,,,,,,,,,,,,,:: ,,.. ..KKWWWWWWWW
WWKKWWKKWW ..,,;;;;,,,,,,,,,,,,::.. ..,,,, ..WWKKWWKKWW
WWWWWWWWWW ::;;;;ii;;,,,,::,,::::::.. ::::;; WWWWWWWWWW
WWKKWWWWWW ..iiiiii;;,,,,,,::,,::,,::,,,,;;;;.. WWKKWWKKWW
WWWWWWKK ..;;iiiiii;;;;,,;;,,,,,,;;iiiiii;;.. WWWWWWWWWW
WWKKWWWW ,,;;iiiiii;;;;,,,,,,,,,,;;iiiiiiii.. WWWWKKWWWW
WWWWWWWW ::iiiiiiiiii;;;;;;,,,,,,;;;;;;;;ttii,, WWWWWWKK
WWKKWWKK ..;;;;iittLLGGttttttiiiiiiiittjjttiiiiii.. WWKKWWWW
WWWWWWWW ..;;;;iiffLLDDEEEEDDffttLLEEKKKKEELLfftt::.. WWWWWWWW
WWKKWWWW ..;;iittjjffffDDEEGGjjiiDDKKDDGGDDDDffjj;; WWKKWWWW
WWWWWWKKWW ..::;;;;iijjGGEEEEEEGGjj;;LLEEEEEEEEEELLjjii:: WWWWWWKK
WWKKWWWWWW ..,,;;;;iittiitttttttttt;;ffGGffffLLtt,,tttt:: WWWWKKWWWW
WWWWWWKKWWWW,,,,;;;;;;iiiiiiiiiitttt,,;;LLtttttt,, ;;ttLL,,WWKKWWWWWWWW
WWKKWWWWWWKKii,,;;ii;;;;,,;;,,iiii;;;;,,jjjjii;;;; ;;ttGG::WWWWWWWWKKWW
WWWWWWKKWWWWttiiiiii;;;;;;;;ttLLffttjjLLGGDDffiiii ttttLL WWKKWWWWWWWW
WWKKWWWWWWWWiiii;;;;;;ii;;ttGGLLEEEEEEKKKKDDLLjjff ffffff..WWWWWWKKWWWW
WWWWWWKKWWWWjjtt;;iiiiiittLLGGffLLLLDDEEDDDDGGLLff LLGGGG;;WWKKWWWWKKWW
WWKKWWWWKKWW;;iiiiiiiiiiffDDDDLLLLLLGGGGDDEEEEGGff GGGGGGttWWWWWWWWWWWW
WWWWWWWWWWWW,,iiiiiittttffDDEEDDEEEEGGEEKKKKEEffLL DDDDDDffKKWWKKWWKKWW
WWKKWWKKWW,,,,iittiiiittffGGttttttffLLGGGGGGLLjjLL DDEEEEttWWWWWWWWWWWW
WWWWWWWWiiiiiijjjjjjttffffffjjttjjGGGGGGLLGGLLGGDD DDEEEE;;WWWWKKWWKKWW
WWKKWWfftt;;LLjjffLLffffLLLLjjiittttjjLLffLLDDEEEE EEEEff;;iiWWWWWWWWWW
WWWWWW;;..ttEEttffLLGGGGLLLLffjjttttjjffLLDDEEKKKK KKKKLL,,ttttWWKKWWWW
WWWW::..,,ffEEffjjLLLLLLGGDDGGLLffLLLLLLDDEEKKKKKK EEKKDD,,::;;;;WWWWii
;;....;;ffLLEEDDttffLLGGLLLLGGEEEEEEEEKKKKKKKKEEKK EEEEEEii;;..,,,,;;tt
....::jjGGGGDDEEffjjffLLLLffffffGGEEEEEEEEEEKKEEKK EEKKEEfftt;;::..::tt
..::;;jjDDDDGGEEGGiijjffGGffLLLLLLGGGGDDEEKKEEKKEE KKKKDDLLjjtt;;::::..
,,,,iiiiEEDDDDDDDDttttffLLLLLLGGLLGGDDEEEEEEKKEEDD KKEEDDffjjLLGGtt,,..
,,;;ttffDDEEDDDDEELLttjjLLLLLLGGLLDDEEEEEEEEEEDDDD KKDDLLffGGEEEEtt,,::
,,;;iiGGGGEEKKEEEEDDjjttffffLLLLDDGGDDDDEEGGDDDDEE GGLLjjDDEEKKLLii,,,,
;;iiiiLLEEDDEEEEDDDDffffffjjffLLGGGGDDGGLLGGGGDDLL GGLLEEEEKKGGjjii;;;;
iiiittttLLEEEEEEKKKKjjttffffjjffffffjjffffLLDD;;GG KKKKKKEEDDffttii;;;;
iiiiiittffLLGGDDEEKKDDffffffjjjjttttiittffjjiittKK KKEEEEGGLLttiiii;;;;
iiiittiiffffjjffjjLLDDEEDDLLttjjjjjjttjjttffKKKKDD GGGGLLLLttttiiii;;;;
iiiiiittttjjffjjffffffLLDDEEEELLffffjjttDDKKKKDDGG GGffffffttiiii;;;;ii
iiiiiittttttjjjjjjjjffffffLLLLGGDDffffEEEEDDGGGGLL LLffjjttiiii;;iiiiii
Nice sig!
MSG <ms*****@yahoo.com> scribbled the following: Severian <se******@chlamydia-is-not-a-flower.com> wrote in message news:<fd********************************@4ax.com>. .. On Sun, 01 Feb 2004 01:29:35 GMT, CBFalconer <cb********@yahoo.com>
wrote:
>Chris, I trust you are making suitable notes. Has anyone got a
>decent Ascii Art version of 'His Masters Voice'. The ineffable
>joy of sitting at the feet of the master!
WWKKWWWWWWKKWWWWWWKKWWWWWWKKWWKKWWWWKKWWWWKKWWWWWW WWKKWWWWKKWWWWWWWWWW
WWWWWWKKWWWWWWKKWWWWWWKKWWWWWWWWWWWWWWWWWWWWWWKKWW WWWWWWWWWWWWKKWWKKWW
WWKKWWWWKKWWWWWWWWKKWWWWWWWW.. WWWW WWWWWWKKWWKKWWKKWWWWWWWWWW
WWWWWWWWWWWWKKWWWWWWWWWW WWWWWWWWWWWWWWKKWWWWKK
WWKKWWKKWWWWWWWWKKWWWW WWWWKKWWKKWWWWWWWWWW
WWWWWWWWWWKKWWWWWW WWWWWWWWWWKKWWKKWW
WWKKWWKKWWWWKKWW WWWWKKWWWWWWWWWW
WWWWWWWWWWWWWW.. ,,::::.. WWWWWWWWKKWWWW
WWKKWWWWKKWWWW ,,iittttii,,::.. WWWWKKWWWWWWKK
WWWWWWWWWWKK ,,;;;;iittii;;,,,,,,:: ..,, WWWWKKWWWWWW
WWKKWWKKWWWW .. ::;;;;,,;;,,,,,,,,::.. :::: WWWWWWWWKKWW
WWWWWWWWWWWW ,,;;,,,,,,,,,,,,,,:: ,,.. ..KKWWWWWWWW
WWKKWWKKWW ..,,;;;;,,,,,,,,,,,,::.. ..,,,, ..WWKKWWKKWW
WWWWWWWWWW ::;;;;ii;;,,,,::,,::::::.. ::::;; WWWWWWWWWW
WWKKWWWWWW ..iiiiii;;,,,,,,::,,::,,::,,,,;;;;.. WWKKWWKKWW
WWWWWWKK ..;;iiiiii;;;;,,;;,,,,,,;;iiiiii;;.. WWWWWWWWWW
WWKKWWWW ,,;;iiiiii;;;;,,,,,,,,,,;;iiiiiiii.. WWWWKKWWWW
WWWWWWWW ::iiiiiiiiii;;;;;;,,,,,,;;;;;;;;ttii,, WWWWWWKK
WWKKWWKK ..;;;;iittLLGGttttttiiiiiiiittjjttiiiiii.. WWKKWWWW
WWWWWWWW ..;;;;iiffLLDDEEEEDDffttLLEEKKKKEELLfftt::.. WWWWWWWW
WWKKWWWW ..;;iittjjffffDDEEGGjjiiDDKKDDGGDDDDffjj;; WWKKWWWW
WWWWWWKKWW ..::;;;;iijjGGEEEEEEGGjj;;LLEEEEEEEEEELLjjii:: WWWWWWKK
WWKKWWWWWW ..,,;;;;iittiitttttttttt;;ffGGffffLLtt,,tttt:: WWWWKKWWWW
WWWWWWKKWWWW,,,,;;;;;;iiiiiiiiiitttt,,;;LLtttttt,, ;;ttLL,,WWKKWWWWWWWW
WWKKWWWWWWKKii,,;;ii;;;;,,;;,,iiii;;;;,,jjjjii;;;; ;;ttGG::WWWWWWWWKKWW
WWWWWWKKWWWWttiiiiii;;;;;;;;ttLLffttjjLLGGDDffiiii ttttLL WWKKWWWWWWWW
WWKKWWWWWWWWiiii;;;;;;ii;;ttGGLLEEEEEEKKKKDDLLjjff ffffff..WWWWWWKKWWWW
WWWWWWKKWWWWjjtt;;iiiiiittLLGGffLLLLDDEEDDDDGGLLff LLGGGG;;WWKKWWWWKKWW
WWKKWWWWKKWW;;iiiiiiiiiiffDDDDLLLLLLGGGGDDEEEEGGff GGGGGGttWWWWWWWWWWWW
WWWWWWWWWWWW,,iiiiiittttffDDEEDDEEEEGGEEKKKKEEffLL DDDDDDffKKWWKKWWKKWW
WWKKWWKKWW,,,,iittiiiittffGGttttttffLLGGGGGGLLjjLL DDEEEEttWWWWWWWWWWWW
WWWWWWWWiiiiiijjjjjjttffffffjjttjjGGGGGGLLGGLLGGDD DDEEEE;;WWWWKKWWKKWW
WWKKWWfftt;;LLjjffLLffffLLLLjjiittttjjLLffLLDDEEEE EEEEff;;iiWWWWWWWWWW
WWWWWW;;..ttEEttffLLGGGGLLLLffjjttttjjffLLDDEEKKKK KKKKLL,,ttttWWKKWWWW
WWWW::..,,ffEEffjjLLLLLLGGDDGGLLffLLLLLLDDEEKKKKKK EEKKDD,,::;;;;WWWWii
;;....;;ffLLEEDDttffLLGGLLLLGGEEEEEEEEKKKKKKKKEEKK EEEEEEii;;..,,,,;;tt
....::jjGGGGDDEEffjjffLLLLffffffGGEEEEEEEEEEKKEEKK EEKKEEfftt;;::..::tt
..::;;jjDDDDGGEEGGiijjffGGffLLLLLLGGGGDDEEKKEEKKEE KKKKDDLLjjtt;;::::..
,,,,iiiiEEDDDDDDDDttttffLLLLLLGGLLGGDDEEEEEEKKEEDD KKEEDDffjjLLGGtt,,..
,,;;ttffDDEEDDDDEELLttjjLLLLLLGGLLDDEEEEEEEEEEDDDD KKDDLLffGGEEEEtt,,::
,,;;iiGGGGEEKKEEEEDDjjttffffLLLLDDGGDDDDEEGGDDDDEE GGLLjjDDEEKKLLii,,,,
;;iiiiLLEEDDEEEEDDDDffffffjjffLLGGGGDDGGLLGGGGDDLL GGLLEEEEKKGGjjii;;;;
iiiittttLLEEEEEEKKKKjjttffffjjffffffjjffffLLDD;;GG KKKKKKEEDDffttii;;;;
iiiiiittffLLGGDDEEKKDDffffffjjjjttttiittffjjiittKK KKEEEEGGLLttiiii;;;;
iiiittiiffffjjffjjLLDDEEDDLLttjjjjjjttjjttffKKKKDD GGGGLLLLttttiiii;;;;
iiiiiittttjjffjjffffffLLDDEEEELLffffjjttDDKKKKDDGG GGffffffttiiii;;;;ii
iiiiiittttttjjjjjjjjffffffLLLLGGDDffffEEEEDDGGGGLL LLffjjttiiii;;iiiiii
Nice sig!
Sig? What sig?
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
On 3 Feb 2004 12:21:35 -0800, ms*****@yahoo.com (MSG) wrote: Severian <se******@chlamydia-is-not-a-flower.com> wrote in message news:<fd********************************@4ax.com>. .. On Sun, 01 Feb 2004 01:29:35 GMT, CBFalconer <cb********@yahoo.com>
wrote:
>Chris, I trust you are making suitable notes. Has anyone got a
>decent Ascii Art version of 'His Masters Voice'. The ineffable
>joy of sitting at the feet of the master!
<snip>
Nice sig!
That was no sig, it was Ascii Art of ERT, the Trollmaster himself,
since I don't have one of 'His Master's Voice'.
--
Sev
On 26 Jan 2004 18:50:46 -0800, qe*@pobox.com (Paul Hsieh) wrote:
<snip> No, its a language weakness issue. One of the few good things to come
out of the C99 spec is the adoption of C++'s requirement for
prototype, and not assuming the default: int ()(int) . <snip>
C99 does not require prototype forms. It does (changed from C90)
require that functions be *declared* before use; that declaration may
be either prototype or old-style/K&R1; the former is preferable, but
not required. In C90 if you did not declare a function, it was
implicitly int ()() -- unspecified args, not one (of type) int.
- David.Thompson1 at worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: hermit_crab67 |
last post by:
Can someone explain to a C newbie why this doesn't work as I expect it
to work? (expectations clearly outlined in the printf statement in
main routine)
OS: Linux 2.4.26
GCC: 2.95.4
void...
|
by: ytrama |
last post by:
Hi,
I have read in one of old posting that don't cast of pointer which
is returned by the malloc. I would like to know the reason.
Thanks in advance,
YTR
|
by: alex.j.k2 |
last post by:
Hello all,
I have "PRECISION" defined in the preprocessor code
and it could be int, float or double, but I do not know in the
code what it is.
Now if I want to assign zero to a "PRECISION"...
|
by: Tinkertim |
last post by:
Hi,
I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.
For instance :
...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
