gEDA-dev: Broken slotting

[Gabriel Paubert]

On Tue, Sep 11, 2007 at 03:12:09AM +0100, Peter Clifton wrote:
> 
> On Tue, 2007-09-11 at 02:50 +0100, Peter Clifton wrote:
> 
> > The question remains... is the fix to revert the behaviour - and keep
> > pinseq constant for slotted parts, or (seems more likely) introduce a
> > modulo operation when looking for pinseq when updating slots?
> 
> (The obvious route to calculate what pinseq numbers to look for from our
> old slot doesn't work... the slot is updated by the time the
> o_attrib_slot_update() function is called)
> 
> I know its late... but is the following g_malloc completely bogus?
> 
> 
> 	/* Now put new pinseq attrib onto pin. */
> 	new_pinseq = g_malloc(sizeof(char)*((numpins-1)*slot)+pin_counter);

Indeed, it looks bogus:
a) sizeof(char)==1 by definition (harmless)
b) malloc has at least 4 byte granularity in practice
c) 12 bytes will always be enough to keep the ASCII representation of 
   an int in base 10. Of course I'm assuming that pinseq will not 
   exceed about 2 billion, but that's already about 6 orders of
   magnitude more than the largest packages I know.

> 	sprintf(new_pinseq, "%d", numpins*(slot-1)+pin_counter);
>         /* Add 1 for EOL char */

I don't know whether we want to support negative pinseq but 
a safe way would be:

	char tmp[12];
	sprinf(tmp, "%d", numpins*(slot-1)+pin_counter);
	new_pinseq = g_strdup(tmp);

The performance is probably not that worse. Double the
size of tmp if you want to be 64-bit safe for multibillion
(well, american billion) pin packages :-)

	Regards,
	Gabriel