[GRASS-dev] portable.h elimination

[Glynn Clements]

Paul Kelly wrote:

> >> For some reason (can't quite remember why) I changed test.c in the past to
> >> try and get this to work. ISTR someone suggested somewhere extra seeks
> >> were needed on Windows.
> >
> > You need to seek when switching between reading and writing. Windows'
> > FILE structure only has a single buffer (rather than separate
> > read/write buffers), so you need to force it to flush/discard any
> > buffered data.
> 
> Do you think extra seeks need added anywhere else in the library, or is it 
> just this test program that is affected?

I would think that most uses of the diglib I/O use either read-only or
write-only streams, so shouldn't be affected. And programs which do
both will normally follow a pattern of seeking followed by a sequence
of reads or a sequence of writes.

Writing something then reading whatever happens to follow what you've
just written seems unlikely. Reading then writing seems more likely. 
Also, this isn't specific to the diglib I/O, but anything using ANSI
stdio.

> > The "diff" failure indicates that what was written wasn't what was
> > expected. This could be a text/binary issue (I don't see $(FMODE_OBJ)
> > in the link command); it could even be due to differences in
> > floating-point rounding (even if only the lowest bit of a double is
> > wrong, the test will still fail).
> 
> None of those - it was just that I had put the dig_fseek() call in too 
> late - it should have been before the call to fprintf(). With it before 
> fprintf(), now everything works even without bothering about $(FMODE_OBJ) 
> so I have committed the changes to CVS and enabled the test for MinGW in 
> the Makefile.

I've noticed that test.ok doesn't include any '\n' characters, so EOL
conversions won't affect the test case. But, in general, every program
needs to link against $(FMODE_OBJ). Those which use the cmd/inter/etc
targets from Module.make are automatically covered, but anything with
an explicit linking command needs to handle this manually.

It might be worth adding a make function for linking executables to
e.g. Rules.make, so that we don't have to deal with this issue (and
similar issues) in dozens of individual Makefiles. There are quite a
lot of programs which aren't built with the standard cmd/inter/etc
targets.

-- 
Glynn Clements <glynn at gclements.plus.com>