michael@??? wrote:
>> If the formal
>>declaration of the function declares that it will copy n bytes FROM THE
>>SOURCE STRING then what you proposed would be correct.
>
>
> Yes, that's what the length parameter is good for. It is either
> the number of characters in the source string or a smaller number,
> but never more. At least that is how it should be, but so far nobody
> showed a place where Exim works different.
The problem is, that we also have local_scans, changing the api could be
a problem. The problem is, that string_cat can also be used as "Append
from string, but don't use more than X chars", your patch will break
this. No, I'm not saying that this is good practice, but you never know
what kind of code is lurking in the wild. :)
> I guess I have worked on too many programs that use their own string
> library using the pointer/length model, thus removing the artificial
> difference between str* and mem* functions and calling them all string
> functions. I have no benchmarks on them, btw, but I don't need one,
> because those libraries are used for _correctness_ when dealing with
> NUL characters, not for efficiency.
>
> I can imagine Exim going that way further than it already does. Right now
> it deals with length/capacity variables in many places instead of using
> strlen() often, like typical code does, but it may as well put those
> variables together with the char pointer in a struct.
ACK! Like I said before, I think C-Strings ARE braindamaged. It would be
good to make the store_* functions more generic, and add some more
functions, that can handle structured strings, consisting of
capacity/length/data.
This is a better approach (IMHO) than normal C-Strings, but it's a bit
harder to handle, and will need a major rewrite of exim.
One of the major problems is, that you'll still have to handle data from
external libraries that use standard C-Strings *SIGH*.
Nico
