Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!rutgers!mailrus!b-tech!m-net!remmers
From: remmers@m-net.UUCP (John H. Remmers)
Newsgroups: comp.lang.c
Subject: Re: hardcoded constants
Message-ID: <2645@m2-net.UUCP>
Date: 23 Dec 88 17:04:37 GMT
References: <2636@m2-net.UUCP> <1104@goofy.megatest.UUCP>
Reply-To: remmers@m-net.UUCP (John H. Remmers)
Organization: M-NET, Ann Arbor, MI
Lines: 30

In article <1104@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <2636@m2-net.UUCP>, by remmers@m-net.UUCP (John H. Remmers):
>...
>> The space requirement for a string concatenation is a frequently-needed
>> value; it's worth having a macro to represent it:
>> 
>> 	#define  Catspace(s,t)  (strlen(s) + strlen(t) + 1)
>> 
>
>You are a candidate for SLMA (Silly Little Macros Anonymous).
>
The merits are debatable, I suppose, but if an application requires a 
lot of dynamic allocation of space for strings, hiding the 1 for the
null byte in a macro definition is a way to defend against forgetting
it (a common error, in my experience).  The wisdom of this approach
ultimately is determined by frequency of use.  Agreed, inventing
macros for isolated situations is not good practice.  What I was trying
to say, perhaps not too clearly, is that a macro for string concatena-
tion space might find sufficient use to be worth defining, and that
*if* that is the case, this is a natural place to use it.
>
>But if you don't like the naked "1", how about this?
>
>foo =  malloc( strlen(s) + strlen(t) + sizeof('\0'));
>
As a couple of people pointed out to me in mail, '\0' and '/' are
ints, so sizeof('\0') = sizeof(int), usually 2 or 4, and more space
is allocated than needed.

It was not the naked "1" I was questioning so much as the naked "2".