Re: [5516] first support for quoting node names

[Gavin Smith]

On Sun, May 4, 2014 at 10:24 PM, Karl Berry <address@hidden> wrote:
> Gavin,
>
>     +   TODO: Decide on best method of quoting. */
>
> Indeed.  I have all your various messages saved but haven't put together
> the time to carefully consider them yet.  (And given TeX Live and other
> things, not likely to happen real soon.  Sigh.)  I hadn't been ignoring
> it, though it may have seemed like it.  Sorry.  I wasn't expecting you
> to implement it.
>
> Anyway, my one off-the-cuff thought was that you proposed using DEL
> because it is ignored in terminals.  Ok, but how about using NUL
> instead?  Which is also ignored as far as I can see.  Or rather, NUL NUL
> to avoid ambiguity with the misbegotten NUL BS syntax.  That way, at
> least we avoid introducing yet another special character into Info files.
>
> Like I said, off the cuff, so if this is obviously dumb, apologies in
> advance.
>

There are probably several methods which would work fine. I don't
think there is much harm in using DEL. I found with using the NUL BS [
style quoting it would crash the info browser for some reason - I
didn't investigate why but I suspect the use of NUL doesn't play well
with the C string functions. That said, if NUL NUL does work with
existing readers, there's no reason why that couldn't be used. Or
maybe SPACE BACKSPACE could work. There are other complications like
how well it plays with different character encodings, which I haven't
thought about that much.

> Meanwhile, could you please write a minimal patch to the Info
> specification chapter in texinfo.texi to describe your proposal?
> It would have to be done anyway, so ...
>

Yes, I can do. I'll post it to the list when I do it.

> Thanks,
> K
>
> P.S.
> +          *output = 0;
> ..
> +      (*output)[len] = '\0';
>
> Wouldn't it be more consistent to either use NULL in the first
> assignment (if I'm following), or 0 in the second?
>

It's a question of style and personal preference. I have reasons for
my preferences but they're not worth going into in great detail. I
write '\0' to document that a char object is getting the value 0,
specifically as a null terminating a string. The = 0 assignment is
different; that is not an assignment to a character object, but to a
pointer. Some people prefer to write NULL instead, which is defined as
0 anyway, but then there is a slight worry about what header file NULL
is defined in and what it's defined to. But either way is fine.

> P.P.S.
> +  long len;
> Is using long instead of size_t going to cause dumb declaration
> conflicts?
>

Again, it's a taste issue. AFAIK the main conflicts would come in
trying to cast between (long *) and (size_t *) which the compiler
cannot do safely if the underlying types differ, but it can cast the
plain types safely. It should be okay if there are no compiler
warnings about it. I had problems with size_t being an unsigned type
which meant that subtractions involving it always came out as
positive, which leads me to worry about when I see it. There's also
ptrdiff_t, which I'm not sure what the point of is. It seems simpler
to me just to use long for everything - but again, I feel it's a minor
issue and I don't care if others want to do it differently.