[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico]
[Índice de assunto]
Re: forwarded message from anonymous@ime.usp.br
- Subject: Re: forwarded message from anonymous@ime.usp.br
- From: Jose Coelho de Pina <coelho@ime.usp.br>
- Date: Tue, 24 Jun 2003 11:16:06 -0300
Ois,
Rubens Altimari writes:
> >Já que o EP foi adiado, gostaria de tentar finalizá-lo apesar daquele
> problema que expliquei ontem de coisas estranhas acontecendo no SGB...
> Alguém mais está tendo esse problema? Lembrando: arcos somem quando crio
> arestas.
>
> Você está trabalhando no Linux ou no Windows? Se for no Windows (ou, na
> verdade, em qualquer outro ambiente em que você tenha tido de recompilar o
> SGB), eu tenho verificado erros estranhos por conta de compatibilidade
> pré-ANSI x ANSI x compilador, estas coisas...
>
[...]
Sobre esse negócio de ANSI ou não ANSI, tem o seguinte escrito no
arquivo README em http://www.ime.usp.br/~coelho/grafos/sgb/src/
(Acho que não ajuda em coisa alguma... mas é interessante.)
[...]
* Important note: The Stanford GraphBase programs do not obey the ANSI C
standard restriction on comparison of pointers. In fact, the author (Knuth)
confesses to being unaware until recently that such a restriction was
part of the standard; he wrote the code under the assumption that
pointers were essentially machine addresses. No problem occurs with
respect to |==| and |!=| comparison, but the code sometimes has a loop
like |for (p=hi;p>=lo;p--)| where |lo| is the base address of a
dynamically allocated array. Strictly speaking, |lo-1| is undefined.
In other places (e.g., sections 23 and 26 of GB_SAVE) we explicitly test
if one pointer is less than another; this code effectively sorts a set of
pointers of unknown origin by magnitude, so it assumes that |<| defines a
total ordering on pointers. In GB_GATES section 2 we cast a pointer
to unsigned long and test whether the result is |<=1|; conversely, the
constant 1 is read as a pointer via a union type in GB_SAVE section 10.
None of this is likely to cause any trouble unless your environment has
segmented architecture and 16-bit offsets within each segment. If you do
have such a system, your best bet is probably to get one of the free
and excellent ports of the GCC compiler. For example, DJ Delorie has
succeeded in porting GCC to the MSDOS environment. Alternatively,
a set of change files appears on directory sgb/ANSI.
* The code also assumes throughout that NULL is equivalent to zero (for
example, that pointer arrays delivered by |calloc| are full of NULLs).
It would be almost impossible to remove this assumption; don't even
think about it.