Re: getline & getline_safe

[Paul Edwards]

"Derek Robert Price" <derek@ximbiot.com> wrote in message 
news:mailman.467.1059075915.8231.bug-cvs@gnu.org...
> >>>but the other strings are
> >>>not logically related to filenames and thus should be separately
> >>>defined.  Maybe I wouldn't be so anal to create a USERID_MAX,
> >>>WHATEVER_MAX, but I would separate filenames that aren't
> >>>actually stored in the ",v" file to strings that are.  I see those as
> >>>very different things.
> >>>
> >>What are you talking about here?  What filenames stored in ,v files?
> >
> >Filenames AREN'T stored in the repository (,v) files!  Other
> >strings are.
>
> Uh, I knew that.  Now what in the world are you talking about separating?

There are two very distinct things:

1. String used for a filename.

2. String used to be inserted into ",v" file.

Conceptually, they would have very distinct maximum sizes, so would
have different #defines for maximum sizes.

Number 1 is OS-dependent, and FILENAME_MAX exists for this
purpose.

Number 2 is application-dependent and CVS_MAX_STRING
would seem appropriate for a generic define.

I don't see any reason for the maximum string size acceptable in
the CVS application to be in any way dependent on the maximum
file size that the OS supports.  Even if you have made a *guess*
that FILENAME_MAX/MAX_PATH should be larger than
CVS_MAX_STRING on "most platforms", thus just cascading the
former (as is currently done) should be fine.

The original question you were asking was to do with design
philosophy, so I am giving you my personal opinion on what I
consider to be "clean design", and that means distinguishing
lengths for different data types, and they are different data types.

I doubt that in practice anyone will issue a bug report, so there's
no particular need to do any code change.  It's just the original
question was along the lines of "what makes sense from a
design point of view".

BFN.  Paul.