Mail Archives: geda-user/2015/12/16/15:12:16
> > I note you use // for comments. If we're going this route, we should
> > update configure to test for a C99-compliant compiler.
>
> This is probably a pretty safe assumption now.
Still, a check would be nice.
> It bugs me too. The C alternatives I'm aware of are:
#define Point Vec
> > I think the debug markers should either be removed for now, or
> > "completed" - added to all HIDs and documented with some
> > programmer-specific documentation.
>
> Would you settle for stubs in the non-gtk HIDs, and programmer
> documentation?
> It's not obvious to me how to do it in lesstif and I have no real motivation
> to figure it out. What do you mean by programmer documentation besides
> comments in hid.h?
Sure. At the moment, it's just a couple extra functions that nobody
calls and aren't documented. I still don't really know what they're
used for...
> > The right way to ignore square flags on arcs is to update the flag
> > parsing table so that it's not in the supported flags... oh wait, it's
> > already ignored there.
>
> I didn't find this table... so I can just take out all the square arc stuff
> and it should do the right thing (though a message would be nice really)?
strflags.c
There are a lot of unsupported flags that we don't error (or warn)
for, if you want to add warnings for them, go for it :-)
> > Foo foo foooo, twice. With an abort, no less.
>
> Well I was making sure I'd found the arc parser. Seems you have some
> old-style arcs around
It's for backwards compatibility - older file formats have a different
syntax.
And no, I have no such files, I read the diff.
> > "double" type isn't precise enough to hold a pcb coord - "double" is
> > 53 bits, but Coord is 64 bits. Does this matter?
>
> Well, the existing geometry code does this quite a lot.
As noted elsewhere, it's probably not a problem anyway. I was
thinking of the limits of 32 bit coords, we're nowhere near the limits
on 64 bit coords.
- Raw text -