Paul Eggert wrote:
> There's gotta be a better way.
>
> I installed the following
Look fine. Thanks!
> I prefer macros like "static_inline" and
> "long_double" when defining macros that stand for their standard
> counterparts like "static inline" and "long double".
Well, I agree that 'long_doub
Paul Eggert wrote:
> Hmm, what if GCC's __NO_INLINE__ macro is defined? Shouldn't
> m4/inline.m4 define HAVE_INLINE only if __NO_INLINE__ is not defined?
Yes. I applied this.
2006-11-08 Bruno Haible <[EMAIL PROTECTED]>
* m4/inline.m4 (gl_INLINE): Also test __NO_INLINE__.
Sugge
Bruno Haible <[EMAIL PROTECTED]> writes:
> The purpose of HAVE_INLINE is to avoid bloating the binary when compiling
> with a compiler that doesn't support 'inline'. With such a compiler,
> AC_C_INLINE defines 'inline' to empty, and such older compilers don't
> optimize away unused static function
Hi Paul,
In case HAVE_INLINE is not defined, xnmalloc is not an inline function.
XNMALLOC (n, char) was optimized to a single xmalloc call. Can we restore
this optimization?
2006-11-06 Bruno Haible <[EMAIL PROTECTED]>
* lib/xalloc.h (XNMALLOC): Restore optimization of sizeof(T) = 1 cas
Paul Eggert wrote:
> I noticed that the other changes in that patch never invoke
> xcharalloc (n); they always invoked XNMALLOC (n, char) instead.
> If that's the preferred usage, perhaps we should remove xcharalloc?
> On the other hand I prefer not using macros (which is why I added
> xcharalloc i
Paul Eggert wrote:
> HAVE_INLINE isn't defined by xalloc.m4 or any of xalloc's prerequisites.
Oops, thanks for noticing that. I'm adding this.
2006-11-06 Bruno Haible <[EMAIL PROTECTED]>
* m4/inline.m4: New file.
* m4/gl_list.m4 (gl_LIST): Require gl_INLINE.
* modules/
Bruno Haible <[EMAIL PROTECTED]> writes:
> ! /* Return a pointer to a new buffer of N bytes. This is like xmalloc,
> !except it returns char *.
> !xcharalloc (N) is equivalent to XNMALLOC (N, char). */
> static inline char *
> ! xcharalloc (size_t n)
> {
> ! return (char *) xmalloc
Paul Eggert wrote:
> > #ifdef __cplusplus
> > #define XALLOC_WITH_EXPRESSION(N,EXPR) xalloc_with_expression (N, &(EXPR))
>
> That doesn't look right in general, since there can be side effects in
> computing the address of EXPR.
And also, if the programmer writes
result = XALLOC_WITH_EXPRESSIO
Bruno Haible <[EMAIL PROTECTED]> writes:
>> #define XNMALLOC(n, t) ((t *) xnmalloc (n, sizeof (t)))
>> #define XCALLOC(n, t) ((t *) xcalloc (n, sizeof (t)))
>
> Yes, this looks good. I'll use these names.
OK.
> #ifdef __cplusplus
> #define XALLOC_WITH_EXPRESSION(N,EXPR) xalloc_with_expression
Paul Eggert wrote:
> If you look at the context of those lines in getgroups.c and
> group-member.c, you'll see that those lines are OK. (So I'm afraid
> the "sinner" is whoever's in charge of the rest. :-)
Yes. But in the group-member.c case, a macro that invokes xnmalloc would
simplify your cod
Bruno Haible <[EMAIL PROTECTED]> writes:
> clean-temp.c:277: xmalloc (new_allocated * sizeof (struct tempdir *
> volatile));
> fatal-signal.c:210: xmalloc (new_actions_allocated * sizeof
> (actions_entry_t));
> fstrcmp.c:623: buffer = (int *) xmalloc (bufmax * (2 * sizeof (int
Paul Eggert wrote:
> I installed this patch instead.
Thanks.
> I prefer to put it into a C++ ghetto area of the code.
I was hesitating about this too.
What I realize now is that we are using xmalloc() too often, and xnmalloc()
not often enough. xnmalloc() is designed to be safe against integer
12 matches
Mail list logo
