Re: [Bug-gnubg] Patch: File associations under Windows and spaces in filenames

[Jim Segrave]

On Mon 25 Nov 2002 (17:34 +0100), Holger wrote:
> 
> >    In the case of the diffs you submitted, running them against the
> >    current CVS put the new local variables szQuoted et al into the
> >    middle of the usage text, as there was no context from diff.
> 
> I was hoping that it would be enough to state the snapshot date (from
> alpha.gnu.org). I will use the IDs from now on.

Yep - on good (or maybe bad days) you can see 3 or four developers
checking files in on the same day, sometimes a file can change within
hours. 
 
> > Other comments:
> > 
> > 1) When you added the --datadir option to the getopt_long call, you
> >    missed the comments above, which should be changed to reflect the
> >    change to the code. It's a mistake every programmer makes, but it
> >    leads to a support nightmare. There's a saying somewhere
> >    (Programming Pearls II perhaps) to the effect:
> > 
> >    "If the comments and the code disagree, it is likely that both are
> >    wrong."
> 
> Indeed, sorry. Like I said before, my programming experience is not that
> huge and zero in regard to public projects. So, please be patient with me.
> However, I'm really willing to improve and learn from you.

I'm far from perfect, believe me. I simply was reading the comments
while looking at your changes so I could estimate if there might be a
problem. 
 
> > 2) I don't have a Windows environment, so I don't know if it supplies
> >    PATH_MAX, but Unix environments don't supply _MAX_PATH. I added a
> 
> I had thought about this earlier. But then I've seen it in MinGW, too, (and
> not only in the Visual Studio help) and supposed that it would exist under
> Unix as well. Unfortunately, a wrong guess.
> 
> If you or somebody else could recommend a comprehensive, downloadable
> manual/reference on what is portably usable I'd be very grateful.

Buf of course Unix people will assume that (their version of) Unix is
standard, which also isn't true. Posix is a standard, but often not
adapted - there are some arguments against it, as applies to almost
anything of this nature. 

I find http://www.opengroup.org/ a useful starting place to guess how
standard something might be across flavours of Unix, but it's not
really what one is usually looking for. For example, it may well tell
you that some function of definition is considered mandatory, but it
won't help you guess what that function or name might be called. And
for Unix users like me, who have no Windows build environment, I have
no idea where I could find out if some function or definition is
likely to be available in the Windows port.
> > 3) Again, this is my opinion only: 
> >    I would strongly recommend against using C++ style comments ('//
> >    text') and only use /*..*/ ones. We're much better off staying with
> >    ANSI C. The option is going to C++, but I don't think that that's
> >    desireable/possible. I notice other developers who are also doing
> >    this, but this really limits any build to being done with gcc or a
> >    similarly tolerant compiler. The person trying to build a text only
> >    version on an obscure platform (or with a compiler optimised for
> >    his hardware) will thank us all for not expecting the compiler to
> >    accept this.
> 
> I've never learnt pure ANSI C. That's why. C++ style comments are much more
> convenient. But of course I agree with you.

I know - they are inherently quicker and, when I was doing some C++
coding, they started slipping into the C code I wrote as well. Then I
hit the compilers from hell and got out of that habit.
> 
> Thanks. I hope my patch is worth your trust.

I'd be very surprised if it doesn't do exactly what you intended - the
code is clear enough in what it does.

-- 
Jim Segrave           address@hidden