on not casting malloc

[Jordan Abel]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
# ifdef __cplusplus
# include <cstdlib>

struct voidptr_ {
void *x;
template <typename T> inline operator T * () {
return ((T *) x);
}
};

static inline voidptr_ malloc_(size_t n)
{
return (voidptr_) {
malloc(n)
};
}

# define malloc(x) malloc_(x)

template<typename T> static inline void free(T *x) {
free((void *)x);
}

template<typename T> static inline T *realloc(T *x, size_t n) {
return (T *)realloc((void*)x,n);
}

# else /* C */
# include <stdlib.h>
# ifdef __GNUC__
# define realloc(p,s) ((__typeof__(p))(realloc(p,s)))
# endif /* GNU C */
# endif /* C++/C */
#define tcalloc(n,T) ((T*)(calloc(n,sizeof(T))))
#endif /* incl guard */

 

[Victor Bazarov]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

V

 

[Jordan Abel]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

 

[Ben Pope]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

Take a closer look at the bit Victor quoted.

Ben Pope

 

[Victor Bazarov]

Jordan Abel wrote:

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

Take a closer look at the bit Victor quoted.

Well, that's probably a simple typo. It's good that you've caught it,
but my question was in general, not about those particular two lines.

V

 

[Victor Bazarov]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

V

 

[peter koch]

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of C-code.

Jordan Abel wrote:

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of existing C-code. In that case I do find some value in
it, so long as it is not meant to be a permanent solution. If the
purpose is to allow C++ code to call malloc, I agree that this is ugly
and should be forbidden.

/Peter

 

[Victor Bazarov]

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of C-code.

Jordan Abel wrote:


Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?


Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of existing C-code. In that case I do find some value in
it, so long as it is not meant to be a permanent solution.

I am honestly disappointed that you would find "some value in it". If I
were to port existing C code, I would expect the C++ compiler to _scream_
at me for every use of 'malloc' so that I would be *forced* either to
change it to 'new' or at least put an explicit cast that can be searched
later and weeded out...

Of course, I can later search the code for 'malloc' and take care of it...

So the point is moot, I guess. Possibly it's just my knee-jerk reaction
to the original proposal

> If the
purpose is to allow C++ code to call malloc, I agree that this is ugly
and should be forbidden.

/Peter

V

 

[Jordan Abel]

Jordan Abel wrote:

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

While the reason for forbidding implicit conversion of pointer to void
in general has been explained to my satisfaction, the explanation I was
given does not justify having to do it for malloc in particular. Note
that I did not have realloc return a "voidptr_", and I went to some
effort to provide a reasonable solution for calloc also without doing
so.

 

[Jordan Abel]

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of C-code.

Jordan Abel wrote:



Jordan Abel wrote:


Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
[...]

And how do you think it's going to benefit its user?


Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of existing C-code. In that case I do find some value in
it, so long as it is not meant to be a permanent solution.

I am honestly disappointed that you would find "some value in it". If I
were to port existing C code, I would expect the C++ compiler to _scream_
at me for every use of 'malloc' so that I would be *forced* either to
change it to 'new' or at least put an explicit cast that can be searched
later and weeded out...

Of course, I can later search the code for 'malloc' and take care of it...

So the point is moot, I guess. Possibly it's just my knee-jerk reaction
to the original proposal

Sometimes when interacting with existing libraries written in C, you
_need_ to use malloc/free instead of new/delete. Some library functions
will require something that can be realloc'ed internally, or will return
something that needs to be free'd.

C++ code is already permitted to call malloc. This just provides a way
to do it without adding a cast that can hide warnings that are still
needed in C. It's certainly a better solution than defining a macro that
does the cast for you.