I updated asprintf.c to cannibalize the GIS API, using G_tempfile().
Objections?
--
Brad Douglas <rez@touchofmadness.com>
(attachments)
asprintf.c.patch (2.29 KB)
Hello Brad
On Wed, 8 Jun 2005, Brad Douglas wrote:
I updated asprintf.c to cannibalize the GIS API, using G_tempfile().
Objections?
It may be a bit slower but probably not much if at all. It is clearer what it is doing and more consistent with usage in other GRASS modules anyway.
Previous correspondence on the list has indicated that in all C
implementations we can rely on the size of a char being 1 byte so it is
more efficient not to use the sizeof() function.
It would be nice also to use indent according to the spec in the SUBMITTING document to format the file nicely, as I left it in a total mess when originally submitting it.
Paul
On Thu, 2005-06-09 at 01:52 +0100, Paul Kelly wrote:
Hello Brad
On Wed, 8 Jun 2005, Brad Douglas wrote:
> I updated asprintf.c to cannibalize the GIS API, using G_tempfile().
>
> Objections?It may be a bit slower but probably not much if at all. It is clearer what
it is doing and more consistent with usage in other GRASS modules anyway.Previous correspondence on the list has indicated that in all C
implementations we can rely on the size of a char being 1 byte so it is
more efficient not to use the sizeof() function.
I used sizeof(char) because size_t varies across architectures and it
quiets the compiler without any loss in performance. sizeof() is a
macro and is determined before the binary is generated, so there is
absolutely no loss in performance (I verified the asm output to be
identical in GCC).
It would be nice also to use indent according to the spec in the
SUBMITTING document to format the file nicely, as I left it in a total
mess when originally submitting it.
I had planned on reformatting the function after the working parts had
been committed.
--
Brad Douglas <rez@touchofmadness.com>
It would be nice also to use indent according to the spec in the
SUBMITTING document to format the file nicely, as I left it in a total
mess when originally submitting it.
As far as I can see, there's nothing in SUBMITTING about indentation.
Here's what I have used:
$ indent -nbad -bap -bbb -nbbo -nbc -br -bli1 -bls -cbi0 -ncdb -nce \
-ci4 -cli0 -ncs -d0 -di0 -fc1 -nfca -hnl -i4 -ip4 -l80 -lc80 -lp -npcs \
-pi4 -nprs -npsl -sbi0 -sc -nsob -ss -ts8 main.c
Markus has used these rules more recently:
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 $1
We should pick one and add it to the SUBMITTING file, with a note that
doing so without due cause is not good, as it will destroy the
usefulness of diffs vs old versions of the code.
Also, can we change rule #26 to drop 'diff -c' and just prescribe
'diff -u' as the prefered method?
Hamish
On Thu, Jun 09, 2005 at 01:52:37AM +0100, Paul Kelly wrote:
...
It would be nice also to use indent according to the spec in the
SUBMITTING document to format the file nicely, as I left it in a total
mess when originally submitting it.
I don't remember which one is official, could it be:
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 file.c
(http://httpd.apache.org/dev/styleguide.html)
?
Markus
On Thu, 9 Jun 2005, Markus Neteler wrote:
On Thu, Jun 09, 2005 at 01:52:37AM +0100, Paul Kelly wrote:
...It would be nice also to use indent according to the spec in the
SUBMITTING document to format the file nicely, as I left it in a total
mess when originally submitting it.I don't remember which one is official, could it be:
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 file.c
Ah I thought it had been put into SUBMITTING but looks like it hadn't. Here is what Glynn suggested in that discussion:
http://grass.itc.it/pipermail/grass5/2003-July/008196.html
Paul
On Thu, Jun 09, 2005 at 12:24:13PM +0100, Paul Kelly wrote:
On Thu, 9 Jun 2005, Markus Neteler wrote:
>On Thu, Jun 09, 2005 at 01:52:37AM +0100, Paul Kelly wrote:
>...
>>It would be nice also to use indent according to the spec in the
>>SUBMITTING document to format the file nicely, as I left it in a total
>>mess when originally submitting it.
>
>I don't remember which one is official, could it be:
>
> indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 file.cAh I thought it had been put into SUBMITTING but looks like it hadn't.
Here is what Glynn suggested in that discussion:
http://grass.itc.it/pipermail/grass5/2003-July/008196.html
Thanks for the (lost) reference.
A good test case is
grass5/src/libes/image3/*.c
which is full of comments, debug etc and IMHO partially unreadable.
Markus
Hi Developers,
Alltough there doesn't seem to be much interest, I'm still persisting on this subject.
Now that the concept of my thinking is working, I would urge you all to have a look at the
doxygen generated Programmers manual (based on GRASS 6.0). It's the product of a script I've been working some time on, where all c or c++ code is transformed by doxygen and placed in the same directory structure as the sources. In fact it's a system, for generating script based documentation, adding and updating is made easier, which I will explain sometime soon.
I've started last year with the wiki page TheGrassProgrammingHowto, but as the wiki proved to have limitations and doxygen was the new way, I started looking into it.
The result of my efforts can be seen here:
http://members.home.nl/jkwast/doxygenhtml
I'll hope you will find some time to look at it, as good documentation will also attract more developers and make it easier for the non programmers among us, to more quickly become one. The very fine example of documentation would be the gtk+-2.0 library (www.gtk.org/tutorial/), as is their code base.
Greetings,
Joris van der Kwast
Bsc Tropical Agriculture
Unigis student
PS If you like it, I will try and see if somebody is willing to put the scripts in cvs.
Hi Joris.
Just one note: the html does not show well (left and right columns overlap).
All the best.
pc
At 14:17, giovedì 09 giugno 2005, J.C.M. van der Kwast has probably written:
Hi Developers,
Alltough there doesn't seem to be much interest, I'm still persisting on
this subject.
Now that the concept of my thinking is working, I would urge you all to
have a look at the
doxygen generated Programmers manual (based on GRASS 6.0). It's the
product of a script I've been working some time on, where all c or c++
code is transformed by doxygen and placed in the same directory
structure as the sources. In fact it's a system, for generating script
based documentation, adding and updating is made easier, which I will
explain sometime soon.
I've started last year with the wiki page TheGrassProgrammingHowto, but
as the wiki proved to have limitations and doxygen was the new way, I
started looking into it.The result of my efforts can be seen here:
http://members.home.nl/jkwast/doxygenhtml
I'll hope you will find some time to look at it, as good documentation
will also attract more developers and make it easier for the non
programmers among us, to more quickly become one. The very fine example
of documentation would be the gtk+-2.0 library (www.gtk.org/tutorial/),
as is their code base.Greetings,
Joris van der Kwast
Bsc Tropical Agriculture
Unigis studentPS If you like it, I will try and see if somebody is willing to put the
scripts in cvs._______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
G_asprintf() is using G_tempfile():
/* We cheat by printing to a tempfile via vfprintf and then reading it
* back in. Not the most efficient way, probably.
*/
Is the only way to have a safe, portable snprintf() *really* to write
and read off the disk? Surely we can do better.
Aside from being grossly inefficient, this is really bad when running
GRASS on a limited write cycle flash drive, e.g. handhelds. You can
mount /tmp on a virtual ram-drive ok, but due to the security issues
surrounding putting stuff in /tmp, G_tempfile() has to write to the
mapset, which you definitely don't want to be volatile storage.
I bring this up as I do want to put GRASS on a 2gig flash-only portable
to take into the field and don't want to trash the flash cards.
thanks,
Hamish
Hamish wrote:
G_asprintf() is using G_tempfile():
/* We cheat by printing to a tempfile via vfprintf and then reading it
* back in. Not the most efficient way, probably.
*/Is the only way to have a safe, portable snprintf() *really* to write
and read off the disk? Surely we can do better.
As GRASS is GPL, we can just take the code from GNU libc.
Aside from being grossly inefficient, this is really bad when running
GRASS on a limited write cycle flash drive, e.g. handhelds. You can
mount /tmp on a virtual ram-drive ok, but due to the security issues
surrounding putting stuff in /tmp, G_tempfile() has to write to the
mapset, which you definitely don't want to be volatile storage.
Using the mapset directory has nothing to do with security issues.
There are plenty of ways to securely create files under /tmp.
The reason that G_tempfile() uses the mapset is that it must be
possible to use link() to atomically replace a GRASS database file
with a file created by G_tempfile(), so the file which G_tempfile()
creates has to reside on the same filesystem (i.e. partition) as the
mapset directory.
Actual "temporary" files should use e.g. tempnam() rather than
G_tempfile(). Either that or G_tempfile() should be renamed and
anything which uses it for its original purpose should use the renamed
function.
--
Glynn Clements <glynn@gclements.plus.com>
On Sun, 2005-06-19 at 10:37 +0100, Glynn Clements wrote:
Hamish wrote:
> G_asprintf() is using G_tempfile():
>
> /* We cheat by printing to a tempfile via vfprintf and then reading it
> * back in. Not the most efficient way, probably.
> */
>
>
> Is the only way to have a safe, portable snprintf() *really* to write
> and read off the disk? Surely we can do better.As GRASS is GPL, we can just take the code from GNU libc.
I made the most recent changes to G_asprintf(), so I can take care of
this issue and post a diff to the list for review.
I'll look into it this afternoon if I'm not lured to the sunny outside.
=)
--
Brad Douglas <rez@touchofmadness.com>
I made the most recent changes to G_asprintf(), so I can take care of
this issue and post a diff to the list for review.
be sure to search the grass5 mailing list for previous discussion on
this, I think by Eric Miller & Paul Kelly. ...
I can see value in having both G_asprintf() and G_snprintf() for
different parts of the code. i.e. G_asprintf() is nice for new code but
G_snprintf() might be handy for dealing with existing code without
having to rewrite everything to use pointers.
But I totally defer the real programmers around here on this subject.
Hamish
> G_asprintf()
also, should/does it support multi-byte chars now we are in the i18n biz?
e.g. gettext/intl/vasnprintf.c
Hamish
Hamish wrote:
> > G_asprintf()
also, should/does it support multi-byte chars now we are in the i18n biz?
e.g. gettext/intl/vasnprintf.c
Do you mean wide characters? If so, the current G_asprintf()
implementation will support whatever vfprintf() supports. For all
C9X-compatible implementations (including GNU libc 2.x), that includes
%lc and %ls.
The %s specifier deals with byte strings; it doesn't care about
encodings. The %c specifier deals with individual bytes; it can't be
used to write a multi-byte character.
C9X also defines fwprintf(), swprintf() etc, which output wide strings
using a wide format string. As almost nothing in GRASS understands
wide strings, there wouldn't be much point in providing an interface
to those.
--
Glynn Clements <glynn@gclements.plus.com>