Re: why still use C?

From: Sidney Cadot (sidney_at_jigsaw.nl)
Date: 10/21/03 

Date: Tue, 21 Oct 2003 02:37:39 +0200

Mark McIntyre wrote:

> On Mon, 20 Oct 2003 01:30:19 +0200, in comp.lang.c , Sidney Cadot
> <sidney@jigsaw.nl> wrote:
>
>
>>Mark McIntyre wrote:
>>
>>
>>>>If I have the expression...
>>>> malloc(1000*sizeof(double))
>>>>
>>>>...with the intent of using its value as a 1000-element array of doubles
>>>>later on, it should have type (double *), not type (void *). Since
>>>>malloc() doesn't know this,
>>>
>>>but the compiler does, because you assign the return of malloc to a
>>>double*.
>>
>>Please read carefully. I was talking about the malloc expression, not
>>the assignment expression.
>
> Please *think* carefully. malloc() itself has *no need* to know the
> type of what you're going to point the memory to later.

I never said it did.

> The soonest anything needs to know is when the result of
> malloc is assigned to a pointer.

In between these two instants (at compile time), an expression is alive.
That expression should (as I, the programmer, know) be of type double*,
but alas, poor malloc() gives me a void* because it doesn't know.
Therefore, I (the programmer) force the correct type onto the pointer
(this actually happens, i.e., takes clockcycles, at compile-time). Then
this has become a properly typed pointer expression and the compiler can
move on to its other duties, which may (who knows?) be to generate code
for an assignment.

>>>>I will help the compiler a bit to change the
>>>>returned value to (double *) ASAP.
>>>
>>>
>>>The compiler doesn't need this help. It automatically does it just as
>>>soon as possible, merely because you assigned it to a double. It can't
>>>happen any faster than that.
>>
>>... So how to you explain the error on:
>>
>>int *x = (double *)malloc(1000*sizeof(double))
>
> The only error here is in using a poor style.

Look again.... I'd like you to consider why it is that this fragment
gives an incompatible pointer type error, in the context of your earlier
claim "It can't happen any faster than that".

> int *x = malloc (1000 * sizeof *x); // look ma, no possible errors

Fine.

> Plus, just in case it slipped your attention during your increasingly
> frenzied defence, the insertion of the cast doesn't help the compiler
> either.

I think you missed my point. Otherwise, you might have disagreed. But
there _was_ a point, you know.

>>>Then your experience is more limited than you think.
>>If it makes you happy to think so, be my guest.
>
> It makes me /un/happy to think that someone who's exhibiting such
> limited experience and muddle headed thinking can fail to see their
> glaring mistakes.

I decline to dignify your rudely worded remarks with a response.

>>>>But to answer your question: No, since this doesn't help to reduce
>>>>mistakes in my C code I don't. C++ however can help in that respect.
>>>
>>>No, it can't. It can only *introduce* them, or fool you into thinking
>>>you've found an error that is NOT an error.
>>
>>I chose the word "mistakes" on purpose, and you're talking about an
>>"error". These two are different things (e.g., passing an integer to an
>>enum parameter is not an error in C, but in my coding style it's a mistake).
>
> *shrug*. I can't help it if you insist in using C++ idioms but writing
> C. Why not just write C++ ?

See my response to Cody on October 5th.

>>>>>>What C compiler would you recommend, if I want a warning on an integer
>>>>>>being passed for an enum parameter (as in my example)? Or would you say
>>>>>>that I am wrong in wanting this?
>>>>>
>>>>>since "The expression that defines the value of an enumeration
>>>>>constant shall be an integer constant expression that has a value
>>>>>representable as an int." [6.7.2.2(2)] I don't see that it makes no
>>>>>sense to expect any C compiler to complain about this. C is not C++.
>>
>>That does not answer my question.
>
> Yes it does. You're being obtuse, or stupid, or silly, either is
> applicable.

I had to look up obtuse in a thesaurus, which leads me to believe you're
not being nice. Having a debate is one thing, calling names is another.
Could we just stick to an exchange of arguments?

>>>"Being a practical person", please provide an example of C code in
>>>which the fact that you pass an int where an int is expected, matters.
>>
>>If you like using ints and enums interchangeably, that's fine by me.
>>Just don't expect the same of me please.
>
>
> And now answer the question.

"Please", is the proper idiom, in the English language, anyway.

I took it you meant "int where an enum" is expected, and implicitly
equated "enum" to "int", since you've made clear you felt that way.

If this is true, refer to my enum example a couple of posts ago.

If not, I think it's a strange question, but in order to avoid any
misunderstandings, here you go:

int f(int x) { return x; }
int main(void)
{
   f(3);
   return 0;
}

If you meant it in another way, could you rephrase the question, please?

Best regards,

   Sidney Cadot

Relevant Pages

  • Re: Pointer to small amount of storage
    ... int main ... is the code valid and q indeterminate? ... q becomes a dangling pointer (*IF* malloc does not return NULL) ... after the assignment. ...
    (comp.lang.c)
  • enum
    ... assignment is not allowed (which I ... enum TESTA ... int main ...
    (comp.lang.cpp)
  • Re: memory allocation questions (newbie)
    ... But if malloc returns a void*, how this assignment ... is legal (force p that's a int* to a return value that it's void*)? ...
    (comp.lang.c)
  • Re: New C features proposal
    ... int sum; ... prototype thus the following would be illegal: ... void f1; ... void message(const char *msg, enum level level=LVL_WARN, ...
    (comp.std.c)
  • [git patches] net driver updates for .27
    ... static int lance_open (struct net_device *dev) ... enum mac8390_type type); ... unsigned int fifo_count, timeout, reg; ...
    (Linux-Kernel)